Well, everyone in the Programming world wants to have good coding skills and definitely wants to write good code. Even while writing this blog, I have a mindset of becoming a better programmer and further following the best practices. So, today in this blog will be sharing some of the steps of better programming which will be very helpful to write easy and understandable code.
Bad coding is not just problematic for us but for others too. So, keeping this in mind, let’s start following the below best practices while Coding.
Some of the tips to follow for better programming are:
- Use meaningful Names
- Follow the single responsibility principle
- Write testCases.
- Write comments whenever necessary
Meaningful Names
Use intention revealing names. Choosing good names takes time but saves more than it takes. The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
Eg- int d; // elapsed time in days.
So, here in the above example, though we have defined a variable it needs a comment to define what does this variable means, which is not a good practice at all. However, we can do below which is easily readable & understandable.
We should choose a name that specifies what is being measured and the unit of that measurement.
A better name would be – int elapsedTime.
Class Names- Classes and objects should have nouns or noun phrases names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.
Method Names- Methods should have verb or verb phrase names like post-payment, delete a page, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get, set, and is according to the JavaBean standard.
When constructors are overloaded, use static factory methods with names that describe the arguments. For example,
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
is generally better than
Complex fulcrumPoint = new Complex(23.0);
So, always try to use Solution Domain Names which should have a meaningful context.
Functions
Small!
- The first rule of functions is that they should be small.
- The second rule of functions is that they should be smaller than that.
Lines should not be 150 characters long. Functions should not be 100 lines long.
Functions should hardly ever be 20 lines long.
Do one thing!
Function should do only one thing and do it really well.
Function Arguments
A function shouldn’t have more than 3 arguments. Keep it as low as possible. When a function seems to need more than two or three arguments, it is likely that some of those arguments ought to be wrapped into a class of their own. Reducing the number of arguments by creating objects out of them may seem like cheating, but it’s not.
Now when I say to reduce a function size, you would definitely think how to reduce try-catch as it already makes your code so much bigger. My answer is to make a function containing just the try-catch-finally statements. And separate the bodies of try/catch/finally block in a separate function.
Error Handling Is One Thing
Functions should do one thing. Error handling is one thing. Thus, a function that handles
errors should do nothing else. This implies that if the keyword try exists in a function, it should be the very first word in the function and that there should be nothing after the catch/finally blocks.
Some tips to write effective functions:
- Functions should either do something or answer something, but not both. This ensures a function does not have hidden side effects. For example, a function named isPresent() should only return a bool and not do any other operations.
- Don’t return Null
- Avoid output arguments
Comments
Comments Do Not Make Up for Bad Code
One of the more common motivations for writing comments is bad code. We write a mod-
ule and we know it is confusing and disorganized. We know it’s a mess. So we say to our-
selves, “Ooh, I’d better comment that!” No! You’d better clean it!
Clear and expressive code with few comments is far superior to cluttered and complex
code with lots of comments. Rather than spend your time writing the comments that
explain the mess you’ve made, spend it cleaning that mess.
It is great to explain yourself in Code
Good Comments – Some comments are necessary or beneficial. We’ll look at a few that I consider worthy of the bits they consume. Keep in mind, however, that the only truly good comment is the comment you found a way not to write.
Legal comments are necessary to write. Legal comment means copyright and license statements.
Good code doesn’t even need comments. Correct naming can prevent comments too.
So, this was all in Clean Code Part-1 & will continue the same in Part2 which will cover Data Structure, Exception Handling, Unit test cases, etc.
If you like this blog, please do show your appreciation by hitting like button and sharing this blog. Also, drop any comments about the post & improvements if needed. Till then HAPPY LEARNING.
