Multiline IF-THEN line endings

Hear, hear – although the style of the indentation preferably ought to be configurable.

As with all source applicable items, ROOL should specify specific indents and those are the default – what other people prefer is up to them, but the default is the default.

but the default is the default

Cue war in 5…4…3…

Example:
In BASIC, indent is two spaces. Prefer multi-line IF to a chained set of commands in a single line.

In C, indent is three spaces. Long lines are broken to fit ‘nicely’. C++ style commenting used frequently. Opening and closing braces on their own lines, non-indented.

No Tabs, ever.
No opening brace at the end of the same line, ever.
If in doubt, add a line break and a comment or two. Some day you’ll be reading this code with no recollection of having written it. Help yourself now.

More or less. ;-)

Some day you’ll be reading this code with no recollection of having written it. Help yourself now.

There’s some vbscripts 15+ years old in use. I heard a conversation last week about “getting Mark to look at the alterations needed”

What you guys need to know is that the original was so heavily commented even an idiot could fathom out how to later it for a slightly different purpose, and possibly claim ownership.

That and the detail that the people talking know who wrote the original. :)

Cheers. Another year on life’s calendar. The amount of scotch this evening would probably have Rick in hospital. Me – time for bed.

In C, indent is three spaces. Long lines are broken to fit ‘nicely’. C++ style commenting used frequently. Opening and closing braces on their own lines, non-indented.

There are several C and C++ styles in common use. I prefer cuddling the braces to the control statement above: it fits more lines on the screen, and improves readability. This is essentially the Linux kernel style, except that it jarringly places the opening brace on the next line for funcdefs.

Three spaces for indents is really, really old. I’ve seen very little regularly maintained code using this style in the last decade or so. Most do two or four spaces. However, I have also seen an alarming increase in the use of tabs for indentation. This tends to bring me out in a rash, and I re-indent and commit a whitespace change to the repo because that is a less-serious wrong than the enormity which it correctsm and no jury would convict.

I haven’t seen a vim installation au naturel in the wild in some time (I have my own .vimrc, carefully curated over the years, which follows me everywhere like a tame badger), but iirc it defaults to four spaces for C and C++ code.

I prefer cuddling the braces to the control statement above: it fits more lines on the screen, and improves readability.

Very much this. I find “old style” C code (of the kind that many old RISC OS apps are written in) very hard to read, as the massive amount of white space and braces on their own lines just obfuscates what the code is actually doing.

This is essentially the Linux kernel style, except that it jarringly places the opening brace on the next line for funcdefs.

I’d not realised that I was in such august company… Function definitions are something of a special case, IMO, as they’re blocks in and of themselves: you’re not trying to scan across them.

However, I have also seen an alarming increase in the use of tabs for indentation.

Alarming, you say… ?

And would someone be a complete monster if they were to—ahem—tab-indent their (admittedly textual) BASIC code? :)

This tends to bring me out in a rash, and I re-indent and commit a whitespace change to the repo because that is a less-serious wrong than the enormity which it correctsm and no jury would convict.

I generally try to write code in the prevailing style of the project – my modifications to WinEd were done in “WinEd Style”, for example (although I did break the tradition of terse-to-non-existant comments). I will make exceptions for tabifying space-indented code, though…

just obfuscates what the code is actually doing.

I find the opposite to be true. A brace on its own is an obvious indication that the following code belongs to some form of control structure (if, while, etc). Sometimes when reading other-format source, I find myself backing up to work out what the structural flow actually is.

Code clarity isn’t how many lines you can fit on the screen, it’s what you do with those lines. Sometimes a bit of emptiness says more than a line crammed into the screen with. Don’t fear whitespace in C programs, the compiler doesn’t care.

tab-indent their

Must resist the tempestuous temptation…

Three spaces for indents is really, really old.

Give me time, I’m getting there. ;-)

(Responding to Steve Fryatt; I’m using the iPad and too lazy to quote)

Hmm. Do I hear banjos?

I am only commenting on C code. Haven’t written a line of BASIC in ~30 years, so I’m not qualified to comment.

It’s far too late on a school night to get.into a holy war. But in any case, Magenta has just released the dogs.

This is essentially the Linux kernel style, except that it jarringly places the opening brace on the next line for funcdefs.

It also uses an identation depth of 8…

It also uses an indentation depth of 8…

Ah, now that p***’s me, and all I’m doing is reading the stuff and trying to learn.
Speaking here as someone who alters the default putty window width to 132 to avoid wraps in switch console displays, width is important for clarity and wasting it is a crime.

When I said indentation should be configurable, I meant in the editor’s display – but with no indentation in the saved file. Then what I see is nobody else’s business, and the file is agnostic about it. Your editor can display it with whatever indentation you’ve configured.

I used to have a pale grey rectangle for character &20 in my Zap back in RiscPC days, but I’ve lost that now 8~( – so I never used to have any issues with invisible ones after THEN. I didn’t have any invisible characters in those days.

Speaking here as someone who alters the default putty window width to 132 to avoid wraps in switch console displays, width is important for clarity and wasting it is a crime.

Kernel style also entails 80 character lines. ;)

For the purpose of the kernel the “secular” ⁰ reasoning behind it is often said to be, that it encourages cleaner code by making too deep nesting impossible without breaking the style. There is something to be said for this, but personally I always use 4 spaces/80 characters, and like Richard I can’t quite bring myself to put the opening bracket of function definitions on a new line…

When I said indentation should be configurable, I meant in the editor’s display – but with no indentation in the saved file. Then what I see is nobody else’s business, and the file is agnostic about it. Your editor can display it with whatever indentation you’ve configured.

One can dream…

⁰ as with all these things, there is a semi-religious component to the adherence, see e.g. the Greg Kroah’s tongue-in-cheek definition of the kernel style https://www.kernel.org/doc/html/v4.10/process/coding-style.html (I note that is has a section on inline assembly as well)

One can dream…

Yup.

width is important for clarity and wasting it is a crime.

Indeed. I can accept arguments as to whether two or four is a good indent size (I felt two was too little and four too much, which is why my code uses three)… but eight?

The justification excuse is poor as well. If one is going to mandate splattering code across the screen in order to force things not to be nested too deeply, then one doesn’t need better rules, one needs better coders.

As for the brace placement, I note that the closing brace goes on a line by itself instead of tagged to the end of the line of code (as is done with the opening). Inconsistent and fugly.

Kernel style also entails 80 character lines. ;)

Because there are probably still people coding in vi. ;-)

For my own code, I “aim for about eighty” but the editor width is something like 112. It’s not just to fit in my 1280×1024 screen, the RiscPC could display something akin to that too. You know, for those of us who have moved beyond tty…

so I never used to have any issues with invisible ones after THEN.

Doesn’t Zap automatically strip stray spaces at the ends of lines?

Because there are probably still people coding in vi. ;-)

Me. The only benefit of a graphical windowing environment is that it allows one to open multiple console windows. And yes, there are kids on my lawn.

Doesn’t Zap automatically strip stray spaces at the ends of lines?

No idea. I don’t type stray spaces at the ends of lines anyway… 8~)

No idea. I don’t type stray spaces at the ends of lines anyway… 8~)

Looking at Wiki headline content our wiki may do that for you (add a trailing space)

I have no idea where that concept comes from, but I wish it would go back there and die.

Looking at Wiki headline content our wiki may do that for you (add a trailing space)

I don’t care much (or at all) about trailing spaces on the end of lines of text.

But anything I didn’t put there in code would annoy me no end.