Subj : Re: Is well written code a rare species ?
To   : comp.programming
From : Scott Moore
Date : Fri Aug 12 2005 03:08 pm

Anonymous George wrote:
> 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 ?

Yes. However, most shops (apparently) consider themselves to be "good"
coders, when they have one comment for 40 lines of code or so, may or
may not have a function header or file header, lots of globals, etc., etc.
The basic idea here is that people's idea of what is "good" code varies
quite a bit. I have had it asserted to me, several times in fact, that
NO comments on a program is Ok if the program is otherwise structured
correctly and/or has "meaningful" variable/function names.

> Is well written code a rare species ?

Yes. But that's a personal opinion.

> 
> 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.

Most programmers I know are fixing poorly written applications
that were created long ago. It takes a lot more effort and time
to maintain an application that to create it, and with job mobility
what it is, chances are good the original authors have left the
company.

You can either consider this to be a a bad thing about the industry
that traps programmers in dead end jobs, or you can consider this
the reason you get paid.

> 
> 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.

I came from one company that had a disaster of a code base. They
got bought, and the company that bought them ended up throwing out
all their code, it was that bad. For example, they didn't use
subroutine calls because the original author decided calls were
too expensive on that processor. The code was one huge, long
section of assembly code with spagetti branching.

The next places I interviewed with, I told them this, and asked to
look at their code to see what I was getting into. This "technique"
of mine generated a few fights and bad feelings during the interviews,
but one company did show me some of their code. It was awful, and
they admitted it. I didn't end up working there.

In the end, I decided that judging the people there, and assessing
if they were willing to change was more important than trying to
find out if they wrote bad code. The simple question of that can
cause you not to get a position, since you come off as arrogant
and argumentative.

One other method I use that works quite well is to show them some
of my example code, then gently prod them if their code is better
or worse commented/structured than your example. You should be
showing examples in any case if you are a junior to medium level
programmer. Senior programmers (like me) don't do this, and they
would think it odd if you did. They assume you know how to code,
and are more interested in bigger issues.

I started in programming when assembly language was king, and I saw
some amazing messes written in assembly. Now, with everything
(in my end of the business, anyway) written in C, at least some
basic structure is forced onto the code.

My basic take on your difficulties is this: if you want clean code
in the world, then make it.

Its that simple.

> 
> Ciao
> 
> Anonymous George

.