Using colons to put two statements on the same line in Visual Basic

Question

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

Solution 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.

Solution 2

It's a good practice in moderation, because sometimes readability is enhanced by concatenating two lines:

• when the lines are short and intimately related

• when the lines are short and trivial

  Option Compare Database:  Option Explicit   ''My favorite!
  rsDataSet.Close:          Set rsDataSet= Nothing
  

Don't do it if:

• it hurts readability.
• it complicates debugging. Control structures such as If...Then need to stay clean. You'll be glad you kept it simple when it's time to set a break point.
• it compromises future editing. Often you want to keep sections portable. Moving or re-structuring a block of code is easily hindered by attempts to minimize your code.

Solution 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.

Solution 4

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.

Solution 5

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:)

View more solutions

Comments

[frankgut]

I used to do it in vb6 to place the declaration and initialization on the same line, but that problem was fixed in vbn.

[MusiGenesis]

+1 Agreed. I did VB for more than 10 years, and I didn't even know you could put statements on the same line separated by a semi-colon. I wouldn't do this unless the vertical scrollbars on my computer were broken.

[MarkJ]

that's vb.net of course. And I think it has C# envy, which is why Inherits is on the same line as the Class

[onedaywhen]

Do ever think of the person who will inherit your code? Have you considered that I cannot place a breakpoint in the VBE IDE on the line msg = "no association" without causing break mode in every case?

[Tony Toews]

Your comment is irrelevant in the only two cases I've ever place two staements on the same line.

[onedaywhen]

It's entirely relevant for the code you've posted here!

[Tony Toews]

<shrug> Then we agree to disagree.

[onedaywhen]

What have we disagreed about? You placing two statements on the same line would mean that I cannot put a breakpoint on the second statement. Isn't that unequivocal?

[Tony Toews]

So what. You'd never put a breakpoint on a simple Select Case like that.

[onedaywhen]

What if a defect had been reported that the message "no association" was showing unexpectedly. A search through the code reveals but one instance of that phrase. So I'd want to set a breakpoint on that line. See what I mean?

[onedaywhen]

BTW I have to do put break points on Case statements quite often when maintaining legacy VBA code, so this a practical point born out of experience of working with other developers, some of who like single line statements.

[Tony Toews]

Your objections are exceedingly strenuous for such a minor point. But do what you like.

[Coops]

I think you could go worse, at least that fits on the screen as one line

[Deanna]

+1 for the example :)

[вʀaᴎᴅᴏƞ вєнᴎєƞ]

Again old question, but since this is a new answer I'll post a new comment. I rarely use the : in code but I found that it was very useful in dealing with this bug: support.microsoft.com/kb/327244 I used the : in the following way: Me.ComboBox.SelectedItem = Nothing : Me.ComboBox.SelectedItem = Nothing I could have put that on two lines, but it made it simpler to read all on one line and it made sense since it was just a repeated statement.

[cxw]

dilbert.com/strip/1994-06-08 ;)

[clweeks]

I know this is old, but if I needed to debug that line as suggested, I'd just adjust the code with a couple of keystrokes so that the assignment was on another line and then place the breakpoint there. Or use a conditional breakpoint. This doesn't seem like a big deal and tightening those case statements up, particularly when there are a lot of them is pretty valuable to reader-flow.