>>One of the popular C magazines used to have a regular feature called "Obfuscated C". The challenge was to decipher a block, or even sometimes a line, of C code and describe what it was doing. And this magazine was aimed at serious developers! I have always liked Tamar's description of C as a "write only language."
>>
>>I'm sure it's possible to write C/C++ code that is as clear as a bell. But the language and the culture that surrounds it seems to encourage dense, hard to understand code. "Look, Ma, no hands!"
>
>As the main target area of C/C++ is much more perf oriented this is understandable. I wrote C in a very "pascal/modula" way right down to using #defined replacements - in retrospect a mistake, as that put of the pure C devs. But the code was as readable as pascal. But in a crunch (which happens in less than 5% of the code) walking pointers gives you mmore punch, and even in any language you'll see perf oriented coding where it is not necessary. I myself aim for at least 90% "clean" code written at the outset - but it is also beneficial if you don't have to optimize later. But there are vfp devs proud of writing 10 lines of code just NOT to use an eval or & - which is ok in heavily looped scenarios but not in the start of the application object.
>
>regards
>
>thomas


You're right, there is often a trade-off between performance and readability. Agreed also that C is often used for apps where performance is critical. My approach is to keep the code as readable and maintainable as possible, then go into the trick book when performance becomes an issue. This probably stems from my first training with relational database coding (DB2) -- start out with pure 3NF and compromise only when performance becomes an issue.