The Right Way To Do Wordy Blocks

From ThingsWeHateAboutVbClassic:

Re: I like English-based over punctuation too. But I want consistent English-based syntax. I don't want to have to remember that

For goes with Next
While goes with Loop or Wend depending on dialect
If goes with End If

Some of us like the concept of word-based block markers. In C-style syntax I often put comment-based notes at the end of block to indicate what's ending and find that the practice helps me read code. However, some feel that VisualBasic has tainted the word-based approach's reputation by doing the "enders" wrong.

In my opinion, the right way is to end it the same way it started. If the block starts with "foo", you end it with "end foo" or "endfoo". So For loops should end with "end for" or "endfor" and not "next". (I think the spaces should be ignored in enders because people have different preferences.)

Also, we don't need "then" in IF statements. Perhaps make it optional for those used to it from other languages.

And no more "do".

no more "do" ? How else are you going to mark "do ... while()" loops ?

LoopConstructNeedDiscussion suggests they are not needed. Although, IF it's decided to include them in a language, what kind of syntax convention would be best for the "wordy block" world? [Somebody moved the reference to the bottom. That disconnects the reader from the response in my opinion.]

Suggestion:

WHILE:

  While <condition>
    ...
  End While

"Squished enders" (no space) should also be permitted due to popular expectations from other languages:

  While <condition>
    ...
  EndWhile

But the squished ender option will be considered a side or future topic, and the presence or lack of it from here on out will not be considered an endorsement unless stated otherwise.

UNTIL:

  Until <condition>
    ...
  End Until

IF:

If <condition> ... Else ... Else If // "elseif" also permitted, per rule above ... End If

FOR:

For X = 1 to 30 step 2 ... End For // perhaps also support "Next" for backward-familiarity

FUNCTION:

  Function Foo(...)
    ...
    Return <expression>    // optional
  End Function

And/Or:

  Func Foo(...)
    ...
    Return <expression>    // optional
  End Func

CASE:

  Switch <condition>
  Case <selections...>  // comma-delimited set is possible
    ...
  Case <selections...>
    ...
  Otherwise
    ...
  End Switch

  Case <condition>
  When <selections...>
    ...
  When <selections...>
    ...
  Otherwise
    ...
  End Case

(Other case ideas can be found at IsBreakStatementArchaic.)

As an aside, VisualFoxPro is close to what is suggested here, though still clearly not perfect:

DO WHILE <Condition> ... ENDDO
DO CASE ... ENDCASE
IF <Condition> (optional THEN) ... ENDIF
FOR <Variable> = <StartBoundry?> TO <EndBoundry?> ... ENDFOR
FUNCTION <FunctionName?>(<Arguments>) ... ENDFUNC

I agree that FoxPro is better worded than VB, however the "DO" is still awkward and could be done away with. "CASE" would have to be redone, perhaps something like CASE...WHEN...WHEN...OTHERWISE...ENDCASE.

Is this all because people are still uncomfortable with IndentationEqualsGrouping? If you make the indentation significant, the issue of what to terminate blocks with because moot. -- JonathanTang

(Oops -- SyntacticallySignificantWhitespaceConsideredHarmful.)

Most VB programmers are uncomfortable with just about any abstraction. {}, no way, they want big long words that are different for every control structure. int index = 0, heck no, Dim index as Integer = 0, they must love typing. Indention for scope.. ha, the only scope most know is method scope, which was the smallest scope VB had till .NET. Most VB'ers declare all their variables at the top of the method uninitialized, never mind where it's used, need to see the variables because you can't find them in the 200 line method they're used in. Objects... no no, they use classes as namespaces for groups of related functions, isn't that what they're for? Personally, I think VB is designed to cripple the mind, in order to maintain Microsoft's programmer base and tool market. Excuse the rant, I've just been forced to work on a VbDotNet project for the last two weeks, and I want to strangle someone.

This is an overgeneralization. These issues are or should be addressed in ThingsWeHateAboutVbClassic. No need to repeat them here. This topic is about the best way to achieve "wordy" blocks, not the merit itself of wordy blocks. But I am curious about why you consider such "less abstract". Regarding your "DIM" complaint, there is also a discussion topic somewhere [HuntFlag?] on whether the type declarations should come before or after the variable name.

Nobody seems to have mentioned the common idiom in some languages (BourneShell for one; though I suspect this didn't originate there) of spelling the opening tag backwards--IF matches with FI, DO with OD, CASE with ESAC. For short keywords like IF, this isn't too obnoxious; however if such a language were to introduce things like WORHT or ELIHW or HCAEROF, things might get UgLy

That defeats the very purpose of being "English like".

Perhaps borrow from XML:

WHILE x ... /WHILE

IF x ... /IF

Could add symbols and words to do away with the end controversies and still make blocks visually distinct and wordy:

 [IF
   ...
 |ELSE
   ...
 ]IF

or maybe the last should be

IF]

Angle brackets may give more the impression of 'entering scope' and 'leaving scope' >IF ... <IF

Interesting.

Note also that the function declaration prototype above may have room for a new paradigm:

  function Foo(...)
    ...
  endfunction Foo

This is so that you know exactly what function is being ended. However, I can see how this model doesn't fit in with the other devices, which don't differentiate what is being ended.

There's generally 3 levels/kinds of details that can be included for endings:

The fact that a block ended
The kind of construct that ended (conditional, loop, function, etc.)
The name or label of the construct that ended, if it has a name (Example: function name)

CategorySyntax CategoryLanguageDesign