Coding standards are often left to a development team and not considered for small groups or individuals. Of course, individuals have a style of coding which is virtually their unwritten standards. Nevertheless, it is essential to create personal rules. These best practices will help you write code that performs better and is easier to maintain. That approach leads to a more professional looking (and working) end product. Better yet, proper coding standards can be used across languages and environments.
Naming Standards
An outstanding place to begin is how variables and blocks (methods, classes, functions, etc.) are called. A language has its syntax and commands, but developers can add complexity with a lousy naming scheme. You should always conform to your company or client when there is a standard in place. However, outside of those directives, here are some points to consider when using names in code.
- Be Consistent – The most crucial facet of a good standard is consistency. Use casing and abbreviations the same way in similar situations. For example, if you use “i” as an index variable for a loop, do not switch to “x’ next time and then “p” for another.
- Be Realistic – Do not abbreviate every word in a name (eg. gAValFrmSomSrc) and do not write sentences as names (eg. thisIsAVeryDescriptiveNameForAFunction). Try to keep things short, but not too short. Goldilocks should find your name lengths to be “just right.”
- Be Descriptive – Getters and setters are a prime example of a naming standard. Most are of the getX or setX format and describe the method entirely. Expand on this with methods like saveToDatabase or writeToFile. These define the primary function of the block of code.
Performance Standards
Each language has an approach to processing and memory management. Even so, there are some universal concepts across all of them.
- Put Things Up When Done – This holds for resources of all kinds. When you are done using something then release it. Do this for memory blocks, file handles, and anything else that makes sense. Sometimes it is best to null or zero out values once you are done with them just to be safe.
- Avoid Duplication of Effort – This warning applies primarily to loops, but also code blocks that may be called many times. Avoid doing work within a block that can be done once elsewhere. This work includes things like opening or closing resources, declaring variables, and computations. Keep your loops as tight and clean as possible.
- Take Only What You Need – Sometimes it is simplest to pull all the data in a row or create an instance of a class to hold a couple of values. This simplicity can be a drag on performance. Try to reduce what you request and require to only what is needed. This may require the use of flyweight patterns or multiple functions that make the same query but return different data sets. That is ok. A little more code never hurt and can make an application use fewer resources.
Documentation Standards
Use the various comment systems available. These are all valuable, whether it is code level comments or auto-generated reference documents. The tools have been created to help you, but they are no good if ignored. Learn what is available and then use the tool to provide future developers with a brief note about what code blocks do. Then look at larger structures like methods and objects. Write a little description of their use and side effects. Finally, do not be afraid to write README documents to help others learn how to build and deploy your code. If you wonder how these should look then check out the documentation provided for modern languages like Java or C#. Trust me, the developer you help most might be yourself.
Coding Standards Lead To Confidence
We have all seen code that was thrown together quickly. I bet we have all written that code at times. Although that is sometimes passable, it usually is not. Your code should look like it had thought put into it. The reader should not be thinking “spaghetti” or “obfuscated” while going over your source. This not only is confusing it makes people uncomfortable in using the program. You would not want to drive a beat-up car so why run beat-up code? I understand that standards can slow you down. However, if you make them habits, then you will write professional looking source without having to think about it. That is the ultimate win-win.
