Reading BEGIN/END or { } or something else is just a question of experience. When you get used to it, your eyes stops looking at characters to read (even if eyes or monitor fails to produce sharp, legible characters). You just get a mental image about a block start in whatever format your brain chooses to express such a concept. The bad thing is of course that someone writing a parenthese (OCR-scanning some source code?) there instead, will trig my brain into accepting a block :)

On the other hand - it doesn't really matter if someone manages to fool my brain with such tricks. The compiler will catch it, without any possibility of any danger.



It might be possible that people with their first 4 weeks of experience with C/C++ do write cryptic code. These people will learn, as they gain more experience.


Some few do it because they think it is cool. They are normally not much older than the SMS junkies that visists these forums regularly and expects to be considered cool if they can average 2..3 characters/word. Any company run by competent people will give them two choices. Start writing real code yesterday, or walk out the door (and possibly a silent hint at a third option - to get thrown out a window...)

These guys mostly represents a problem on the net. They like to exhibit their code on own and other peoples forums, and they like to register themselves on any "rent-a-coder" site as programming experts ready to take on programming tasks. The good thing is that it is so easy to screen them - since they are exhibitionists, it is enough to ask them to post one sample of the programming skillz ;)



Some write cryptic code because they think they know C, but hasn't really learned the language yet so they end up with the first rewrite that finally manages to produce the result that they think represents a correct application. Huge number of forgotten variables. Functions with one name but different functionality. Evaluations that are later thrown away because the original code was either part of a test printout, or a non-working try at getting the correct results.

The bad part with these guys is that since they think they know C, they don't see a need to improve. It is so easy to not know what you don't know. They often like to write on forums about how hard C is - just because that helps them feel good, knowing that they must be way above average for knowing C so well...



Most do it because they do not know better. They may actually do know C quite well, always being able to write correct with correct precedence between operators etcetera. They may possibly be described as technically proficient but not artistically. They have never managed to learn how to organize the code and edit it into a natural flow, a problem they would have in any language.

The problem here is to get them to open the door and notice a much larger world on the outside. They can't really be helped by yet one more book with the language definitions, since they already do know the definitiosn. They need to go looking at paintings instead. They need to see real-world programs written by truly good programmers, and see that besides writing correct applications, you can go one step further and write beautiful programs. Programs that a junior developer can take over and still manage to maintain. Programs that can run efficient but at the same time validate internal assumptions and emit errors in case a code change suddenly starts to break that assumption.



Many developers also misses all the little check-list rules that helps.

They don't know that you should strive for locality-of-reference with local variables close to their use instead of large numbers of global variables.

They don't know that similar variables should be grouped into structures.

They don't realize that "if (0 == variable)" instead of "if (variable == 0)" has the advantage that the compiler will refuce to compile if they make the common mistake of writing "=" instead of "==".

They use #define when enum or const int may be better.

They forget to const-declare function parameters or methods.

They forget the use of file-local static variables.

They don't look into smart C++ pointers that will automatically reference-count memory.

They don't design factory functions for creating dynamic objects, allowing them to control if a specific object should be a singleton or may have multiple instances.

They don't use snprintf instead of sprintf to avoid buffer overflows.

They forget about the excellent warnings most modern C compilers can help with, and that the waring system can be made even better if the code is written using suitable design rules.

...



It doesn't matter what language someone is using. What this world lacks is a good clearing house that people could visit to get links to "known good" source code to read. Reading properly crafted code is probably the fastest way to learn exactly how a programming language should be used to give programs that are easy to maintain (which implies that they are also easy to read).

But "easy to read" is not equivalent with "totally littered with comments". Everything can not be expressed in the normal language constructs - such as the reason why a delay is 150ms - but quite a lot can be self-documented. Maybe 95% of thw "what" can be self-documented. The "why" can seldom be self-documented.

Too much comments results in a reduced sw quality. On one hand, you get too much text to read, so you lose the focus. On the other hand - what to do if the comment says one thing and the code does something else? You can't really maintain larger sets of comments, while the compiler together with black-box and system testing can be used to verify/validate the actual code.