The working world would be nice if we could only develop and maintain our own code. The reason being: we would inherently understand the concepts, work-flow, and logic within it. But like every working developer I’ve ever known, including myself, our days are filled with maintaining existing programs – sometimes a process not for the feint of heart.
As a long-time programmer, often with a staff of other programmers to watch over, I learned early in my career how important enforcing programming standards is in contributing to the overall success of a project. Not only do standards affect an individual’s production of code, but they ensure that anyone else who may contribute code later can do so with a reasonable expectation of consistency.
My own experiences have shown that while the practice of non-standard coding appears across the entire spectrum, from beginner through the seasoned professional, the vast majority of violations seem to happen with beginners, entry level or least supervised programmers. Why, one might ask? Simple! The developers’ supervisors did not live up to their responsibility of encouraging standard coding practices.
Exactly what are standard coding practices? There is no one book; no one Internet site; no one master plan that describes such standards. Oh, there are formatting standards used widely within certain circles. But for most of the on-site projects I’ve seen in my 35+ years of analysis and design there usually only exists a semi-formal standardization plan that was decided by someone, somewhere, responsible for the production of the project. It doesn’t matter what the standards are as long as they convey the expectations for coding and documentation. While rules sometimes exist to be broken, standards should change only for the better to assure the application yields even better and more consistent results.
And so, what should be standardized? The simple answer is… everything! From a project manager’s view this would include program naming conventions, field names, function names, report layouts, database layout, testing procedures, development platforms, etc. You’ll see how standardization efforts will link all the components of a project, in time, to form one homogeneous entity which becomes much more easily understood, easier to understand in the future, and also much more easily maintained.
So what does one do when there is no existing standards? Two words: create them. I will admit that creating a new standard for everything is no trivial task, but you’ll will find that the efforts will yield productive results. You don’t have to create them from scratch – many open source projects have published their standards and guidelines online and you are free to use them as the basis for your own; you can adopt one wholesale or pick and choose elements from several, whichever makes the most sense for your team. It’s not as important as what the standards are, but rather that there are standards in place.
If you are a lower level programmer, always follow any established standards. If a standard can be improved or expanded, discuss it with your supervisor who should greet your comments with enthusiasm. If you are a supervisor, welcome such suggestions. Even if you are a single person programming shop, you will benefit greatly if you take the time to create your own standards then adhere to them throughout the development of the project.
Hopefully this information will not fall on deaf ears (or eyes as the case may be). Industry experience has proven that establishing standards and adhering to them yields better production results and make day-to-day life easier because of the order that comes with them. My personal experience also tells me that once one implements and works with standards, they never turn back.
Image via oconner / Shutterstock
Robert MariottiRobert Mariotti is no stranger to the software design and services industry as he has worked in its technical trenches for over 30 years. He was co-founder, executive vice president, and chief software architect for Financial DataCorp of Glastonbury, CT, for over 20 years and was responsible for the design, development, and deployment of financial services software for the banking and credit union industries. Very much accustomed to a busy, technically challenging schedule, Bob has joined the University of Connecticut, School of Law in the Linux systems administration and web management roles. He can be reached via email at r.mariotti[at]fdcx[dot]net.
