On Thu, 2009-12-17 at 10:40 -0700, Joel Dice wrote: > On Thu, 17 Dec 2009, Bob Plantz wrote: > > > > > > > I have seen many, many examples, both in industry and in academia, where > > programmers write tricky code claiming it is more efficient. I claim (a) > > efficiency is seldom an issue, and (b) looking at the generated assembly > > language almost always shows it is not more efficient. > > > > I believe that the best code is that which (a) correctly solves the > > problem, and (b) is the most simple-minded in appearance. > > Perhaps, but the code in question here is not merely obscure - it's simply > meaningless. I think it's a mistake to put such code in the same category > as e.g. an affine transform implemented in inline assembly which has > well-defined meaning. The latter may pose a challenge for a maintenance > programmer, but at least it will yield to persistence. In contrast, > undefined code is no better than a "todo" comment - you're only option is > to replace it completely with something well-defined based on the > documentation and/or context. > I agree that there are situations where obscure code is the best, perhaps the only, way to solve the problem. For example, in 1984 I had a consulting job where one of my assignments was to write a logarithm function for an embedded MC68000 environment. The only way I could get the required speed and accuracy was to use double-precision integer arithmetic. I wrote it in assembly language and used several "magic numbers" to keep intermediate values in range while maximizing arithmetic significance. My comments took more space in the listing than the actual code. To their credit, the programming team asked for even more documentation during my walk-through of my code. These situations are uncommon -- and lots of fun to solve! The most common uses of obscure code that I've seen are programmers showing off their "understanding" of the language being used. I believe that a good programmer does not ask what his/her code does, but rather explains it -- either through simple, easy-to-read code, or with thorough commenting. I use the term "good" to mean relative to the programmer's skill level. --Bob
