Good Code vs Bad Code

Posted by: Thomas Meadows

‘Bad Code’…If you have ever worked in software development in any shape or form I am sure you have heard this phrase before. It is, as if, a battle is taking place in the mystical land of software development where the good code is always fighting bad code in an epic fight, with God striking down Satan from the Kingdom of Heaven. And, if you believe in fairy tales and happy endings…then one day the Good Code will destroy all of the Bad Code and the software developers will live happily ever after.

Now, this type of epic battle is not generally what people are referring to when they call code bad. What is generally being referred to as ‘bad code’ is the kind of code that anyone is capable of writing unless you have no deadlines and no project manager pressuring you to write code faster. But more accurately, most ‘bad code’ should just be referred to as dirty code. Code that was made quick and dirty to please a project manager without any concern for security, styling, or the coder that will have to come behind and clean up the mess that was left. This type of code tends to “just work”, meaning that the code is only capable of working for that moment the author had in mind and nothing more. So hopefully you are asking yourself, “what can I do to make my code better?” This question has been largely solved by previous generations of coders and thankfully that have left us some answers. The most important concepts to writing code cleanly are YAGNI, Fail Fast, DAMP, and DRY.

First:  “you ain’t gonna need it” or YAGNI

Don’t write code you don’t need till you need it. It’s pretty self-explanatory because it just clutters up working code with non-working code. If you are working on a feature set that involves multiple stages, you don’t need to write code for subsequent stages, only the part of the code you are working on in the moment. If you aren’t sure if you are going to need it, it will be far easier to figure out how to add it later than to create empty sections of code that will need code added to it later. Even worse, you could add a @TODO statement that will probably never be resolved. Commented out code is another violation of YAGNI. The code is saved in git history so just delete it because you can always get it back later. This principle can also apply to other areas of software development such as databases. Have you ever seen a table or collection that only had a handful of entries? A prime example would be a list of states in the US. Are the states really going to change in the next 10…20…50 years? Probably not. Small database sets are better off being placed as constants in a configuration file. Another database offender is one to one relationships. Anytime you think about creating a table that is a one to one relation, you are almost always better off just attaching the items you were going to put on the new table to your original table.

Second: Fail Fast

I was recently writing in some legacy code and I mistyped a variable name, and no error triggered when the route was hit. This caused an unforeseen bug. If the route had failed fast when it was queried then the bug could have been avoided. The code should always fail if there is a problem. If the code does not fail when there is a problem then you will inevitably create bigger problems.

Third: “descriptive and meaningful phrases” or Damp

What this means is, don’t shorten your variable names. The code should read like English and not like steno typing (Ref: https://en.wikipedia.org/wiki/Stenotype). If I am writing a function to charge a credit card, it is easy to name my function chargeCC and most people will know what it means, but if I take the time to write chargeCreditcard(), everyone knows what it means and there will be no confusion as to my intent. It’s a very fine line before we reach Microsoft’s famous Hungarian notation hand. Would be writing userArray really be that much harder than userArr? If it reads like English, it is easier to read and therefore it is easier to maintain and understand.

Lastly, what about DRY code or ‘Don’t repeat yourself’

While this is extremely important, without using the previous three principles dry code becomes totally useless. Many developers will tout this as their highest priority but if you are failing to write readable code then this will not help your code become clearer. If you can’t read the code, you may actually just be making the code more unmaintainable by trying to make dirty code DRY. DRY is like icing on readable code. It simply makes beautiful code prettier.

There are many contributing factors to dirty code, but in my experience, the most lucid problem that I have run into in many projects are file and function sizes. While there are some arguments over optimal files sizes for the code. Almost all coders with any kind of experience tend to agree that file sizes should always be less than 1000 lines of code and functions should always be less than 200 lines of code. Not only does this help with code readability, but it makes resolving merge conflicts significantly easier. Once a function gets over 200 lines of code you have a runaway function. This is the point at which a function becomes extremely complicated and expensive to maintain and that increases exponentially as the size of the file/function grows. Once code exceeds these parameters it becomes nearly impossible to test or modify without breaking something and you end up with what I would call a hostile coding environment. There are even more extreme examples of clean code supporters that will tell you that your functions should never be longer than 10 lines and your files should fit on one screen without a scroll bar popping up.

Unfortunately, code much like life rarely has happy endings. There is no Jesus code, but we can do our best to reach perfection by studying the great code and the coders who have come before us. Read more open source code and learn what makes code easier to read. Try to implement the styles of good code you read in open source projects. If you see something that is unclear or written poorly, remember the coder’s mistake and don’t repeat it or perhaps submit a pull request to help them clarify the code and most likely they will be grateful for the help. And lastly, read the books that will make you a great coder such as “Clean Code” by Robert Martin and “Code Complete” by Steve McConnell. As long as software developers strive for perfection in their code readability and are willing to fight for a cleaner more functional environment then we can all help to make coding great again.

Coding since 10yrs old, Thomas is a rare crossover from video games to coding.  A strong advocate of clean code, his favourite book is ‘Clean Code’ by James O. Coplien, he loves learning new software technologies and learning to code better in his spare time.