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.
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 …
COMMENTS
-
-
-
-
Wednesday 17th April 2024 16:50 GMT 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...
-
Wednesday 17th April 2024 23:18 GMT 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 emacs1. 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.
1emacs is not so much an IDE as a shell with a really ambitious command-line editor.
-
Thursday 18th April 2024 03:29 GMT 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.
-
-
-
-
-
Tuesday 16th April 2024 22:39 GMT 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.
-
Tuesday 16th April 2024 23:35 GMT 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.
-
Wednesday 17th April 2024 01:19 GMT 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.
-
Wednesday 17th April 2024 02:05 GMT 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)
-
Wednesday 17th April 2024 04:36 GMT 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.
-
-
Wednesday 17th April 2024 11:47 GMT 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....
-
-
-
Wednesday 17th April 2024 14:29 GMT 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.
-
Wednesday 17th April 2024 23:28 GMT 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)
-
-
-
Wednesday 17th April 2024 01:52 GMT 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.
-
Wednesday 17th April 2024 12:51 GMT 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.
-
-
-
-
-
-
Tuesday 16th April 2024 19:26 GMT 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.
-
Tuesday 16th April 2024 21:47 GMT 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.
-
-
Tuesday 16th April 2024 19:44 GMT 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.
-
Tuesday 16th April 2024 22:51 GMT 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).
-
Wednesday 17th April 2024 00:08 GMT 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.
-
-
Friday 19th April 2024 07:23 GMT 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.
-
-
-
-
Tuesday 16th April 2024 21:23 GMT 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.
-
-
Tuesday 16th April 2024 21:52 GMT 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.
-
-
Wednesday 17th April 2024 00:12 GMT 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.
-
Wednesday 17th April 2024 02:59 GMT 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
-
-
Wednesday 17th April 2024 09:47 GMT 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.
-
Thursday 18th April 2024 00:17 GMT 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?
-
-
-
Wednesday 17th April 2024 08:54 GMT 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.)
-
-
Wednesday 17th April 2024 07:35 GMT 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.
-
-
-
Wednesday 17th April 2024 13:15 GMT 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.
-
-
Thursday 18th April 2024 23:11 GMT 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.
-
-
-
-
Tuesday 16th April 2024 23:58 GMT 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...
-
Wednesday 17th April 2024 00:06 GMT 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
-
Wednesday 17th April 2024 05:11 GMT 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
-
Wednesday 17th April 2024 11:29 GMT 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.
-
Wednesday 17th April 2024 12:05 GMT 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. :)
-
Wednesday 17th April 2024 13:17 GMT 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.
-
Wednesday 17th April 2024 15:31 GMT 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.
-
Wednesday 17th April 2024 16:02 GMT 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.
-
-
-
-
Wednesday 17th April 2024 02:16 GMT 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.
-
-
-
Wednesday 17th April 2024 09:13 GMT 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]
-
-
Thursday 18th April 2024 04:56 GMT 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
-
-
-
-
Wednesday 17th April 2024 09:57 GMT 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.
-
Thursday 18th April 2024 09:30 GMT 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.
-
-
-
-
Wednesday 17th April 2024 14:42 GMT 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.
-
-
-
Tuesday 16th April 2024 19:34 GMT 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.
-
-
Tuesday 16th April 2024 19:21 GMT 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.
-
Wednesday 17th April 2024 15:46 GMT 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...
-
-
Wednesday 17th April 2024 08:11 GMT 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.
-
-
Tuesday 16th April 2024 23:26 GMT 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 ......
-
Wednesday 17th April 2024 02:48 GMT 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.
-
Wednesday 17th April 2024 10:14 GMT 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!!!
-
Wednesday 17th April 2024 13:29 GMT 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.
-