Recently, I wrote about The First Rule of Software Development. While it's central tenant is complete and covers the main point I was trying to express to my students, there were two more than I pounded them on. The second idea is really pretty simple:
Consistency
This is the second version of this article. I didn't publish the first but I originally talked about the value of Coding Standards, naming conventions for database tables, and other related things. I attacked the question of even though everyone knows they should use these things… but many don't. Why is that?
Then this week, I took a flight from O'Hare to Sea-Tac and listened to the Air Traffic Control channel for the final hour. I went in knowing our aircraft's call sign and that's it.
I heard streams of seemingly random numbers.
I heard names of locations.
I heard longer streams of seemingly random numbers.
I'm not a pilot and never have been, but in just a few minutes, I was able to pick out some key details. I was able to identify other planes and their call signs. I was able to pick out that the pilots and towers were communicating just a few key pieces of information: altitude, heading (direction they're going), speed, and position relative to other things (airports, other planes, etc). The pilots are able to quickly communicate vital information to one another and to air traffic control with minimal explanation.
And that's why Consistency is key.
As your time passes, your team will change. You'll come upon others' code. You'll have to fix or update your own code from months or years ago. The more consistent that it is across the team, the easier and faster it will be to understand and eventually expand upon.
Consistency in your development process will help set expectations. Your developers will know a request has had a certain amount of vetting, prioritization, and review. Your customers, team members, etc will have better understanding of timing, requirements, etc.
Consistency in your coding standard will help communication within the team. I know, everyone hates coding standards and argue whether it should be
tabs vs spaces and curly brace on the same line vs the next line or camelCase vs separated_by_underscores. Whatever. It doesn't matter as long as you use one, preferably a mainstream one*.
The ability to not have to think about the basics or re-figure something out the 28th time. The verbal/mental short hand is what we want. It allows the same code to be passed from developer to developer and the basics are understood immediately.
* And for the record, I think the vast majority of the time, going with a publicly available/established coding standard makes the most sense. Many languages have tools to validate code against a standard – PHP has CodeSniffer to handle PEAR, WordPress, and Kohana. If you choose to create your own standard, you lose this advantage.