And I assume so does anybody else who creates software. I can say with almost certainty that any non-trivial piece of code contains errors, and many trivial pieces do too. The act of writing a piece of software must produce bugs. There is a mysterious entity which has escaped the grasp of many a programmer, and some disagree what it looks like or how it operates. For decades many a programmer has strived to replicate this strange and foreign entity. Many have failed, perhaps some have succeeded. However, most often, no-one can agree that the entity found is the entity in question. I am of course talking about Good Code.
Good Code. What is it? Where does it come from? How does it work? Good Code is strange and mysterious. Those who write Good Code never seem to make errors, never have to repeat themselves, can reuse their functions and their libraries with no modification, can be read and understood by everyone, and operates at a speed rivaling that of no other.
If your language does not have
(templates|type safety|tail calls|high level abstraction|simplicity|object orientated programming) then you can not write Good Code. These constructs will introduce errors into your code and make things (difficult to read|hard to debug|unable to unit test|into spaghetti code). You should never use (goto|break|void*|pointers in general|regex to parse HTML|macros|Perl) in Good Code. It simply cannot be done. Instead you should always use (C|C++|Haskell|Lisp|an object orientated design|a functional design)Good Code is always formatted well. You must always use
(tabs|spaces) for indentation, and it should always be (2 spaces|4 spaces|8 spaces) wide. Variable names must be (camelcased|CamelCased|camelCased), and function names must be (amelcased|CamelCased|camelCased). Variable names must be descriptive but not verbose. Code should be self commenting, but you should always write comments.When creating objects make sure they always follow
(the rule of threes|the rule of fives|RAII|composition over inheritance) so that they never (have to be written in C++|throw erros|have performance overhead|can be destructed) and always (can be reused|throws errors|allocated in the stack|allocated on the heap).You should always carefully plan your code, but leave it open for change. You should always separate the implementation from the interface, so you can isolate code, but never write boilerplate getters and setters. You should always write code that can be reused, but never use
(templates|macros|void*|a type unsafe language). These constructs create code which is hard to debug and carries a performance overhead with the compiler and/or the runtime.I have searched and searched for code which is Good Code, and have even tried writing it myself. But for all the searching, I'm not sure I have found it, or what it would look like if I did. I have thus concluded with the end of this post, that Good Code simply does not exist.
