A Matter of Style

Programming is often said to be as much an art as it is a science.  I agree.  As such, programmers are often faced with issues having as much to do with style as with being technically correct.  Someone with a stereotypical view of engineers may think this would cause discomfort.  And it does.  But, at least for me, that discomfort is in the opposite direction.  I occasionally write code that, while technically correct, doesn’t sit right with me in the same way that my long, rambling, comma-laden sentences don’t sit right with English majors.

Let me give you an example.

For those who don’t know, I’m the IT manager and software developer for the Auburn University Athletics Department.  As such, I often write code that deals with databases relating to student-athletes.  Today I was writing a function dealing with our study table database which includes both student-athletes and the other people who attend study table, such as tutors.  However, the function only needed to deal with student-athletes, so I wrote it thusly:

if (person is a student-athlete)
{
     do what I need to do
}

Simple, right?

Later, however, I thought of something else that needed to happen if a person was not a student-athlete.  So I added some code to my function:

if (person is a student-athlete)
{
     do what I need to do
}
else
{
   do the other thing
}

And that worked.  The program ran beautifully and did was it was supposed to do.  But I didn’t like it.  The things that needed to happen if the person was a student athlete had absolutely nothing to do with the things that needed to happen if they weren’t.  The only relationship between the if and the else was the field I was testing on.  It worked, and it made sense to me, but would it make sense to someone reviewing my code.  Even as a programming shop of one, I think about these things.

So I changed my code:

if (person is a student-athlete)
{
     do what I need to do
}

if (person is not a student-athlete)
{
     do the other thing
}

Not quite as simple.  Not quite as efficient for the compiler.  But a more accurate statement of what I was trying to accomplish.  Some may disagree with me and think that the way I originally wrote it was more artful.  It is certainly more elegant, accomplishing more functionality with less.  However I believe that clear communication of your ideas is important for any kind of art.  That’s how I code. That’s how I (try to) write.  And if you disagree, hey, that’s art.