Torvalds intentionally complicates his use of indentation in Linux Kconfig

Linux kernel supremo Linus Torvalds has made the use of indentation in kernel config files more ambiguous – intentionally to weed out inferior parsers. Kernel 6.9-rc4, the latest release candidate for the next version of the Linux kernel, came out yesterday. Among the usual drivers and bug fixes, it contains some more tweaks …

[Paul Crawford]

I always thought this sort of approach would deal with leap-seconds, make every month a jump forward or back, and when you need to move for good simply exclude one of those steps. That way software teams would get borked every month until they fixed their code to work properly. Rather then moan and hiss and throw up their hands in horror every couple of years when the well-documented event was applied as needed for Earth rotation versus UTC alignment.

[Anonymous Coward]

You're evil and I love you

[Jou (Mxyzptlk)]

Tab = four  

That is indeed the right choice. I agree here. Even Powershell ISE does it :D .

[Someone Else]

Re: Tab = four  

But...but...but...not even Linus can countenance that. He demands using the OTBS, which requires tabs, not spaces, each of which must represent 8 columns of whitespace.

[MacroRodent]

Re: Tab = four  

> each of which must represent 8 columns of whitespace.

Actually it varies: In terminals and printers, a TAB character classically moves to the next divisible-by-8 position. So if the current cursor or print head position is column 15, it moves to column 16, not 23.

Unfortunately various IDE:s practice the Abominable Heresy of by default setting TAB to advance to the next divisible-by-4 position instead. When a file written by such is viewed on a terminal or an editor Configured Correctly, it looks horrid. This wileness has forced the coding standards in my workplace to degree that only spaces shall be used for indentation...

[Michael Wojcik]

Re: Tab = four  

In terminals and printers, a TAB character classically moves to the next divisible-by-8 position.

Traditionally, tabs were settable, on mechanical typewriters. That mechanism dates back at least as far as 1900 (Hillard patent). In the era dominated by mechanical typewriters, the first tab position was often set to 5 or 6 spaces for start-of-paragraph indentation.

ISO 6429 includes control codes for setting tab stops. I don't know offhand of any terminal that implemented them.

Every-8th-position is a convention that came later, perhaps because it's a good divisor for the 80 columns of the common 80-column punch card, though the author of the page linked above suggests it's because calculating the next fixed tab stop is simpler in binary if it's congruent to 0 modulo 8 (add 8 and mask the three low bits). Both justifications could apply, of course.

It's also perhaps worth noting that ASCII codepoint 9 was originally defined as "HT/SK", the "SK" meaning "skip", a control function for card readers. See e.g. the third page of Smith, "New American Standard Code for Information Interchange".

This wileness has forced the coding standards in my workplace to degree that only spaces shall be used for indentation...

The different-settings-for-horizontal-tab problem existed long before IDEs were available on most systems. I well recall problems reading code formatted with tabs, and particularly with tab-and-space combinations, in the 1980s on UNIX systems where most developers used vi or emacs¹. vi, of course, was infamous for aggravating the problem when autoindent was set.

Since it's impossible to know what anyone else's editor will do when displaying tabs, I've always adhered to the spaces-only school. Yes, for much indentation you can get away with tabs-only; but that falls down if you want to align text on anything other than a tab boundary, as some people like to do when splitting long statements, for example.

¹emacs is not so much an IDE as a shell with a really ambitious command-line editor.

[Vometia has insomnia. Again.]

Re: Tab = four  

I remember my grandfather's mechanical typewriter had settable tabs; it wasn't only older than me, it was possibly older than him too (born around 1920, RAF comms guy then BBC luvvie, hence typewriter for script-writing) but disorganised teenage me had no idea what they were for. I probably caused irritation when I moved them about!

10 years later I found the VT220 (or at least clones: this was actually a Motorola/Philips TM220 but was a rebadge that I saw with various different brand names and I'm not sure who actually made them; Ampex, maybe?) also had settable tabs which were used by e.g. the curses library to hasten output when drawing full-screen menus and similar, which was thoughtful at a time when 9600bps was still considered pretty quick for a terminal. It's something I only discovered when using software like Uniplex which went through a phase of crashing randomly, and consequently it left the tab stops in very non-standard places. I dunno what it normally did on a non-crashy exit, whether there was an option to restore the previous tab settings or if it just set them to the default of every 8 characters.

[Roland6]

Re: Tab = four  

Given the equivalence has existed since the first typewriter, it makes you wonder as to the skill level of the people involved in modern parser design and development.

I wonder if Rust suffers from the same problem…

[ModicumSuch]

Re: Tab = four  

> Given the equivalence has existed since the first typewriter

Not at all. Mechanical typewriter tabs were always arbitrary (but usually divisible by 5). On the earliest ones, these were physical tab stops you inserted. Later manuals let you set and clear tabs with dedicated keys. Tab, after all, is short for tabulator, and tabs were first and foremost intended to produce consistent columns for tables. It just happens that tabs are convenient for setting indentation.

In fact, classic typewriting manuals advised beginning lines with 5 spaces, not 4.

[that one in the corner]

Re: Tab = four  

> Mechanical typewriter tabs were always arbitrary

Indeed. The machines I learnt to type on, from the 1960s onwards, all had tabstops that you could place anywhere along the line. So you would count out how many characters the longest line in your own address required and then set up a right-most tabstop to leave just that much on the paper, so you could type up letters properly (when you weren't using the pre-printed Nice Paper, that is).

It was only after years of typing on computers that I ever came across any weird claims like "one TAB always equals 4 SPACEs" - or 2 or 6 or 8. Nope; if you used TABs then you jolly well set a line that defines where the TAB stops sit[1], just like on your typewriter.

It has been a while since I used it, but doesn't even MS Word have proper tabstops you can set anywhere? So nobody who uses a wordprocessor can claim they don't knows tabstops can be set anywhere, in whatever irregular spacing fits your tabulated data best.

Oh, and how I wish I could forget all the stupid arguments from people who do not know what tabstops are in the first place, so claim that, say, TAB equals 8 SPACEs and *then* that a line starting with SPACE SPACE TAB meant the next character would appear in column 11 and not column 9! Or did they mean that they wanted TAB to go to column 8 then 16 then 24 (so just like typing 7 spaces to get to the first of those, then 8 to get to the next...)

Rip the TAB key off any programmer's keyboard and replace it with a drawing pin, pointy bit upwards[2]

[1] there was also a convention that a number of programmer's editors used to follow, where you put a specially marked-up comment into your source code (whatever delimiters your chosen programming language used) and the editor applied those tabstops in that source file until told otherwise - no ambiguity at all, so obviously this idea had to go.

[2] unless they can *prove* that they have set their editor to use "insert SPACEs to reach next tabstop" - you can *type* however you please, just don't leave the bleeping TAB characters in the source code[3]

[3] okay, Makefiles are an unfortunate exception - but then J. Random Coder should not be writing the rules part of Makefiles anyway, but just listing modules in a variable and including the file with the rules for your build setup.

[ModicumSuch]

Re: Tab = four  

> It has been a while since I used it, but doesn't even MS Word have proper tabstops you can set anywhere?

As I recall, you can click and drag anywhere on the ruler to set stops. It’s a charming holdover from typewriters, until you start getting complaints from users who don’t know why their indents aren’t uniform across paragraphs.

[david 12]

Re: Tab = four  

- you can *type* however you please, just don't leave the bleeping TAB characters in the source code

Oh sure, you can say that now, but when I started, a source document containing tabs was smaller and faster than one containing spaces. Faster to load, faster to page, faster to cursor through. And when your character count got to 65536, the larger document containing spaces wouldn't load at all.

Anyway, separate comment: I'd still like having tab characters in my source code. Even when all my indentation is spaced I like having tabbed comments and tabbed assembly language. But, since I started with card punches, the data-entry should "eat" tabs as you go past them, like a typewriter does, rather than pushing them out (overwrite rather than insert)

[An_Old_Dog]

Eight-Space Tabs

1. I believe the tabs-every-eight-spaces thing came about because DEC VT 100/101/102 terminals defaulted to that. People could go into the terminal's SETUP program and change those tab settings, just as on a "real" typewriter, but few people ever did.

2. I hate not clearly-and-easily seeing the indentation level of a piece of code, and therefore I am an eight-columns-indentation advocate. Obviously, (sarcasm on) four- and two-column-indentation advocates are anally-retentive, conserving columns as they would paperclips, and are fearful of continuation lines (sarcasm off).

3. I have suffered through reading a thick paper listing of a Pascal compiler which used two-column indentation. All four- and two-column-indentation advocates ought be required to undergo the same experience.

4. I have no objections to using spaces instead of tabs, as my editors can be configured so my tab key does what I want it to do, replacing tab key strikes with the appropriate number of spaces.

5. So-called "smart" indentation features in editors invariably do what I do not want them to do, which is why I despise them.

6. YMMV.

[TheMeerkat]

Re: Eight-Space Tabs

As someone who used to program Pascal when screens were 80 characters wide, I understand why one would rather have 2 space indentation instead of wasting screen width.

[yetanotheraoc]

Re: Eight-Space Tabs

Yes, this is why choice is good. I used to like 4 spaces. I switched to 2 spaces after I started looking at(*) a significant bunch of code on a tiny iPhone SE screen. The current phone in landscape wraps at column 66 or so. I started using shorter variable names as well.

(*) Mostly read-only mode, although there was that one time while on vacation....

[MichaelGordon]

Re: Tab = four  

Given that "make" was created in 1976 and had to run on the machines of the day, I'll forgive it for not having a particularly flexible parser. There's an argument that modern versions shouldn't care what white space is used to indent recipes as long as something is, but that might break existing input; I haven't thought about this enough to be sure.

[Michael Wojcik]

Re: Tab = four  

Microsoft's nmake uses mostly make-like syntax, but doesn't distinguish between space and tab characters. It figures out whether something is a command line from context.

Apparently in sufficiently recent versions of GNU make you can use either spaces or tabs as prefixes for command lines (aka "recipe" lines) by adding space to the list of recipe-prefix characters, which you can do in the makefile by assigning to a special variable. There are various suggestions for ways to do this, such as:

.RECIPEPREFIX := $(.RECIPEPREFIX) $(.RECIPEPREFIX)

[david 12]

Re: Tab = four  

Correct about the meaning and function of tabs, but that '5' space convention was not generic across different hardware, and the 5-space business rule wasn't in my typing books.

A contributing factor might be that some typing books were actually tied to specific typewriter manufacturers. If the typing book or style guide was intended for use with a typewriter that had only 5-space tabs, it was going to teach 5-space indentation.

[An_Old_Dog]

Re: Tab = four  

I've seen and used many manual and electric typewriters*. All of them let you set tab stops anywhere you wanted. to the limit of the number columns the typewriter's platen supported.

*Some, but not all, printing terminals supported locally-defined tab stops.

[Roland6]

Re: Tab = four  

I was being too concise

Tab = white space consisting of one or more space characters.

Obviously on the typewriter you could set the tab spacing (as you can with MS Word et al).

I suspect the norm for typewriters would have been 0.5 inches, circa 5 space characters.

For IT restricted to 80 columns (displays, punch cards etc.) and basic fixed width font, spacing of 4 spaces was deemed sufficient.

[Philo T Farnsworth]

Semicolons and curly braces, forever.

I can't count the number of wasted hours I've spent trying to find bugs in python or jade code caused by an accidental stray indent or outdent.

But maybe that's just me.

[Ken Hagan]

Re: Semicolons and curly braces, forever.

Zero, surely? Either the text lines up with the logic or it doesn't.

[bazza]

Re: Semicolons and curly braces, forever.

Problem is you then have to write down in comments exactly what the logic should be. Lose an indent accidentally off a line that’s supposed to be inside an if statement and you’ve no way of knowing unless there’s some other record of what the logic should actually be.

Self documenting code is impossible when something that you can’t see can be syntactically significant.

[doublelayer]

Re: Semicolons and curly braces, forever.

Indentation is many things, but invisible is not one of them. If you can't recognize whether a line belongs in the statement, then it won't help if the statement has a curly bracket at the end or not. The problem isn't knowing where the statement ends, but knowing whether an expression should be inside it. There are lots of reasons why syntactic whitespace is annoying, and I would not include that feature in a language I designed*, but you cannot file it under "something that you can’t see can be syntactically significant".

* I might warn about it in my compiler because I've seen some truly horribly indented code in languages where it is unnecessary, but I wouldn't make indentation control flow. Brackets help prevent people from making mistakes that they have to catch later because a compiler cannot know what structure is appropriate. I'm confident that programmers can do that without brackets, but having them makes it less likely that they'll get into that situation in the first place.

[Doctor Syntax]

Re: Semicolons and curly braces, forever.

What isn't visible, at least in any programming editor I've used, is whether the indents are spaces, tabs or any mixture of the two.

[John Miles]

Re: Semicolons and curly braces, forever.

Most Editors and IDEs I've used have a view "White Space Option" or similar, in Notepad++ go to "View -> Show Symbol -> Show Space and Tab", normally they'll be shown as a dot for space and arrow for a tab

[Roland6]

Re: Semicolons and curly braces, forever.

Indentation helps but remember C will flag a missing semicolon sometime after the place one should of been placed…

[Joe W]

Re: Semicolons and curly braces, forever.

The problem is (or was) that the python interpreter was convinced that a tab is a different interpretation than four or eight or however many spaces you used. You had no way to pick that up visually.

The article sounds as if this has been corrected though.

[david 12]

Re: Semicolons and curly braces, forever.

The article sounds as if this has been corrected though.

No, PEP 8 is a very old PEP (the giveaway is the single-digit number), and it's a readability guideline -- people who came from backgrounds where tabs were not used because they were conventionally 8 spaces were convinced that tabs should be 8 spaces, and wanted to inflict that on people who insisted on using tabs -- both because 8 character tabs were righteous, and to stop people using tabs.

The insistence that the python interpreter does not match tabs to spaces just fell out of the parser, and seemed right to people who took their entrenched views of programming from what they were familiar with (something the Python mailing list really suffered from in the early years).

[ldo]

Re: the python interpreter was convinced that a tab is a different interpretation

Newer versions of Python (from 3.0 if I recall rightly) are stricter: successive lines which are supposed to have the same indentation now have to begin with exactly the same sequence of whitespace. You can’t put a tab on one line and a space in its place on another. This avoids a lot of common mistakes.

[david 12]

Re: the python interpreter was convinced that a tab is a different interpretation

That's always been the case.

[ldo]

Re: That's always been the case.

Actually, no. Notice in the description of the indentation rule, in Python 3.1 you have the statement “Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.” This rule is not present in Python 3.0.

So it was introduced in Python 3.1.

[Liam Proven]

Re: the python interpreter was convinced that a tab is a different interpretation

[Author here]

> You can’t put a tab on one line and a space in its place on another.

That is exactly what I wrote: _you have to be consistent_.

[Philo T Farnsworth]

Re: Semicolons and curly braces, forever.

In a perfect world, perhaps.

In a world where you need to debug someone else's code, you need to debug your own code six months later (effectively the same thing), or the cat decided to curl up on top of the keyboard while you weren't looking, the flow of logic may not always be apparent.

I wish to Torvalds and van Russum that life were so simple and the fates were so benign.

[John Riddoch]

Re: Semicolons and curly braces, forever.

I'm sure it was /etc/syslog.conf on Solaris that really didn't like spaces instead of tabs. Of course, everything looked ok to a human, but it just failed spectacularly. It usually happened when copying & pasting from another system, because it would copy the tab as spaces into the new file.

[ldo]

Re: that really didn't like spaces instead of tabs

The classic example where tabs are needed in certain places but not others is Makefiles.

[MrXonTR]

Re: Semicolons and curly braces, forever.

If your chosen editor cannot convert tabs to spaces automatically then please learn the expand command.

"man expand". Ever notice how every manual page sounds like a double entendre?

[ldo]

Re: If your chosen editor cannot convert tabs to spaces automatically

I used to use tabs, back in the day, but with the meaning that tab stops were positioned every four columns, not eight. Eight never made any sense to me (some old typewriter convention or something), and still doesn’t.

But I gave up and switched to spaces maybe a couple decades ago. But for compatibility, I still have my editor configured to take a quick sniff of every file I open: if it spots a tab, then it configures the tab key to emit literal tabs. Otherwise, pressing tab inserts some suitable number of spaces.

[david 12]

Re: If your chosen editor cannot convert tabs to spaces automatically

(some old typewriter convention or something), and still doesn’t.

The VT105 (1978) was a CRT ("Glass") serial terminal from DEC, important in the development and use of unix from AT&T and VMS from DEC. It implemented fixed 8 space tabs.

I don't think the VT52 (1974) had tab support at all.

Earlier mechanical TTY's didn't implement Horizontal TABS, or implemented TABs with optional extra hardware that provided typewriter / card-punch "programable" tabs

[ldo]

Re: It implemented fixed 8 space tabs.

No. All members of the VT100 family had a customizable tab ruler. Tabs every 8 columns was just the default setting.

[Doctor Syntax]

Re: It implemented fixed 8 space tabs.

1. A lot of code was written on VT100s, and not only for DEC OSes.

2. Messing with defaults is simply a recipe for causing confusion. If you do it you should be condemned to spend a year debugging code which was written with a mixture of spaces, and n-spaced tabs where n varies from line to line and is any random number from 1 to 10 excluding 8 but occasionally including 12.

[ldo]

Re: Messing with defaults is simply a recipe for causing confusion

Tab stops were always like that. They were always meant to represent configurable positions on the typewriter, printer or display screen. Computer printers even had vertical tab stop settings. (And that’s why ASCII has both “HT” and “VT” control characters.)

You see why it’s a good idea to avoid tabs for formatting?

[Bebu]

Re: If your chosen editor cannot convert tabs to spaces automatically

《I don't think the VT52 (1974) had tab support at all.》

There are no terminfo entries for vt52 for hts or st (termcap.)

I use tabs as field separators and use a program (detab) to convert the tabs to required number of spaces to move the fields to the arbitrary specified columns.

Displaying texts in proportional typefaces containing tabs is never going to be pretty.

You can display text containing tabs nicely by setting (pseudo)terminal's tab stops normally by using the tabs program (part of ncurses) (which is faulty on RHEL7, fixed in RHEL8.)

I still think Linus is right in requiring parsers to parse white space when such white space has no syntactic role other than separating tokens. (Postel's law. ;)

I never warmed to languages that use indentation to delineate block structure but it does go back to 1966 (Peter Landin.)

[thosrtanner]

Re: If your chosen editor cannot convert tabs to spaces automatically

Because having your first tab at 8 was REALLY useful on card punches when writing fortran, You *could* technically start your code in column 7, but it looked confusing if it came immediately after the whatever symbol you were using that day in column 6 for a continuation line.

[swm]

Re: If your chosen editor cannot convert tabs to spaces automatically

For cards punched on an 029 all you had to do was create a card for the program drum.

[Jou (Mxyzptlk)]

Re: Semicolons and curly braces, forever.

and way too many man pages skip the "userful examples" part? 'cause expecting that all tools use the same command line "logic" and are so "bloody obvious, you don't need an example"?

[Roland6]

Re: Semicolons and curly braces, forever.

I remember some of the early Unix documentation was simply papers/articles which gave examples and defined a few of the parameters, leaving the reader to discover the full parameter list for commands such as tar, dd. A task not made easy without access to source code.

[Ken Hagan]

Re: Semicolons and curly braces, forever.

Hmm. Learning how dd works by trial and error sounds interesting.

[Vometia has insomnia. Again.]

Re: Semicolons and curly braces, forever.

I learnt that conv=ebcdic and conv=ibm aren't the same thing. By which I mean I learnt the hard way, obvs.

[jake]

Re: Semicolons and curly braces, forever.

The dd source was readily available to anybody who had access to Research UNIX v5 or higher, where it was introduced.

The man page (dated May 15, 1974) is just under a full page in the UNIX Programmers Reference, 5th Edition, June 1974. (My copy is old, brittle, coffee and/or Guinness stained, very dog-eared, and hadn't been out of my trophy case in a couple decades until just now ...).

The C file is quite small, and easily readable. I remember no real problems learning to use the tool way back when ... even though it seemed more JCLish than UNIXish syntactically. Someone at Berkeley (probably one of Bob Fabry's grad students, possibly Bob himself) was going to fix it to be more UNIX-like, but it never happened. The program worked, and there were many more important fish to fry.

[jake]

Re: Semicolons and curly braces, forever.

If you had access to UNIX back then, you had access to the source code.

[that one in the corner]

Re: Semicolons and curly braces, forever.

It is so nice to have code that is safe against whitespace being messed up by being pasted into a badly behaving email system or shoved into a wordprocessor document when you ask them to "just send me a copy of the bit you are talking about".[1]

Or they've somehow managed to convert the entire lump of code into a single line of text! With the braces in place you can pass the resulting mess through a pretty printer and make it legible again.

Ah, meaningful whitespace in a language that is suitable for teaching neophytes to code, what could possibly go wrong.

[1] Yes, you *would* hope that anyone who believes that they could learn to code would be capable of following instructions to just zip up their source file and attach that to an email, but...

[ldo]

Re: accidental stray indent or outdent

I decided early on in my Python code to add “#end” comments to mark the ends of compound statements. I also have custom editor commands defined to jump between lines with matching indentation. This makes it easier to ensure that things are properly nested.

A (small) example:

def set_wakeup_main_function(self, wakeup_main, data, free_data = None) :

␣␣␣␣"sets the callback to use for libdbus to notify you that something has" \

␣␣␣␣" happened requiring processing on the Connection."

␣

␣␣␣␣def wrap_wakeup_main(_data) :

␣␣␣␣␣␣␣␣wakeup_main(data)

␣␣␣␣#end wrap_wakeup_main

␣

␣␣␣␣def wrap_free_data(_data) :

␣␣␣␣␣␣␣␣free_data(data)

␣␣␣␣#end wrap_free_data

␣

#begin set_wakeup_main_function

␣␣␣␣if wakeup_main != None :

␣␣␣␣␣␣␣␣self._wakeup_main = DBUS.WakeupMainFunction(wrap_wakeup_main)

␣␣␣␣else :

␣␣␣␣␣␣␣␣self._wakeup_main = None

␣␣␣␣#end if

␣␣␣␣if free_data != None :

␣␣␣␣␣␣␣␣self._free_wakeup_main_data = DBUS.FreeFunction(wrap_free_data)

␣␣␣␣else :

␣␣␣␣␣␣␣␣self._free_wakeup_main_data = None

␣␣␣␣#end if

␣␣␣␣dbus.dbus_connection_set_wakeup_main_function(self._dbobj, self._wakeup_main, None, self._free_wakeup_main_data)

#end set_wakeup_main_function

[Jou (Mxyzptlk)]

Re: accidental stray indent or outdent

> ␣␣␣␣#end if

I use similar style on closing brackets if the amount of code between extents 80 or 120 lines, depending on the code type between, to mark the ending which belongs to that opening... Latest example from "Growatt MIC via RS485 + Shelly 3 EM pro + other data to decide where to use the solar power using powershell" stuff:

if ($HourOfDay -ge 4 -and $HourOfDay -le 22) {

# more than 190 lines of code, using above opening bracket style since I don't like wasting space, closing bracket on extra line is enough

} # if ($HourOfDay

[Anonymous Coward]

Re: accidental stray indent or outdent

If you have more than a handful of lines between the IF and ENDIF, particularly if you can't see them both on the screen at the same time, you should probably move all those lines into a nicely named function.

Similarly if you have more than 2 or 3 levels of indentation.

[yetanotheraoc]

Re: accidental stray indent or outdent

"If you have more than a handful of lines between the IF and ENDIF, particularly if you can't see them both on the screen at the same time, you should probably move all those lines into a nicely named function."

Now you need and ENDIF and an ENDFUNCTION. :)

[Roland6]

Re: accidental stray indent or outdent

People who obviously only write and view code on screen, in days of yore, the line printerwith fan fold paper was your friend…

Personally, the issue was one of balance, nicely structured and readable code with lots of nested functions that run slow or larger less readable code (well without the fanfold printout) which could run with less overhead.

Obviously when writing real-time code (back in the 1980s) in memory constrained systems, you avoided excessive function calls.

[Anonymous Coward]

Re: accidental stray indent or outdent

So now you have a profusion of functions called from only one place, each of which likely exceeds that "more than a vertical screen" metric anyway. This does not seem like an improvement.

[Jou (Mxyzptlk)]

Re: accidental stray indent or outdent

> move all those lines into a nicely named function

Ah, functionitis, making a function of something which is only used once just to have a function. While the mentioned script is not function-free for things needed several times along the run, creating functions where it does not make sense complicates the code, makes it less readable, longer, and more difficult to debug.

[swm]

Re: accidental stray indent or outdent

Anonymous classes are my friend in Java.

[the spectacularly refined chap]

Re: accidental stray indent or outdent

If you have more than a handful of lines between the IF and ENDIF, particularly if you can't see them both on the screen at the same time, you should probably move all those lines into a nicely named function.

Similarly if you have more than 2 or 3 levels of indentation.

Personally I always cringe when I see arbitrary limits on length of code, a lot of unnecessarily contorted and fundamentally inscrutable code has resulted from it. Functions should do a comprehensible job, not half of one. Functions that operate on a data structure should take a generally valid data structure (or valid substructure) as their input, not some in progress half-updated mutant whose rules for validity only exist in the mind of the coder thinking on the hoof. Any notion that a function/block/whatever should be not more than x lines, one screen or one page can be sunk when you raise the possibility of a 1000 line switch statement. That isn't theoretical, it can and does happen inside complex state machines - OSPF is always the example that comes to mind. Yes, understanding the monster as a whole is complex, it's an inevitable consequence of a system that is itself complex. Individual terms can remain trivially easy to understand as they operate independently, it's deeply nested "wide" code that is difficult to follow, not "long" code.

Yes, "wide" code is a problem but in my experience it is too frequently a symptom of poor logic than anything stylistic. It indicates a need for a structural rethink as opposed to changing the layout. A perennial issue is lack of break and continues - I've even seen them described as bad style in themselves. I embrace them, it is a natural and concise method of saying "I am done with this task" or "I am done with this node" that avoids a lot of unnecessary control logic contributing several layers of indentation by itself.

[david 12]

Re: Semicolons and curly braces, forever.

I can't count the number of wasted hours I've spent trying to find bugs in c or BASIC or Fortran or Pascal trying to find mismatched brackets (or end, or ; or next)..

The pages of hardcopy print out with a pen matching up braces. Poring over compilation failures flagged --at the end of the file --, not where the error was. The logic errors caused by dangling IFs.

It's like people who complain about the error-prone nature of electronic spreadsheets: they weren't around in the era of paper spreadsheets, and they never grok that electronic programs have eliminated far more errors, and far more serious errors, than they have created.

[ldo]

Re: trying to find bugs in c or BASIC or Fortran or Pascal trying to find mismatched

Surely all the good editors provide standard commands to match up bracket symbols nowadays?

[TheMeerkat]

Re: trying to find bugs in c or BASIC or Fortran or Pascal trying to find mismatched

All good editors today format code that uses brackets and semicolons nicely automatically as you type. And can reformat code if one wishes.

Which eliminates the issue of mismatched brackets.

[ldo]

Re: All good editors today format code

Assuming you can control the rules they use, rather than have them impose their own rules on you.

For another example of my style:

LIBNAME = \

␣␣␣␣{

␣␣␣␣␣␣␣␣"linux" :

␣␣␣␣␣␣␣␣␣␣␣␣{

␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"cairo" : "libcairo.so.2",

␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"freetype" : "libfreetype.so.6",

␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"fontconfig" : "libfontconfig.so.1",

␣␣␣␣␣␣␣␣␣␣␣␣},

␣␣␣␣␣␣␣␣"openbsd6" :

␣␣␣␣␣␣␣␣␣␣␣␣{

␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"cairo" : "libcairo.so.12",

␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"freetype" : "libfreetype.so.28",

␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣"fontconfig" : "libfontconfig.so.11",

␣␣␣␣␣␣␣␣␣␣␣␣},

␣␣␣␣}[sys.platform]

[swm]

Re: All good editors today format code

(defun (fact n)

(if ((eql n 0)

1

(* n (fact (- n 1)))))

[ldo]

Re: All good editors today format code

My way:

(defun set_tab_expansion (expand)

␣␣␣␣"changes tab expansion setting for current buffer."

␣␣␣␣(interactive)

␣␣␣␣(cond

␣␣␣␣␣␣␣␣(expand

␣␣␣␣␣␣␣␣␣␣␣␣(setq indent-tabs-mode nil)

␣␣␣␣␣␣␣␣␣␣␣␣(message "tabs will be expanded to spaces")

␣␣␣␣␣␣␣␣)

␣␣␣␣␣␣␣␣(t

␣␣␣␣␣␣␣␣␣␣␣␣(setq indent-tabs-mode t)

␣␣␣␣␣␣␣␣␣␣␣␣(message "tabs will not be expanded to spaces")

␣␣␣␣␣␣␣␣)

␣␣␣␣) ; cond

) ; set_tab_expansion

[Doctor Syntax]

Re: trying to find bugs in c or BASIC or Fortran or Pascal trying to find mismatched

Memory says there was once a program called cb (C beutifier) which sorted things out for you.

Nowadays it seems you're expected to use some online service to do that. You're going to paste all your employer's trade secret code into an some unknown online site? Really?

I have no information to say such sites are anything but honest and upright but nevertheless that would have to be regarded as a massive security breach.

[Vometia has insomnia. Again.]

Re: trying to find bugs in c or BASIC or Fortran or Pascal trying to find mismatched

I was a bit perturbed when I had to get used to cb's absence; it was really nice for sorting out mangled code, or just code which used the "wrong" formatting style (often my own in both cases). I occasionally use indent nowadays but it has about eleventy billion options and sometimes it's quicker just to indulge some regex unpleasantness in vim.

[tatatata]

Re: Semicolons and curly braces, forever.

No. it is not just you. It is one of the reasons I dislike Python. I have, after 40+ years, finally got used to the space/tabs in the Makefiles. I am also not a fan of YAML.

And for those who seem to be ok with these whitespace-horrors, please try to write anything usefull in Whitespace (the programming language). Or anything at all.

[Herring`]

Re: Semicolons and curly braces, forever.

In a previous life, I spent a lot of time doing stuff with Lex & Yacc. When I saw python and whitespace having syntactical significance .... No.

[m4r35n357]

A stand against software leniency

Coding against idiocy has led directly to the bloated mess that is the web stack. Important stuff _should_ go bang if it is wrong!

[bazza]

Re: A stand against software leniency

Indeed.

It’s interesting that the language du jour Rust is widely applauded and has some entirely new and powerful ways of pointing out the one’s code is the product of a klutz who should not be allowed near a keyboard. That’s kind of the ultimate anti Web tech reaction.

[bazza]

I Hate Syntax Critical Whitespace Indentation

As per title.

If you’re the type of coder who likes it, go and write in Whitespace (as in the actual programming language) and then say it’s still a good idea. You’re already half way there if you like Python or Yaml.

It’s a really bad idea that something a computer won’t show or print and, more importantly, cannot be seen to be missing should be considered syntactically important.

[Doctor Syntax]

Re: I Hate Syntax Critical Whitespace Indentation

Quite. Don't make what should be explicit implicit.

[Marcelo Rodrigues]

Re: I Hate Syntax Critical Whitespace Indentation

"I Hate Syntax Critical Whitespace Indentation "

Indeed, You and me both.

We can argue about which format indentation is better (8 spaces? 4 spaces? new line before and after curly brackets or just after?), but white space as a syntax? No, it's one of the worst things I can imagine. We already have problems finding a comma transmuted into something else. Imagine one white space gone astray...

[Dan 55]

!(Postel's Law)

Seems Linus is being liberal in what he sends, not conservative. And parsers are being conservative in what they accept, not liberal.

[petef]

Postel's Law considered harmful

Postel's Law which whilst admirable in 1980 has since become discouraged for reasons of security.

[Mike 125]

Re: Postel's Law considered harmful

> Postel's Law considered harmful

By definition, a secure system can unambiguously determine the difference between what matters and what doesn't matter.

So it can perfectly well afford to be liberal in what it accepts.

And for the same reason, it will be inherently conservative in what it sends.

Postel's Law is just fine.

[Roland6]

Re: Postel's Law considered harmful

> So it can perfectly well afford to be liberal in what it accepts.

And be precise I why it has rejected some input.

[RedGreen925]

"It should weed out the weaker tools, leaving only the fitter, better-adapted ones… while not publicly hurting anyone's feelings."

Yes the anti-social behavior training was a stunning success. Like the racists and fascists of old did he just hides it better now, even as they come out from under their rocks to enjoy the full light of day with their mainstream acceptance by more and more scumbags among us ......

[Doctor Syntax]

Your generosity of spirit is an example to us all.

[Paul Hovnanian]

A strange battle

I've seen it posted elsewhere that Kconfig files have allowed tabs as whitespace for some time now. Meaning that _existing_ parsers should not have choked on tabs. Or this would have been an old problem.

But it seems that being against tabs (anywhere) has reached the level of dogma among some people. Whether the parser developers just hoped that the FTRACE_RECORD_RECURSION_SIZE change request would go through and they deleted their tab handling in optomistic anticipation, or their parser change was made to force the issue, we may never know.

But it seems that Linus doesn't want this dog fight in his back yard. Good for him.

[Anonymous Coward]

Chop his pay!

He does realise he’s going to get paid less for using tabs?

https://www.theregister.com/2017/06/16/spaces_vs_tabs/

[sabroni]

FFS

Formatting is to make it easy for humans to read.

Keep the language in the visible characters and let a formatter make it readable.

Anything else is putting the computer first. They're tools for us, they're supposed to lay things out to keep us happy......

[Anonymous Coward]

Easy peasy

Just pipe kconfig files through expand before they reach your broken parser. Defect fixed!

[Anonymous Coward]

No mention here of C.......

.....perhaps because C pays no attention at all to indentation!!

For those of you with a taste for SERIOUSLY bizarre C sources, take a look at the winners of the Obfuscated C competion (https://www.ioccc.org/).

Of course in the debate about {} in C, there's also the rule that {} is not required in some places where a block is only one statement long!!

Yup.....C is very fast to execute.......but often very slow.w.w.w.w.w.w...... to debug!!!

[Roland6]

Re: No mention here of C.......

At least C supports comments…

I remember writing an awk script, the final script was practically unintelligible, hence the documentation consisted of the steps I took (with commentary) to develop the implemented logic(*) and then fold it into the final script.

(*) the requirement was something that was simple to express in English, but not so easy to codify.

[sfjuocekr]

And why is using tabs more complicated?

I fail to see the point here, but I'm also easily annoyed by inconsistent use of whitespace... especially when you want to fix it and submit a pull request most developers are downright hostile towards you.

[Jou (Mxyzptlk)]

The evil mix

Did noone mention this variant yet?

SpaceSpaceTabSpaceTabSpaceSpaceSpaceTab = 12 columns. Parse this!