VB Using colons to put two statements on same line

Question

Is it considered bad practice to use colons to put two statements on the same line?

Answer 1

There is nothing inherently wrong with using the colon to combine statements. It really depends on the context but as long as it doesn't reduce readability, there is nothing wrong with it.

As a general rule I avoid using the colon for this purpose. I find it's more readable to have one statement per line. However this is not a colon specific issue. I avoid doing the same with a semi-colon in C# or C++. It's just a personal preference.

Answer 2

I'll take the other side. I don't like dense lines of code. It is easier to skim code when lines are not combined.

Combining statements also makes it easier to create long functions that still fit on a single screen.

It isn't a major sin, I just don't like it.

I also don't like one line If statements.

Answer 3

In general, I'd advise against it, as it makes for busier code.

However, for simple tasks, there is nothing wrong with it. For instance:

for i = 1 to 10: ProcessFoo(i): next

I think a line like this is short enough not to cause confusion.

Answer 4

It is considered bad practice in most of the sites at which I have worked. And by most of the VB developers with whom I have worked. And in my head. If I see it, I will admit that I would almost certainly change it. I say "almost" because I admit there's a possibility that I could find a piece of code that looked better that way. I don't expect to see it in my lifetime, though.

I also really don't like one-line Ifs either.

Both are most likely hangovers from the days of VGA (640x480) monitors; that's no excuse these days.

Answer 5

I've never seen this mentioned in an official capacity at any of the companies which I've worked. But I do think that using colons excessively can start to make your code less readable and more of a pain to maintain.

I do tend to use these myself at times, for example when checking for cancel in one of my recent projects:

If _bCancel Then Status = CancelProcess() : Return Status

Putting this in kept my code readable than the alternative IF block.

But it can be taken too far, I've recently inherited a project which is replete with examples of taking colon usage too far :

    Select Case GetStringValue(Index).Trim.ToLower
        Case "yes", "y" : GetBooleanValue = True
        Case "no", "n" : GetBooleanValue = False
        Case Else : GetBooleanValue = Nothing
    End Select

Personally I find the above to be a bit much.

Answer 6

I've seen it used in class declarations when using inheritance or implementing an interface:

Public Class DerivedClass : Inherits BaseClass
   ...
End Class

But like the others, I also discourage its use.

Chris

Answer 7

It's a good practice, in moderation (readibility!), with two considerations. Sometimes readability is enhanced by concatenating two lines:

• if the lines are short and intimately related (close recordset, set recordset to Nothing).
• if the lines are short and trivial (such as turn hourglass off, turn screen echo on).

The second consideration is debugging. Step-by-step review is not helped by this concatenation (for examples, setting a breakpoint or determining precise point of error). So any code that has substance should never be concatenated.

Answer 8

I've only ever used it when I'm clsoing a recordset and setting the variable to nothing. I figure one line instead of two gives me more lines of code on the screen and doesn't detract from readability.

I've seen it used in simple select cases such as the following but that would be as far as I would go.

 Select Case success
      Case ERROR_FILE_NO_ASSOCIATION: msg = "no association"
      Case ERROR_FILE_NOT_FOUND: msg = "file not found"
      Case ERROR_PATH_NOT_FOUND: msg = "path not found"
      Case ERROR_BAD_FORMAT:     msg = "bad format"

from http://vbnet.mvps.org/index.html?code/system/findexecutable.htm

And even then I would've lined up the "msg =" portion.

Answer 9

To me you shouldn't say "never do thus", you should just say "If you do this, a possible problem is such and such." Then just weigh the pros and cons for yourself. The pro is brevity/few lines of code. Sometimes this can aid readability. For instance some people use it to do vb.Net declarations:

Dim x As Long: x = 1

Or wait loops:

Do Until IE.ReadyState = READYSTATE_COMPLETE: DoEvents: Loop

But obviously you can really make it rough on someone too:

Public Sub DoYouKnowWhatThisDoes()
    MsgBox Example
End Sub

Private Function Example()
    Const s$ = "078243185105164060193114247147243200250160004134202029132090174000215255134164128142"
    Const w% = 3: Const l% = 42: Dim i%, r$: For i = 1 To l Step w: r = r & ChrW$(Mid$(s, i, w) Xor Mid$(s, i + l, w)): Next: Example = r
End Function

Another practical reason that you might not want to use this approach is breakpoints. Breakpoints can only be set by the line. So if you have several things executing on the same line you can't isolate the second thing. It will stop on the first statement. (This is also one of the reasons some people don't like single line ifs.) It just complicates debugging a little.

I usually don't use colons in production code for this reason. However I do use them to improve the brevity of "copy/paste" code that I post in forums and elsewhere. YMMV:)