The Natural Language Naming Convention
Doesn't using The Natural Language Naming Convention make you do a lot of extra typing?
Do Long Identifiers Slow Program Execution?
Is The Natural Language Naming Convention difficult to learn?
What's Wrong with Module Headers?
Can you adapt The Natural Language Naming Convention for C programming?
Most emphatically not! One of the reasons for the development of The Natural Language Naming Convention is to reduce the amount of typing that you have to do. A simple count of the characters between well-written programs using any two systems demonstrates clearly which system requires fewer characters. The additional comments required for cryptographic naming conventions account for this difference.
The savings with a readable system go beyond simple character counts, however. Because the code is so easily understood, it is more likely to be right the first time. And the effort savings at maintenance time is even more significant. How many times have you had to rewrite an entire routine because you had no idea how it worked? A significant amount of typing is saved if you can do something once and be done with it. Furthermore, readable, well-organized code is more likely to be re-used.
Besides, typing is less than one percent of the effort of creating a piece of software. If typing was as much a part of their job as many programmers make it out to be, they'd be put out of their jobs in no time by any reasonably competent secretary.
In an interpreted language, this is a possibility. It should not be a problem with any compiled language because the compiler will choose its own representation for all of your objects.
Not if you are fluent in your customer's natural language. The rules are simple and few, and all are structured to encourage well-engineered software.
Like any system, there is an adaptation period. First, you must want to make the change, and then it takes time to become skilled at the new methods. Some people will pick it up faster than others.
It all comes down to purpose. We want to make it as cheap and easy as possible to create and maintain our software. Increasing the readability of your code decreases the cost of all subsequent software development activities.
Microsoft's standard was developed in an environment with extremely short identifiers and intense memory limitations. It had to be cryptographic to contain any information at all. Considering the limitations of that environment, Microsoft's standard solved a lot of problems. Fortunately, that environment is no longer the norm.
Today, we have longer identifiers and program are much larger and more complex. Memory is still a problem, but it is a different kind of problem now. The problems are different; so is the needed solution.
If you are a programmer, you want to be as productive and as valuable as possible. Adopting a highly readable naming standard is one of the most effective steps you can take in that direction.
For software development managers, the benefits are broad and deep. First, you can actually read the code and see what it does. How many managers of programmers can say that today? Second, you can move a programmer from one module to another, and the new programmer doesn't need to spend six weeks figuring out what the previous programmer did. Third, as a manager you know that your real costs are going to come in maintenance; readable code pays its biggest dividends at that time.
Sometimes you have to do what Microsoft recommends even when they are wrong. This is not one of those cases. And there are signs that even Microsoft is beginning to change.
Comments do not get maintained because the program may run perfectly well with completely erroneous information in the comments. As a result, it is so rare to find a comment that provides any meaningful indication of what is going on that the few correct comments there are will often be ignored.
This is not to mention the amount of work they are to create; lots of this work can be handled automatically with any reasonably professional configuration management system.
They encourage code ownership, they duplicate work done by the configuration management system, and they encourage sloppy names.
Certainly, but adapting it for C programmers may be beyond our grasp. This, after all, is a community that gives an award each year for the most unreadable code.