One of the first step a company must take is defining a coding standard, and stick to it. The web and books are full of coding conventions, but you might want to specializes it.
This topic is already heavily discussed in the community. Everybody comes with its naming convention, whether to use Hungarian notation or not. I would not discuss about those. For most of them, it is just taste, and I don’t discuss taste. Still I think other criteria must be taken into account.
Most Coding Standard (CS) limit themselves to describe naming convention, global usage of language features, … Those aspects are important, but I would like to introduce others. Increasing the productivity and the comfort of the programmer should be the only goals of a CS in the end. In our company, anybody can change any code ( read about our Collective ownership policy ). The CS should ease their work.
Removing noise
CS should remove all formatting’s personality of programmers, not just naming. The goal here is to remove unwanted noise. Space count, variable declaration position, method ordering, if different from one programmer to another, can create a huge noise factor. This also means that access to the logic gets harder. Getting over those differences takes brain cycles, cycles that can’t be use thinking about the problem. That does not mean programmers have no freedom, I simply prefer they express their freedom on design and algorithms. The goal is not being repressive, but to ease access to others’ code.
Parsability
The next point I consider fundamental is the parsability of a CS. In a competitive environment, productivity tools can really help being on time. Imagine the comfort of “one-click” functionality such as generating an empty test case for every method in your class, generating accessors for a variable, adding missing headers. Writing those tools can be cumbersome if the naming convention is ambiguous. I don’t want to write a fully-fledged recursive-descent C++ parser (while it can be interesting as a hobby job), I just want to create a unit test case. One requirement is then that all signatures, class name, files path should be easily found by a simple parser in most part of the code. I don’t apply this rule to low-level programming. No, I don’t parse assembly nor generate some with a tool ;-)
Universality ( in your work environment )
As the CS must be adopted by all programmers, try to keep it as a global philosophy. Never create a rule without a valid explanation. Open all rules to discussion and if it needs to be changed, don’t hesitate to do it. Include your team in the discussion, it is fundamental. Finally, you are going to live with it for a moment, so everybody must feel confortable with it.
Conclusion
At Fishing Cactus, the coding standard is part of the company’s value. Simple, efficient and adopted by everybody. While it burned the eyes for about a week, everybody gets use to it. And is productive!! Whatever coding standard you choose, ask yourself, does it stand those small points?