Where's the meaningless(?) code? > 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 > > > ________________________________________________________________ Please visit a saintly hero: http://www.jakemoore.org
