Reading the article 9 bad programming habits we secretly love I’m appalled that apparently this is considered the norm.
While I have likely used all of these bad programming habits at one time or another, I’m pretty sure that these are mostly due to the fact that the programmer is a poor one. Thus writing the article and hoping to get cheered on, we’re apparently worshiping the mediocre or even poor workmanship.
Depending upon where I reside in the hierarchy you should then either follow my advice or that of the article.
The habits:
No.1: Using goto
Using line numbers, you were bound to run out of valid line identifiers, thus you had to insert one line in essence telling “the code is to be continued on line xxx”, which made reading the code in its entirety really difficult.
The article states that a goto in a case statement will produce something that’s simpler to understand than a more properly structured list of cascading if-then-else blocks. Well, swapping one bad idea for another really isn’t the way to argue. Chain of Responsibility would be the right abstraction in that case. The part that sometimes needs a goto is then a different method called by some of these handlers.
No. 2: Eschewing documentation
Documentation should state evergreen information on the entities. The intent of a class, function, field. In some rare cases it should provide sufficient insights as to why a specific approach is used over another.
The code may be changing – and you’d likely then be violating the Open Closed Principle, but that’s another story – rarely the intent of the code is changing at the same pace as the code itself.
The function names suggested: insertReservation and cancelReservationare really poor names. Quite likely there would be an argument to these functions in the sort of a reservation object, and you would end up with having code as:
insertReservation(Reservation reservation) cancelReservation(Reservation reservation)
Which – when read out loud – really is stuttering and horrible. I prefer:
insert(Reservation reservation) cancel(Reservation reservation)
No. 3: Jamming too much code on one line
Readability is at a premium, why would anyone write long lines of code? I know Java is basically a one dimensional source code language – hence the need for semicolons between statements. Why you cannot have a line wrapping string is then a bit odd, but that’s a different story.
Yes, minified JavaScript loads faster, but leave minifying to minifiers.
If you need to put things in a grouped environment, then either use functions or separate within functions with additional blank lines.
The code is not getting longer – well, perhaps line-wise, but not really byte-wise or at least code-wise. The readability on the other hand goes up.
No. 4: Not declaring types
Well, that really depends upon your programming language. In a type safe language it does give you insight when reading the code, what the writer likely had in mind. You know that a + b is supposed to be string concatenation and not an arithmetic sum if one of the arguments is a string. You know that 1/2 is integer division and will
result in 0 and not .5
No. 5: Yo-yo code
With the web a more frequent part of any development, there is a need for string to something else conversions, and sometimes back to strings again. With JSON we have basic numbers, but no dates or timestamps, thus a string <-> x is needed.
No. 6: Writing your own data structures
Usually you really shouldn’t, not even for an anticipated performance improvement. But then – who knows – maybe you’re writing the next great data structure to be used for decades.
No. 7: Breaking out of loops in the middle
The reason for not breaking or returning at several different places is code readability – and thus maintainability. Odd thing is, then loop breaks are often used for “find first”. Java – being a bit slow on this – does not cater for this functionality, whereas Scala has find(predicate) doing exactly what is needed.
No. 8: Using short variable names (but i, x, and and make sense)
Definitely! Working with coordinates, math, physics you’d be less confusing using the nomenclature of those domains. Using a for an array and l for a list seems to be counter intuitive given habit No.4 “Not declaring types”. To be hones, I don’t care if it’s an array or a list – I care what it is: List of some sort of entities: Books, users, …
No. 9: Redefining operators and functions
This is only funny until you have to debug the 2nd and 3rd redefinition. Use a mapping between whatever needs to be hacked using inverse logic and the sane world.
Summary
If you deliberately use any of the bad programming habits – with the exception of No.5, which has a few valid excuses – then my take is that you are a bad programmer. Luckily there are ways to improve – start by not doing these bad things. Follow up by not taking bad advice (mine included).