A simple way of commenting if/else follow-up

Search DominoPower's 11,974 Lotus-related article archive

Home
EasyPrint
News details

Articles-only

Twitter Feed

CODING BASICS
A simple way of commenting if/else follow-up
By Joshua B. Jore

Erwin van Hunen's article "A simple way of commenting if/else for better understanding" in the August issue of DominoPower Magazine has generated quite a bit of feedback. This time around, we have a piece sent in by Joshua B. Jore, a Domino developer for Imation Corporation, regarding guard statements. Take it away Joshua . . .

Mr. van Hunen's recent article dealing with deeply nested conditional statements at http://www.dominopower.com/issues/issue200408/00001323001.html appeared to be lacking the mention of guard statements.

When you have a block of code you wish to run conditional on a number of criteria, perhaps with some set-up work along the way, guard statements allow for readable code instead keeping the deep nesting and trusting to yet more text to deobfuscate it.

The key here is to use Goto in a way that doesn't violate the Dijkstra's original frustrations. More on this can be found at http://c2.com/cgi/wiki?GotoConsideredHarmful, but specifically Knuth's expansion on Goto at http://pplab.snu.ac.kr/courses/PL2001/papers/p261-knuth.pdf.

Goto has a bad reputation, deservedly so, since it enables some horrible, horrible flow control. It has the ability to clarify the important parts of a program -- the code being executed for its effects over the control flow.

The key thing here is that all the uses of Goto are forward and local. There is a distinct sense of a block being skipped over, that the destination is always further down, and when code is skipped, there isn't going to be any tricky-reentering code.

I normally use this sort of construction when writing loops where there is a significant number of conditionals (more than two), or where there is a significant block (more than two lines).

The idea is to find a balance that makes the code visually pleasing, so the most important parts (the effect generating code, normally) can stand out more. The indentation effects of multiple conditionals serve to make the most important code less visible by pushing it farther away and also making it less clear.


If docCurrent Is Nothing Then

    ' The docCurrent UIDocument is not available.



    If Not ViewCurrent Is Nothing Goto SkipFormChange

    ' The viewCurrent object is not set.



    Set viewCurrent = dbCurrent.getView( "vlu-Names" )

    If viewCurrent Is Nothing Goto SkipFormChange



    Set docCurrent = viewCurrent.GetFirstDocument()

    If docCurrent Is Nothing Goto SkipFormChange



    ' Do something with the document.

    Call docCurrent.ReplaceItemValue( "Form", "f-Test" )



End If

SkipFormChange:

The counter argument to this is your exact same code with the addition of some code inside the nested ifs but after one of the inner end-ifs. Normally such a beast would be poor coding as-is but it also limits the number of nested ifs that can be stripped down to a SKIP-OVER block.


If ... Then

    If ... Then

        ' Guard statements may be put here

        If ... Then

            If ... Then



            End If

        End If

    End If

SkipTheAbove: ' This should have a descriptive label



    Call SomeFunction()



End If

I hope this sheds a little more light on what can sometimes be a complicated and confusing coding scenario.