I agree Andy. One time I was doing some significant logic and due to its nature it was very obfuscated. In line, I put comments in to fully explain what I did in that 20 lines of code. It took about 20 pages of documentation. ... I figured without it, there would be no possibility of maintenance by almost anyone once the code hit production. ... Those 20 lines took me a couple of weeks to write and test, but it was called over and over again and was at the heart of doing some complicated tax modeling for a Fortune 500 company.
Most code is not like that, thankfully. Some languages are more 'readable' than others (even 'readable languages' can be written in an obtuse manner to make them impermeable to most minds). Even in the best languages, and the best programmers, writing readable code and properly documenting it is not an easy thing to do. For me, the OO craze has made it worse, but I was raised on assembler, Fortran, PL/I, etc (Yes I did some COBOL, RPG, SNOBOL, BASIC of various dialects, and a very tiny bit of APL and LISP). OO is not inherently bad, it just made a hard task more difficult, IMHO. Others obviously disagree and since they are writing and maintaining it, I will not quibble over that point. In any language and method, efficient code is desirable, maintainable is better. On occasion efficient must override maintainable, but the amount of GOOD documentation goes up exponentially if it is to be maintainable. Andrew Farnsworth wrote: > On Thu, Nov 20, 2008 at 6:33 PM, Andrew Farnsworth <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > This is exactly the reason that I push maintainable code over > efficient code (ok, overly optimized code). It may take you a > week to write it, but it has to be maintained for years > afterwards. This basically means don't use obfuscated code or > what could be perceived that way by almost any moderately > competent programmer. > > Just keep it simple and only optimize your code where it can be > proved to be a perceivable improvement. If possible or necessary, > move the processing offline and give the end user a "Still > processing" screen until it completes. > > This does not mean you should write code that is manifestly > inefficient just to write inefficient code. Find that happy > medium but keep in mind that someone else will be maintaining it, > and tomorrow you will be maintaining their code. > > > Preemptive strike here. Yes, I know there are situations where you > really need to optimize code, such as low level hardware drivers, > database store procedures, etc. However, the vast majority of code is > not in this category and should be written to be as maintainable as > possible. Even highly optimized code should be very very well > documented, even to the point of providing a non-optimized version > that is easy to understand. > > Andy > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en -~----------~----~----~----~------~----~------~--~---
