Subj : Re: Is well written code a rare species ? To : comp.programming From : Roger Willcocks Date : Sat Aug 13 2005 12:07 pm "John" wrote in message news:2D6Le.18536$6d4.1418637@news20.bellglobal.com... > > "Anonymous George" wrote in message > news:pan.2005.08.12.17.56.50.318008@somewhere.nu... >> Good day everyone, >> >> This is my second job now. By now, in my 10 year career, >> I have had to maintain some programs that were written >> by others. Most of those programs were badly written. >> Global variables all over the place, way too long functions >> with hardly any useful comments, badly chosen function names, >> you name it. >> >> Is bad programming common practice ? >> Is well written code a rare species ? >> >> I ask this, because I want to know if I should change >> myself or if I should just go to another employer. >> My current job is driving me crazy, because it takes so much >> effort to do even the simplest modification to the application. >> >> And how can I learn during a job interview whether the company's >> product has high quality source code ? I know every company will >> say that about themselves. > > Hi George, > > IMHO; ugly code is everywhere. > > I believe there is a many reasons for this : > > 1. Consultants who never maintain thier own code. I know there are > probably some good consultants out there, but I'm willing to bet they > agree with this statement. > > 2. Programmers who don't understand the code they are maintaining. > > 3. Deadlines undermining the programmers better judgement. > > 4. Project evolution turning a good design into a bad one. Either over > the course of many years, or months if the requirements/specs weren't done > correctly. > > 5. Weak programming culture. > > 6. The fastest coders are rewarded, even when they cause most of the > maintainence work ... because nobody watches who created the bug. > > I believe reason #1 is the biggest problem. > > Test driven development may help eliviate enforce cleaner code. I think time pressures and laziness play their part too. When I'm writing something tricky (*), I sometimes write very ugly code with lots of global variables, misnamed variables, commented out and misleading code and a liberal use of goto. But once I understand what it is that I'm trying to do, I'll do some very heavy refactoring to de-uglify the code. It still does the same thing, but other people (and me in a few months) stand at least some hope of understanding what's going on. The notion of what's ugly and what's not is an open question, but I've seen quite a few examples of code where the writer just stops when it 'works', for some value of 'works'. Knowing what it is, exactly, that the code is trying to achieve is important, as is having good test data. -- Roger (*) for instance, 'read the on-screen timecode from an mpeg encoded video' for which I tried several approaches and heuristics. .