More on Linear thinking

Yesterday, I posted on linear thinking and how it can get you into trouble when your objects are containers. If you did not read it, you can find it here. Today’s topic expands on that idea. It is yet another post in the continuining series of "back to basics" posts and another one spurred by code I have seen.
I am currently working on ACH records for credit cards. In order to translate from the type my client uses to the type their vendor uses, I have to do some translation of fields. My best map currently is the map made in the code the previous developer worked on. So far, so good.
One thing that is very difficult, however, is the developer created fields as he saw fit. In other words, I need to know a transaction type, so I do something like this:

String strTransactionType = "";
if (MerchantTransactionsReader["TXTYPE"] != DBNull
    strTransactionType = MerchantTransactionsReader[

This is still not a problem. Where it gets difficult is when I am on line 256 of the file and I find something like this:

// Authorization Response Code – 2 char
String AuthorizationResponseCode = "";
if (strTransactionType == "209") //Refund
AuthorizationResponseCode = "00";
else //any type of Sale
AuthorizationResponseCode = "88";

I know I can right click and choose go to definition, but there is an easier way to make code maintainable. And, it is something you have been taught already, if you have taken any courses on programming. Place you definitions at the top of the routine. If you do this, the maintenance developer (or the fireman fixing the burning house) can use a split screen and keep the definitions visible, as they are all in once place.
NOTE (added 3/26/2009): Per the comment left by no name – In general, most routines are short. There are a few exceptions that are valid. In this particular file, it was more split screening to see the private variables of the class to more quickly organize the load routine(s). The particular code is ultimately throw away, so the load routines are a bit longer than I would normally work with, as well. Thanks to no name, as well, for suggesting Clean Code. Will have to look at it.
In linear thinking, you declare variables throughout your routines, classes, etc. When you break from linear thinking, you think up the contract first and then put all of the like types in one location. In a routine, this means you declare your variables in one place, which is, in every book I have read, at the top of the routine.
Peace and Grace,

4 Responses to More on Linear thinking

  1. Shane says:

    I think you have a much bigger problem if your method is that long that you could actually split your screen to look at it. Time to eat someone up with a copy of "Clean Code" by Uncle Bob 🙂

  2. Shane says:

    er.. beat someone up 🙂

  3. Gregory says:

    I probably should have stated more clearly that the definitions I am talking about are the private variables for the properties of the object. Actually, with a bit more time, it would be more sane to use a code generator. :-)Peace and Grace,Greg

  4. Shane says:

    Hmmm No clue why it said No Name. I just logged in and my name is appearing. Anyway if we’re talking about class level variables then I’m all for putting them at the top. Of course here again there are practices that can be helpful here as well. Between Single Responsibility & the heuristic of looking at variable names in a class and splitting up classes when the methods & variable names have natural groupings.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: