I’ve been programming in one context or another nearly all my life. Sometimes for fun, sometimes professionally. Even now, though programmer is not my title, I find myself programming a lot, writing programs in interpreted languages like Perl, and scripted programs in command shells like Korn/BASH. I think programming even at a simple level like scripts in Korn (modern), or BASIC (retro, possibly some modern) is an essential skill for anyone working with computers.
Needless to say the early days on the Atari 8 bit were instrumental in teaching me logic sequences that are necessary to write programs. These are so ingrained I often think in “code” especially when solving problems. In my career, when I was strictly a programmer I was exposed to a lot of other programmers writing styles, many of which I could not stand for one reason or another. I didn’t want to write the code that someone else couldn’t stand so I immersed myself in best practices books.
Two books in particular played huge roles in how I code today. Though they are older books now, they still have some great fundamental teachings. One was geared a bit toward programming in C, but much of its teachings can be directly applied to other languages. When you see any of my code, with very few exceptions, the principles I learned in these books are apparent. After you finish reading this post you’ll understand why my variables seem to start with the same letters, and a bit more about my coding style.
Both of these books are Microsoft Press books. They were both released in January of 1993. The first of which is “Writing Solid Code” by Steve Maguire. The second is “Code Complete” by Steve McConnell. I highly recommend both of these books to anyone that writes code in any language.
Here are the top three topics I learned from these books, not in any particular order of importance.
Variable Notation
One of the things you may have noticed in much of the code I’ve posted so far is how I name variables. I adopted a form of naming called Hungarian Notation in the course of reading these books. There are arguments for and against it’s use. In all the years I’ve been using it I’ve not run into any of the negatives, so I endorse it’s use. You can read more about it at this link. So why use it? In simplest terms it aids in readability, essential self commenting code.
My implementation of the notation doesn’t follow the specification exactly. In short I preface all variables with a lowercase first letter of its type, but I don’t apply the function/procedure naming in absolute terms. So a variable of type char would start with a c, one of integer would start with i. I apply to each language I code in using that languages primitive types. One thing I do that is slightly different is naming of globals. I will add a g, typically the second letter in the variable name to signify a global. The system has worked great for me, but your mileage may vary.
Comments
Likely this largest lesson I learned from these books was the value in comments. Comments in code have saved me from many hours of reverse engineering. Think you’ll write some code once and never touch it again. Ha! Good luck with that. The intrinsic value of well structured comments will be readily apparent the first time you need to touch:
- Code you wrote x years ago, say 10 for example. Will you remember or know what that specialized function does, how it works, or what data or string syntax it expects to work with many years later without any comments. Possible, but not likely.
- Code written by someone else. This I find to be the most irksome. Even if the author commented it, sometimes the comments are not descriptive enough.
Comment, comment, comment!
Debugging
Debugging can be a nightmare. It was especially hard for me to debug the 6502 Assembly code I was learning last year. I didn’t have the tools or experience to do it easily and ended up spending hours tracing through it on paper! Not ideal. The top 3 things these books taught me about debugging are:
- If the language supports it, use assertions to validate variable values. In absence of assertions, use printed output.
- If you have a debugging tool, use it to trace through code blocks.
- If you have a complex calculation, validate it with an alternative algorithm.
Links
Here are all the links from the post in one convenient location, as well as some additional relevant ones.
Hungarian Notation – The Good, The Bad, The Ugly
Unfinished Bitness 