Even if you have years of experience, you should look through this list. It may contain the reason why your co-workers laugh about you in the coffee room… maybe the reason they’re campaigning to have you replaced.
If you are guilty of any of these things without remorse, you may be considered a “permanent beginner”.
“When the application exits, all the resources are reclaimed anyway. Who cares if a small amount of memory isn’t explicitly freed by the application?”
Consider what happens when you have an insidious, slow memory leak, that gradually makes your application unusable.
You turn on an allocation mapper, which you expect will point directly to the problem allocation after the program exits. But what you see is—thousands of little crap allocations that sloppy programmers have left laying around, because it “doesn’t matter”.
The powerful tool that would have immediately pointed out the problem is rendered almost useless due to carelessness. A needle has been rendered a needle in a haystack.
Days or even weeks may be wasted.
What to do if your code allocates in bad ways? Unfortunately, the problem is usually a matter of re-structuring the code that does the allocation. Usually such code is undocumented spaghetti, which actually does something rather unlike what anybody would ever want it to do. On the other hand, it probably contains other bugs that are hard to see for the same reasons—so it is a good thing to re-write it. But that will necessarily involve re-thinking it too.
“They’re just warnings—they’re harmless”
“Real programmers don’t care about warnings.”
“Our policy is to turn all warnings off.”
“Warnings! Ha ha ha ha!”
One of those warnings points out a bug that causes an awful, erratic misbehavior in your program. But you can’t see the warning, because it’s buried under heaps of other warnings. A powerful tool has been rendered almost useless because of carelessness. Again, a needle has been rendered a needle in a haystack.
If from the beginning you write code that compiles cleanly, then when you see a warning, you look at it right away, and also maybe fix a bug.
What if your code causes lots of warnings? Fortunately, it’s not usually too hard to eliminate warnings. Even if there are thousands, most are repetitions of others, and usually, a warning is fixed without having to re-structure the code.
My personal experience with codes of a few tens of thousands of lines is that, it’s about an afternoon’s work to eliminate all warnings. (And usually, the effort turns up a couple of ugly bugs.)
“Johnny is so smart, nobody can understand his computer code!”
Some computer programmers think of their job as an act of tricking a computer into doing what they want.
But, if it were just about trickery, we could do the trick even better using machine language. Why do we use high-level programming languages?
To be effective in the real world, we must communicate not just to a computer, but to other people (including ourselves, at a later date). Computer programming is as much about communicating an idea to the reader of the code, as about making the computer do what you want.
What to do about poorly written code?
Write better for the next project!
Your code should reflect as much as possible what you mean for the code to do.
“Say what you mean, simply and directly”
—Brian Kernighan
Your code should read directly as the concepts in the problem your program is meant to solve. This is as opposed to code that is all about how you implemented the concepts.
For instance, you have a list of things which the program should use and manipulate. If throughout your program, the code concerning the list is mostly about how you implemented the list (as an array, or a linked list, or a hash, etc.) than your code is not about the list, it’s about your implementation of the list.
“We’ll document it after the next beta release.”
“I’m a programmer, not a writer!”
“If you want a manual, you can write one yourself!”
If you can’t write down what it does, you don’t know what it does. If you have any integrity, you should offer your resignation. But of course you don’t and won’t. Documenting your code is like giving stuff away, like giving away your precious power. Why would you do that?
What to do about undocumented code?
A large, undocumented project is just junk. In the end that’s a good thing, because the absence of documentation will hasten its replacement. In the short term, for the users and maintainers, it’s sheer hell.
The right thing to do is to document a project from the start, and keep documenting it as you go. The documentation doesn’t always have to be perfect or beautiful, just reasonably complete and accurate.
Well-written initial specifications can become a user’s guide, and there are plenty of code-documentation mechanisms that facilitate a maintainer’s guide.