Code Indentation Density

I once worked in a VB6 shop where we had one developer insist that a tab in the code editor was 3 spaces and not 5 like the rest of us were using.  It was no big deal until someone else had to work on his code.  As it turned out, the developer left after a year and we had to extend everything he ever worked on in addition to the inevitable bug fixes.  I think we generated enough hatred for that one developer to last a lifetime because not only did we have to fix his buggy code but we had to reformat it too.

The Real Studio code editor handles indentation for you and you have no control over it.  I know some hate that but I’m okay with it.  It enforces consistency across source code so that it all reads the same.  As someone who reads and edits a lot of Other Peoples Code (OPC) I can appreciate that.

The Real Studio IDE puts in visual indicators (lines) for loops.  This is convenient but I’ve found that once I get past three layers of nested If-Then or For-Next or While loops it gets harder to read.  Perhaps that just me but I suspect that others have the same issue.

Take this first (totally contrived and nonensensical) example:

Real StudioScreenSnapz001


It’s not an exceptionally hard method to figure out.  First we check that our array has content.  Then if we have only one item we do something and if we have more than one we iterate through them and do some processing and finally return true.

Towards the bottom of the method where we’re using the For Next loop to process the items I find myself having to highlight the loop so I can visually keep it straight in my mind.  I decided to rewrite it a bit to the following:

Real StudioScreenSnapz002

The only difference is that I immediately bail and return from the method if I have nothing in my array.  It cuts down on my indention nesting by one level ands thus makes it easier to read (in my opinion).

This got me thinking about what else I could do to reduce the indent density.  So I tried this:

Real StudioScreenSnapz003

Switching from the If-Then-Else structure to a Select-Case makes it less dense.  I don’t know about you but I generally don’t think about a Select-Case statement when dealing with array processing.  Perhaps that is because I don’t generally care if I have only one item in the array or not as in this case.

In some situations there’s simply no way around huge complex nested loops and if-then statements.  What I tend to do is take my innermost loops and convert then into their own functions and name them something that makes total sense (to me at least).  If that means a function is named “These_Are_Not_The_Droids_You_Are_Looking_For” that’s okay.  It eliminates one or more levels of nested code.

Regardless, making your code easier to read should be a goal in life.  Making code less dense and easier to understand will aid that process.  Of course comments can help but to each their own on that.  White space can help too.  Remember:  you’re not coding just for now or five weeks from now but for five years from now.

I hope everyone has had a good holiday season so far.  I’ve been enjoying my time off by —- coding, of course!


Loop Variables

A subscriber to my Real Studio training videos sent me an email the other day asking me why I did something in the videos.  He was asking why I did this

for i as integer = 0 to ar.ubound

rather than

dim i as integer

for i = 0 to ar.ubound

I had no real answer except that it’s a little less typing and that the variable, i, can’t be used outside of the for next loop.

The subscriber went on to say that he tested both for speed and that there’s essentially no difference between the two versions.  That has been my experience too.

I initially was very against this ‘shorthand’ method.  It was introduced to me by my senior developer, Seth, and it just looked…odd.  I think at one point I might have even emailed him to ask him to stop doing it.  After a brief discussion he convinced me it didn’t matter to him but if I really wanted him to go back to the other method he could.

To make a long story short, I tried it out for a week and I discovered that I really prefer it to the other way and I’ve used it consistently ever since.  It’s a bit less typing.  I don’t know about you but I am essentially a lazy programmer so anything that means less typing is good for me.

The second reason is that when you declare the variable in the for next loop the variable is local only to the loop.  This means I can’t reuse it outside of the loop by accident.  If I declare the variable outside the loop I can use it again (sometimes by accident).  Of course, there are times you actually WANT to reuse the variable but I find those rare.

The other thing that I tend to do is reuse the same loop variable time and time again even in the same method.  So I get code like this:

for i as integer = 0 to ar.ubound
   //Do something in this loop

//Some other code

for i as integer = 0 to iMax
   //Do something in this loop

//Wrap up the function

I find this to be very readable (though I’m not doing anything in these examples). ‘i’ is my default loop variable and I think I’ve had entire apps where my only loop variable is i even though I’ve had thousands of for next loops.

Anyway, given the recent discussion on standards, I thought I’d ask what you do?  Do you have a preference?  Do you despise one over the other?  Does it really matter to you?

Happy coding!