Erik Malund wrote:
-------------------------------
Professionals create beautiful code that is crystal clear. Where is the difference ?

- - - - - - - - - - - - - - - -
Sounds like our documentation level is the same - in that we agree.

My contention is the beautiful code that is crystal clear.

Seldom have I seen the most important and clever code taking on any shape that could be described crystal clear. Its usually very involved and anything but crystal clear. The only beauty is in the breakthrough and its efficiency. Efficiency seldom makes code appear beautiful because placement of partial results and ram locations are often dependent upon the current pointers. For efficient realtime code, you don't have the luxury of placing data in beautiful places. Recent code I'm proud of even has its computational partials in split storage tables (High via R0, Low via R1) for each 8051 16 bit crunch. No beauty there but it can't run any faster and it confuses the heck out of anyone that would attempt to deassembly the algorithm. :)

An example, the last US Patent of mine was on an algorithm I did for a telecommunications company. To describe that beautiful algorithm took about 60 pages and a patent lawyer 2 years to process. The law language description was so cryptic that I included a C biased pseudo code listing for software nerds to comprehend. Nothing crystal clear there. Likewise, even though it was in the end, the most heavily documented source code I've even written, it was also the most impossible for anyone else to maintain due to the efficient data structures and network traversing algorithms.

It never hurt me that no one else could revise it more than to change the report formats around. :)

From my experience, beautiful and crystal clear only apply to simple code. Its seldom acheivable in the high end applications.

aka j