Coding Values - Arunav.Net
The other day, while reviewing a code I found an error in the exception handling logic, essentially to fall back for null values. The response by the programmer was the code will never execute as the value would never be null. Lesson; never write a code that will never execute, effectively do not handle exceptions unnecessarily.
The thumb rule is the less code you write, the less error you make. The other thing that annoys me is commented code and the reason being that might be used in future. Lesson, futuristic coding does not mean writing code for future and commenting it out or otherwise. Essentially the code should never be futuristic; it is the design that should be futuristic. That means you leave scope for future extension with no need of changing your existing functions or classes.
An Italian painter named Carlatte defined beauty as the summation of parts in a way that nothing can be added or removed or altered. That also goes for the definition of beautiful code.
Note even the most beautiful codes can have silly mistake, another note it is the mistake in the code that is silly and not the programmer. So differentiate your code from yourself, your default view about your code should be that it is a culprit planning to penetrate in all other good code just to ruin your and your teams earlier efforts. A general excuse for bad code is because the existing code is bad enough to adjust with this new miscreant. In such situation you should introduce reformer codes, a code good enough to change the way other programmers would be writing new codes.
Proving the code innocent, .net provides ample of tool for debugging, using which you should step through every line of code, you can also force the control to step in the code that would not be called otherwise based on the current input and execution plan. This is the best way to prove a code innocent and practicing this will very soon enable you to review the code as a compiler and hence will empower you to write code that already eliminates various future bugs.
Only after you have proved "the code" as innocent to yourself by the above step you should call it "your code". So now you have a soft corner for your code but that would mean nothing to your team member, so challenge a fellow programmer to prove your code guilty and allow him to review your code. Believe it or not, I loose such challenges all the time but its all for the good. Only when the reviewer (the critic) approves your code as innocent should it be allowed to mingle with the other codes.
I have had experience in not being able to understand my own code after some duration, so I believe another important aspect of programming is commenting, your comment should essentially answer three questions Why, What and When? Optionally you can also answer how, but since the comment is never read by people other than programmers so you can live without it unless it is a complex logic where inline comments should be placed. Elaborations of the questions are; why is the code required? What does it do to achieve the answer of why? And when is the code executed, possibly by which function or class?
Practicing commenting I have realized I am able to remember my comments more than my code and now while searching for a location of code to be modified I search by my comments.
“Happy Coding” to all programmoholics.