Compilers don’t refactor, extend, and debug code. People do. I doubt you can find a single book written on software development guidelines that does not sate in one way or another that you should write software for people, not computers. No matter how ugly you make your code, if it is technically correct, the compiler will be able to read it. However, what should be of great concern to you is that the person who will maintain your code needs to be able to quickly read and understand your code. That person, often referred to as “the next guy” might very well be you. If you have ever looked at code you had written a year ago, or even 3 weeks ago then you know that it might as well have been written by someone else. Make your code as readable as possible for the next guy!
I thought this was a universal truth that everyone followed, but on a continual basis I see that it is not. When reading through code I often have to translate what is written into English when I shouldn’t have to. Granted there might be some gray area between what is readable to you and what is readable to me, but seriously folks, the languages you are writing in allow you to speak near-English, please do so! I know many developers including myself have developed disdain for Visual Basic and its culture, but you have to hand it to the language designers, it is easy to read.
When writing code it is very useful to remove operators and replace them with English when possible. Sometimes this is for English-ness, other times it is just good OO encapsulation. It should darn near always be done for publicly-callable code.
//If the collection is empty then…
if (myCollection.Count == 0)
Replace with
if (myCollection.IsEmpty)
//If the collection has any items then…
if (myCollection.Count > 0)
Replace with
if (myCollection.IsNotEmpty)
or
if (myCollection.HasItems)
No translation or comments are needed
Some coding shortcuts remove the English to create functionally equivalent but more compact code.
int ValueToUse = UserEntered >= MinValue ? UserEntered: MinValue
Instead of
int ValueToUse
if UserEntered >= MinValue then
ValueToUse = UserEntered
else
ValueToUse = MinValue
Or a little more compact
int ValueToUse = MinValue
if UserEntered >= MinValue then
ValueToUse = UserEntered
I would argue the second code blocks are much easier to read while scanning code to understand functionality. There is no translation. The ternary code might look cool, but the coder looks foolish.
The only excuse for hard-to-read code is when it is an accepted convention among a development team or department. For example, often a group might decide that i can be used as a variable for a simple counter in a loop, or that ex can be used for exception in all the standard error handling routines, etc. Standard acronyms might be used that have no place outside the domain but are readable in the application’s context. Even the ternary operator can be excused under the right circumstances, but clearly should not be used on a normal basis.
I might add this to my list of interview questions when trying to get a glimpse into a candidate’s development psyche. “Tell me your feelings about object-oriented development, auto numbers, data binding, comments, programming certifications, error handling, and ternary operators.”