Sunday, December 02, 2007

One metric of a decent programmer


There are many many many metrics for figuring out if a person who can program is in any way decent.  One thing I look for when reading people's production code is how trusting they are.  Since I work in security this is something I look at from that perspective but I also think that if you want to program well you just can't trust data, period.  

Now the few people who have read my code know I don't always do this.  Why?  Well there are two reasons:
1) I never claimed I am a decent coder 
2) It is tedious work to always check your inputs 

However, I have seen some decent code and when I do they tend not to trust anything.  What does that mean?  It means you are stating the pre-conditions of your code and then checking them, be it asserts, validation checks or contracts.  

For example lets say you are expecting an ID to be passed in between the ranges of 1 and 100 the code should look like.
// Description: This is a test method
// Pre-condition: We expect an id between 1 and 100 to be passed in 
// 
// Post-condition: Our work is done
// 
// Parameters:
//    id = The id we need to use for the lookup
function junkFunction($id) {
  // Do our pre-condition check
  if(($id <>
      ($id > 100)) {
    // return error code or throw an exception
  }

  // do work since pre-conditions checked out and return
}

Why is this good?  Because there will be a smaller chance that low-hanging bugs will not surface and on top of that the programmer has to THINK more about what he is doing.  Sure it might not be as fast but most of the time that does not matter (plus performance should be done after the code is initially working and not any time before that).  

Why do I overall think this should be a metric of a decent programmer?  Because I think good programmers realize that other people (or their future selfs) will eventually look or use their code.  They can't always trust what is going to be passed in will match with the assumptions used when writing the code.  I also think it shows that the coder was actually thinking about what the function was supposed to be doing and not just doing what they were told what the function was supposed to do.  What does this mean?  It means they have to understand the business or user needs.  

Once again this isn't the one and only metric, just one that I think should be used when evaluating all coders.  

0 Comments:

Post a Comment

<< Home