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

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

The answer to the question is No. Anything beyond No is purely subjective and wasteful irrespective of the answer outside of a simple No. Below is my waste of typing.

Are you some sort of slave? Do as you wish. You are the center of your universe not some stranger from StackOverflow. If you work for a company the question is mute because coding style would already be defined and completely out of your control. As for one's self, who in this universe is going to ever in all eternity look at let along care about your code.

I would choose A over B. As evident this shows the purpose of a colon without the use of a colon. It's to save space. Below saves space and makes code far more readable. Keeps It Simple Stupid. Same for ternary ? : usage. When the code is inherently complex then a colon, single line if then else, or ternary no longer should be considered.

'================================================================
'A
If somevalue1 = 0 Then AddLogTry("True") Else AddLogFalse("False")
If somevalue2 = 0 Then AddLogTry("True") Else AddLogFalse("False")
If somevalue3 = 0 Then AddLogTry("True") Else AddLogFalse("False")
'================================================================

'================================================================
'B
If somevlaue1 = 0 Then
  AddLogTrue("True")
Else
  AddLogFalse("False")
EndIf

If somevlaue2 = 0 Then
  AddLogTrue("True")
Else
  AddLogFalse("False")
EndIf

If somevlaue3 = 0 Then
  AddLogTrue("True")
Else
  AddLogFalse("False")
EndIf
'================================================================

Answer 3

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

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

Answer 6

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.