Tag Archives: programming

What if bad code was discouraged on a language level?

Stumbling upon code that is messy, incoherent and less reusable than one would like is more of a rule of programming than the exception. I’ve always wondered why that is — haven’t we all been taught to properly comment, refactor and modularise code where possible? Don’t we see the value in making code maintainable, reusable and easy to comprehend?

I’ve been thinking about ways to rectify this problem, and have come to the conclusion that this is something that should be enforced on the programming language level. I arrive at this conclusion because despite good education, the use of code style guides and lint (code analysis) tools, crap code is still something that I encounter on a daily basis. Why not make it so that code will not compile or even run until you have adhered to a set of rules promoting reusable, readable and maintainable code? Think of a scenario in which a language would make the following mandatory:

  • All function/methods must have a comment that is non-empty.
  • Variable names must be longer than one character.
  • Functions/methods may not exceed, say, 15 lines of source code (promoting the use of smaller, more reusable blocks of code).
  • if or else clauses too deeply nested are not allowed.
  • Identical or almost identical code blocks across multiple source code files are not permitted.
  • Non-trivial assertions must be used at the beginning or end of complex functions.

The aforementioned rules are ones off the top of my head — there are certainly many, many more. What if there was a new programming language designed from the ground up to enforce such rules? Better still, why not retrofit them into an existing popular language[1]?

I’m talking about this subject as if it would be a simple thing to do, but despite not being a language designer, I can see that this is in fact a very hard problem to solve. Modifying a language to enforce such rules means changing the grammar of the language, which in and of itself is tricky. It ¬†would probably also make semantic analysis more complex. But above all, it will make a language known for its flexibility less so.

Still, I believe that the pros outweigh the cons in this case. In fact, I believe that until key software quality attributes are enforced on a language level, we will still continue to see an abundance of bad code. I suspect that even the most seasoned programmers write bad code on occasion — I know that if someone gives me a large piece of bad code and asks me to implement a feature, I won’t feel motivated to make large structural changes even though I know better.

It’s not that us programmers are lazy, it’s that we are humans — prone to making mistakes, showcasing bad judgement and sometimes not seeing the value in trying to make every single line of code the very best it can be.

  1. I know that there are languages that do this, but I haven’t found one that does it all the way. []