How do you like to indent the CASE statement?

Hello,

I’ve recently been thinking about how the CASE statement should be indented. This is how I personally do it:

CASE GET$ OF
WHEN "z"
 PROCstatement_one
 PROCstatement_two
WHEN "x"
 PROCstatement_three
OTHERWISE
 PROCstatement_four
ENDCASE

I keep the ‘CASE x OF’, ‘WHEN’, and ‘ENDCASE’ on the same level, and the statements one level up. I find this looks good and works well for me. How do you do it?

I indent WHEN and OTHERWISE one step, and anything between them another step. But in your example I’d put all those PROCs on the same line as the WHEN or OTHERWISE, thus:

CASE GET$ OF
 WHEN "z" : PROCstatement_one : PROCstatement_two
 WHEN "x" : PROCstatement_three
 OTHERWISE : PROCstatement_four
ENDCASE

Usually – but I’m not terribly consistent with my indenting. I often don’t indent things at all within simple functions and procedures – but I always leave a complete blank line between functions and procedures.

StrongED does it for me.

I indent so that IF/ELSE/ENDIF are all at same level with bits between 2 spaces indented so I indent CASE/WHEN/OTHERWISE/ENDCASE so that all are at same level with bits between 2 spaces indented. BB4W indents WHEN/WHEN/OTHERWISE a further 2 spaces but I don’t like that approach because the final ENDCASE then undents 4 spaces.

Something like this:

DEFPROCmeh
  REM What the function does.
  
  CASE something% OF

    WHEN    1 : REM What this is
                PROCdosomething
                PROCandsomethingelse

    WHEN    2 : REM What this one is
                PROCdosomethingelse

    OTHERWISE : PROCsulk
  ENDCASE
ENDPROC

What’s important:

1. Comments to explain what’s what (if it isn’t obvious – I would not comment a GET$ matching to “x”, but I would comment a numerical Wimp_Message).
2. Whitespace to break each bit of code into it’s own section. This isn’t the ’80s, whitespace is okay now. ;-)
3. That the ‘:’s line up (I think it is clearer). Consequently everything is nicely indented to the same level (and no, there’s no requirement to align it all to any specific column, as if that was in an IF conditional, it’d be indented further.

Whitespace is okay – but too many blank lines means you don’t get as much of your program on screen simultaneously.

I like the lining up of the colons, but it’s not something I’ve often bothered to do.

But then I’m a lousy guru for anyone to follow. My code is grossly undercommented – but at least I mostly use fairly meaningful variable, function & procedure names.

Too few white lines is like trying to pull shiitake mushroom pieces out of a pre-prepared meal¹. I find the screen issue less pressing now than way back when given that not only are editors quick at scrolling (and can do useful stuff like listing functions), they can also open multiple files simultaneously and multiple views of the same file.

I won’t comment on the commenting. ;-)

My maxim is “you’re working on this right now? you have the entire flow of it in your head? well, whatcha gonna do in a decade when you come across this code again and don’t remember writing it, never mind what it does?”. I comment with that in mind, and err on the side of too much rather than too little. Ignoring superfluous comments is always less mentally taxing than trying to work out what a “clever” bit of code is trying to do².

¹ Chopsticks FTW!

² I think my brain likes pain. Some of my best code has been written when I’ve been really ill. How and why it works… that’s a different question entirely. I once stumbled across a big function that could easily have been written in C, as a mass of assembler that did freaky things with the stack in lieu of having addressed memory locations for variables, and not a comment in sight. Accordingly, I rewrote it. In C.

but at least I mostly use fairly meaningful variable, function & procedure names

That helps. Compare with this verbatim example from our production codebase at work:

/// <summary>
/// Validates the priority.
/// </summary>
/// <param name="s">The s.</param>
/// <param name="e">The ServerValidateEventArgs instance containing the event data.</param>
protected void ValidatePriority(Object s, ServerValidateEventArgs e)
{
    e.IsValid = grdPriorities.Items.Count > 0;
}

Fortunately there are helpful comments in there too!

// This magic incantation makes the label wide enough to fit its contents without using AutoSize, which breaks TextAlign.
lbl.Width = (int)lbl.CreateGraphics().MeasureString(lbl.Text, new Font("Segoe UI", 9f)).Width + 8;

This is very much a matter of personal taste, so there is no “correct way to do it”.

I like compact structures that I can scan easily on one screen, so a combination of Patrick and Clive:

CASE GET$ OF
WHEN "z": PROCstatement_one:PROCstatement_two
WHEN "x": PROCstatement_three
OTHERWISE PROCstatement_four
ENDCASE

I do tend to line up statements, and REMs, if I think it will clarify the structure, but I do not put spaces around colons, nor blank lines between definitions. StrongED folding means that I can see large chunks of a program at one time while editing just one routine.

I am liberal with comments and long names if I think that I will return to the code or anyone else will need to read it. On the other hand, if I am playing around with a fragment I will write pre-crunched code ¹ that would be almost impossible to work out later.

The matter of white-space is interesting. I appreciate the clarity that programmers say it brings to source code, but I find that if there is too much I cannot see the wood for the trees. For instance, I find much code in the RISC OS source difficult to follow. ;-(

However, BASIC is not source code and white space has implications. Most white space, and comments, are removed if BASIC$Crunch is set, but that is a user option. Blank lines are not removed and I would suggest they should be avoided. Long names also have implications. I think that it is worth a bit of effort to consider speed and memory, but on our current machines that might be classed as a foible. ;-)

Anyway, I can now crunch programs ² to allow both without penalty, so I am trying to retrain myself to be more liberal.

¹ Not a cryptic as Sophie Wilson or nemo, though. ;-)

² I have had no takers to test Crunchie

For instance, I find much code in the RISC OS source difficult to follow. ;-(

Ah, but it’s worth noting that something that could be expressed as a single line of BASIC could equate to a couple of screenfuls of assembler. ;-)

I think that it is worth a bit of effort to consider speed and memory, but on our current machines that might be classed as a foible. ;-)

For speed (and maybe memory), you wouldn’t be using BASIC! These days, I’d choose clarity over compactness.

I have had no takers to test Crunchie

Sorry, I missed the offer. I’ll bite – I have some old code in BASIC I can try it with…?

Ah, but it’s worth noting that something that could be expressed as a single line of BASIC could equate to a couple of screenfuls of assembler. ;-)

Something I have been promoting for decades – hence Basalt. ;-)

For speed (and maybe memory), you wouldn’t be using BASIC!

Speed, yes, but the BASIC machine code is shared, so memory can be less. Especially if you have a large chunk of shared machine code in addition in Basalt, desktop programs can be pretty small.

I have some old code in BASIC I can try [Crunchie] with…?

I think I had better upload it, but I still consider it to be alpha until some others have put it through the mangle. Watch this space.

StrongED does it for me.

I find that in recent versions StrongED makes a bit of a mess of indentation in BASIC – especially when editing old/existing code.

I haven’t pointed it out to Fred either directly or on the mailing list yet simply because I haven’t done a huge amount since whatever change caused this, and I’m usually doing things at the last minute, so I put off reporting the problem until I’m less rushed, and promptly forget¹.

What StrongED used to do was simply indent each line based on the indentation of the line above, which put it fully in my control. Now it seems to be trying to decide for me what indentation I should have, and gets it wrong. (Which is another reason for not reporting it yet – I should investigate the options in case it can be switched back to the old behaviour.)

¹ Even now: I’m on my Windows laptop during my lunch break at a clients, so I thought I’d check the forum; saw this thread, and it reminded me of the problem – but being where I am I’m not at a RISC OS box. By the time I am, I will have forgotten. (I may not [remember to] check this forum later – so I may not see this post again as a reminder until I finally get around to catching up on my RSS feeds.)

Also: My preference = as per Rick’s example.

I haven’t pointed it out to Fred

Well, you have now. ;-)

The Return key in StrongED’s BASIC mode is set to do 2 additional things:

• Ensure that BASIC keywords are in uppercase (via an add-on).

• Indent the line based on the rules defined in the ModeFile.

This can be changed back to the old behaviour simply by commenting out the keybinding for the Return key in ModeFile for BASIC mode.

You can still re-indent (a selection of) the BASIC file by using cs-R which will use StrongED’s internal indenter. The file can also be indented by the BASIC interpreter via c-E,c-I.

Duh! It should have occurred to me that you’d probably spot the comment here!

This can be changed back to the old behaviour simply by commenting out the keybinding for the Return key in ModeFile for BASIC mode.

I’ll do that – if/when I remember! This is actually more likely than me remembering to report the problem in the first place: Next time I use it, get some odd indenting, and swear, I’ll probably remember this thread and to make the change! :)

You can still re-indent (a selection of) the BASIC file by using cs-R which will use StrongED’s internal indenter. The file can also be indented by the BASIC interpreter via c-E,c-I.

Which means where it has gone awry, I can highlight the whole function and get it to sort itself out. Useful to know. Ta.

This can be changed back to the old behaviour simply by commenting out the keybinding for the Return key in ModeFile for BASIC mode.

Amending the defaults on any new installs I do is a given.
Any particular reason why “End” takes you right to the end of the document like you’d expect Ctrl-End to do.
It’s a pet hate. Massively irritating to anyone that uses any other platform.

Any particular reason why “End” takes you right to the end of the document like you’d expect Ctrl-End to do.

Clue in the name? ;-)

Seriously… I just tried it on Zap and it looks like End deletes backwards, and Ctrl-End toggles a mouse-less selection mode.
I can’t tell you what Notepad++ does on XP, as my “Microsoft Natural”¹ keyboard with built-in touchpad² has done away with all of those keys. Insert? Home? End? Menu? Win/Ctrl on the right? All gone. I do however have a bunch of media buttons (doubling up as Fkeys with an FN button) which may or may not work as I’m using XP; plus every so often Windows makes the “WTF?” bong. I think I can draw gestures on the touchpad, which…aren’t recognised.

My pet hate – compact keyboard layouts with an FN button where they cheaped out on supporting all of the keys on a normal keyboard. It would not have killed them to do something like FN+Up as Home and FN+Down as End, for instance.

¹ Which is, I believe, what Microsoft call most of their keyboards…

² The keyboard works under RISC OS. Dare to touch the touchpad, however, and it’s an instant system freeze. That’s why I use it on the PC…

Clue in the name? ;-)

Indeed, but you see I rather expect it to take me to the “end of the line” and Ctrl-End to do somewhat more, like end of the document.

Seriously… I just tried it on Zap and it looks like End deletes backwards, and Ctrl-End toggles a mouse-less selection mode.

Clear signs Zap has been hidden in a dark cave for several decades. Obviously someone, somewhere, thinks the key in that position is still the one on a BBC micro.

I can’t tell you what Notepad++ does on XP,

Same as it does on Win7 – takes you to the end of the line, just like Notepad, and Word and Wordpad and…

Dare to touch the touchpad, however, and it’s an instant system freeze. That’s why I use it on the PC…

This beast I’m one now, being a laptop, has one of those. It gives me no problems whatsoever, however that could be down to the fact that I disabled it¹ as that’s where I tend to rest my hands when using the keys.
Removing the USB wireless mouse would re-enable it so I always leave the USB dongle inserted :)

¹ I did wonder whether gluing a layer of clear film over it would be useful, but the USB mouse disable route seems easier.

just tried it on Zap and it looks like End deletes backwards

Not here it doesn’t – The End key takes the cursor to the end of the current line

Any particular reason why “End” takes you right to the end of the document like you’d expect Ctrl-End to do.

It’s per the Style guide.

It’s a pet hate. Massively irritating to anyone that uses any other platform.

That’s understandable. Fortunately it’s a simple edit to change it.

That’s understandable. Fortunately it’s a simple edit to change it.

above: “Amending the defaults on any new installs I do is a given.” – I was just hoping for a bit of cross platorm uniformity.

Well that depends on which platform you’re “crossing” with, eg. End goes to the end of the document on a Mac.

I’d have to look back over all the BASIC code I wrote regularly years ago to see how I used to format CASE statements as since then it’s almost exclusively been C and C++ for me. My only preference now really would be to have at least some kind of indentation and I tend to leave a blank line above and below a clearly defined block of code like that.

One thing this discussion has brought to my mind is the question of line lengths and word wrapping in code. This question applies more to C and C++ than BASIC given that newlines in BASIC terminate a statement. I tend to run very high resolutions when I work which means that very long lines of text can fit on my screen and typically the code I’ve been exposed to in my career didn’t have a single standard for line length and usually word wrap was disabled by default. At worst this meant some statements and comments stretching off the screen needing much horizontal scrolling to read and at best it was often a case of taking a best guess at which point the line should be broken up – sometimes at the end of a comment sentence or other times halfway between two subconditions on a long “if” statement.

The trouble is, when you really think about it, a best guess like that isn’t necessarily very good when other people will be reading the code. I mentioned my large screen resolutions. If someone views the code on a small laptop screen, all my code lines will probably look far too long, and they may even turn on their own word wrap settings which will doubtless conflict with the newlines I put myself into the code, making it a bit messy. What do other people do about this? I’m fully prepared to be told I’ve been doing it wrong all these years; if there is such an absolute notion of right and wrong when it comes to style issues such as this.

Well that depends on which platform you’re “crossing” with, eg. End goes to the end of the document on a Mac.

Useful info, I’ll add it to the list of reasons not to buy a Mac. :)

For C code, I’ve set Zap to 156 columns (how much fits 1280×1024). When writing, I go “about” three quarters of the way across (maybe ~120 columns) unless the extra space is required (sometimes for comments); and tend to break things with parameters to line up, like this:

   printf("Some %d message %d here %d\n",
          var_one, var_two, var_three);

Since it’s no longer the ‘80s and we’re no longer editing in MODE 12 and printing to an fx80, the 76-columns rule has been thrown away. All I can say to that is thank <deity$name>!

Also: each block in C is indented three spaces. No tabs are used (at all). Opening and closing braces go on a line on their own.

Stylistically, there is a module (module as in a chunk of code, not a RISC OS module!) called “wrapper” that deals with startup and shutdown, holds globals, and some generic functions (like debug() etc). There are other modules that do specific tasks. For example in !Manga there is “fetcher” and “jpeg” and “wimp” (etc) – all of which are kind of self explanatory. Within these modules are functions. The general rule here is lower case, prefixed by the module name. So “fetcher_dosomething” and “jpeg_draw” and “wimp_somethingelse”. This rule can be broken for static functions that aren’t visible to other modules. Variables are either lower case or CamelCase and may or may not have underscores. It depends upon how I feel at the time, though generally lowercase. The only fixed rule is they cannot be UPPERCASE because that’s reserved for #define stuff. I don’t use RP or variable type encoding in the names. The names instead reflect what they are for. I once wrote a program where the variables were all character names from My So-Called Life. That was a lesson I didn’t learn since the program wasn’t terribly useful, thus I wrote another program where the variables were characters from Buffy. This program was more useful. Maintenance was a nightmare (remind me, what’s “_giles_tmp = anya→xander[willow];” assigning?!?). That lesson was finally learned. Hard. :-)

Also: each block in C is indented three spaces. No tabs are used (at all).

Oh no, don’t spark off the H0ly w*r of tabs versus spaces, Rick!

That was a lesson I didn’t learn since the program wasn’t terribly useful, thus I wrote another program where the variables were characters from Buffy. This program was more useful. Maintenance was a nightmare (remind me, what’s “_giles_tmp = anya→xander[willow];” assigning?!?). That lesson was finally learned. Hard. :-)

Sounds like following that code would be a fun challenge in its own right! Maybe you could write an obfuscation tool that renames all the variables automatically to characters from the show of the user’s choice?