I'm just reading Pete Goodliffe's Code Craft. I'm only at the beginning of the book and he's devoted a chapter to coding standards, reinforcing my own belief that good code presentation goes a long way towards good code.
One of the things he neglects, I believe, is adding the reason why to each specific point of the standard. This might seem like a whole bunch of unnecessary nit picking, but here me out.
I'm an inquisitive chap. I flat out refuse to accept anything anyone says as an absolute truth without some context or background. In a lot of cases, this can tell you a lot about the person making these statements.
I think providing a "why" to each rule of the standard gives context and background helping to coerce people who might otherwise be hostile to the rule, and to give those with a legitimate argument against it more of a backdrop to better formulate their argument, which could lead to a better standard in the end anyway.
For example, the underscore rule I've adopted for private/protected fields (fields considered internal to the class and it's subclasses).
I'll declare them like so (in C#):
1: protected string _firstName;
Then anything public (fields externally visible from the class) I'll declare like this:
1: public string LastName;
(Forgetting automatic properties/should I use properties at all/etc)
Now, my reasoning behind this is simple. The first part is; I don't like hungarian notation. I don't think it's relevant anymore; and people don't use it in the way it was intended to be used (scroll down to "I'm Hungary"), anyway. Not only that, it adds extra characters when you type variables that detract from the beauty of simple code. What looks better, this:
1: private string m_sFirstName;
or
1: private string _firstName;
the "m_" is redundant, as you can only have member variables in classes in .NET anyway, so there's two characters saved; and the "s" is tying the type of the data to a string. What happens if it's a string buffer and you later want to change it to a StringBuilder instance? Are you going to go through your entire code base and replace every "s" with an "sb"? If you are, you're in for a long day for a simple decision, and if you don't you're breaking the point of the hungarian and people will learn not to trust it.
The second part (and more to the point, anyway) relates to the case-sensitivity of languages. Let's say you're writing your library in C#, and one of the consumers of your library is using VB. VB is a not case-sensitive. There's no conceptual difference to VB between the two following declarations:
1: protected string firstName;
2: public string FirstName { get; set; }
The underscore is the simplest possible way to better differentiate the internal fields from the external ones.
So, there you have the why. You may already have some good arguments as to why I should change my mind, or even have a better solution to the problem. The point is, it's no longer related to ego, but an honest reason. It's not religious, and I won't be hurt if you suggest something different, as long as it also has a valid "why".
If you can't think of one, then be prepared to change it and be man (or woman) enough to admit that it was that way simply because you wanted it that way.