Think more, react less
First off, I'd like to thank everyone for their comments. The editorial was meant to be somewhat controversial, but was more intended to solicit opinions on these things. Now that many people have had the chance to read and comment, I'll address some of your comments and ideas.
As many of you explained your own coding standards, you do share the same fundamental view I was trying to express -- bad variable naming or function naming = bad code. However, a lot of you argued that when I said coding standards shouldn't apply to naming, this was a bad idea, with examples of "get_c" versus "get_count" and such. This is exactly my point: bad naming = bad code. But more than the reaction of bad code, bad naming = bad programming = bad programmer. The coding standard shouldn't have to even address this issue -- the naming of variables and such should be correct and intuitive to everyone from the outset. Therefore, no, a coding standard shouldn't enforce a certain type of naming convention. We all recognize that "get_c" isn't a good idea. So why write it in the first place?
Let's talk a little more about case styles. In many cases, people argue that variables should always be "DayCount" or "day_count", one or the other. In real, complex examples, sometimes it's best to mix styles. You may receive source code from a vendor with functions such as "i2c_write()" -- in fact, you may have hundreds of functions and variables using the "x_y_z" convention. In order to distinguish your code from theirs, it's quite common to use the opposite in your own so a cursory glance will tell you if the function being called is vendor-provided or company-generated.
I agree that across a project, there should be an agreement to some things in style (indentation, does the company use DayCount or day_count, etc), but all too often the "Standards" go way too far. A standard is only put in place to address problems; in this case, it's a work-around to a fundamental issue that very few programmers are capable of being consistent with themselves, let alone others, in naming and style.
How many of you use multiple styles depending on what you're coding and the nature of the system? I maintain about 4 different styles I use on a regular basis. It takes a lot of effort not to mix them up. But then, I'm working on large projects of complex interactions with multi-threaded issues, making a complex application with a variety of vendor provided source routines for hardware access. It's a different world, but the problems are common.
As for Hungarian Notation, the examples I used were from the original work by Simonyi, as you can find at various places on the web or in publications. I won't profess to like it or be particularly expert in it, but as everyone points to the original work as the fount of HN, my examples should be HN. If there have been later distinctions between HN and type-based naming, hopefully an effort will be spent to distinguish between the two. Can anyone provide complete simple and complex examples of each?
What I'm getting at:
HN, other naming conventions, and coding styles exist and probably will for quite some time. But the fundamental REASON they exist is because we, programmers, are incoherent. We are lazy, too, and that makes things worse. Until we are ready to agree to a certain amount of responsibility for ourselves, these types of nonsense "patches" will be forced upon us.
And for those who complain that the big drawback of HN is that a variable that was once "puchData" and is now really "piData" -- yet the code wasn't changed to convert all puchData to piData -- I rest my case. The person doing the change was lazy, and didn't take the responsibility they should have. While this continues, we're all going to be subject to idiot managers (pointy-hair types) telling us how to do things.
The issue raised about whether companyX's proprietary coding style could be copyright/patented -- this is a very valid question. And a very scary one. It's not impossible -- hell, they can patent/copyright that "Ctrl-C" is "Copy", so why not programming style? Or a language itself? An interesting area to think about...
And while it's frequent to find buggy implementations of operations in different platforms, sprintf() will never change from one system to another. Putting a wrapper on it buys you nothing. It's ANSI and ISO defined in parameters, format, etc. You may change compilers, but you won't change the call. If you replace sprintf() with your own for some reason, you shouldn't call it sprintf() in the first place -- this will lead to unnecessary confusion.
I agree that contractors and even corporate programmers must live in their environments. I constantly am working under some company's format, and it's irksome to find no two companies like things the same way. Mostly, I want everyone to stop and think --
Why did these things get developed in the first place?
If they're a "good" thing, then why the hell aren't we doing this on our own?
Why do we let non-technical people make up our coding standards?
What are the REAL issues behind why these got started?
How can we address these REAL issues?
Think about it.
One final comment, for "Mauro":
My knowledge of mathematics is rather good, IMHO. A theorem, if you'll recall, is an item that has yet to be disproven. You have confused a Theorem with an Axiom. An Axiom is an item which has been proven and can not be disproven -- ever. A theorem is something which has been postulated, but has yet to be proven absolutely. The only restriction to a theorem is that it must have all assumptions explicitly listed. At the time of writing, my inflammatory statements were yet to be proven false (and still are, I might add), therefore qualified as "Theorems"... Granted, they are opinions, are it would be ungainly to run around all day to precede any comments you make with "My new Theorem is ...", however, it would be technically correct. The funny thing is, everything is an opinion. 2+2=4 is an opinion, and assumes a lot of information about the underlying set, but isn't always true. It's just an opinion that it usally is.