Coding for Co-Workers, part 4
This is the fourth post in a series about writing code for my co-workers. Here are parts one, two, and three.
Coding conventions
For the past two weeks, I have been posting about writing code for your coworker. The idea behind this is that if you are hit by a bus this afternoon, your coworker should be able to take over your work tomorrow morning. Your code should be so clear and navigable so that he could take over at once.
This is also where coding conventions come in. The objective of coding rules is to reduce confusion among the developers. The key to that is consistency: consistency throughout a project, between projects and between authors. A coding standard will contain stuff like:
- Where to put your braces,
- How many spaces in a tab,
- Keep tabs or replace them with spaces,
- What is the standard preamble for all your source files (i.e. the copyright etc.),
- Your naming conventions,
- What is the order of the members of your class (i.e. variables first, then the constructors, followed by properties, etc),
- etc…
The choices you make in the standard are not really important: code will not perform better or worse because of it. You can have a field day discussing it, though, because everybody has his own opinion about brace placement, and every developer thinks his way is best. At a former company, I once spent one week talking about this stuff. That’s why it is best to let one person create a coding standard, and let all developers pledge allegiance to it.
What is important, however, is to adhere to the standard. Again: you’re doing it for your coworkers: they can find their way and fit in easier with a coding standard.