Thursday, March 01, 2012

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.

3 Comments:

Blogger Griffin "THE EMPIRE" Smith said...

I totally agree. I think art is most powerful not when it's hanging in a museum but when it's at work making our daily grind...prettier. KEEP BLOGGING WILEY!

3/02/2012 04:18:00 PM  
Blogger BCPenick said...

Those look to me to be very different things. Without seeing your database the 2nd set of code suggests to me that you are testing a boolean value. But the 3rd set of code might be testing an enum or string value which, currently(?), only has two choices. Even if I assume the value is boolean for the 3rd set of code also, they would behave very differently if "student-athlete" is NULL (assuming the language allows for it).
My personal view on whether the code below the if and the else need to be related is that they don't need to be related at all. As long as its clear that you want two different actions to happens based off a test on the value of student-athlete.

3/08/2012 04:02:00 PM  
Anonymous Steve F said...

I agree with ya. Doing those kinds of random logic branches may initially be easy and convenient, but often gets very difficult to maintain and follow over time - I know i'm guilty of doing it myself and usually regret it later. Very unrelated If/Else pairs are usually a warning sign you're putting functionality/making decisions in the wrong place.

3/11/2012 05:40:00 PM  

Post a Comment

Links to this post:

Create a Link

<< Home