Tabs vs spaces

Not exactly on-topic, but I HATE (mildly said) "indentation" languages where indentation determines blocks! Like in Python.
One space somewhere and you could be screwed for hours chasing a Stupid thing. And there spaces/tabs mixture can be disastrous.
In other (normal) languages a space here or there used sparingly and on purpose can be helpful but for main indentation I see almost no use for them. Of course tabs are the way to go for multiple reasons.
 
Not exactly on-topic, but I HATE (mildly said) "indentation" languages where indentation determines blocks! Like in Python.
One space somewhere and you could be screwed for hours chasing a Stupid thing. And there spaces/tabs mixture can be disastrous.
In other (normal) languages a space here or there used sparingly and on purpose can be helpful but for main indentation I see almost no use for them. Of course tabs are the way to go for multiple reasons.

Umm, Python doesn't let you be inconsistent. It'll throw a TabError, and it'll show you where it is.
Any IDE will do the same.

You can also define how tabs/spaces are handled in most editors and nearly all IDEs.

Doesn't seem like you're up to date on modern programming in Python.
 
Spaces tripping you up? Pfffsst.. you haven't lived until core dumping due to a missing period. lol. ;)

20190313_cobol.png


FYI
https://www.masswerk.at/keypunch/
https://www.masswerk.at/cardreader/
 
Umm, Python doesn't let you be inconsistent. It'll throw a TabError, and it'll show you where it is.
Any IDE will do the same.

You can also define how tabs/spaces are handled in most editors and nearly all IDEs.

Doesn't seem like you're up to date on modern programming in Python.
I got to know about Python just recently. I don't have extensive experience. I even tried PyCharm as IDE. This doesn't have anything to do with my opinion and facts. You could happen to need to edit something in a plain text editor or something. Not even mentioning if you happen to need to copy/paste code from different sources (web, skype, other IM) where blanks could be stripped etc. etc... Ugly outcome.
Apart from mixture of spaces and tabs, I LIKE being able to be inconsistent if I want to in specific cases. The point is, this indented programming is only "invented" for people who fidn it "easy" to program blocks using visual indenting. This makes it much more dangerous than "normal" languages where you use normal tokens to define blocks.
 
I got to know about Python just recently. I don't have extensive experience. I even tried PyCharm as IDE. This doesn't have anything to do with my opinion and facts. You could happen to need to edit something in a plain text editor or something. Not even mentioning if you happen to need to copy/paste code from different sources (web, skype, other IM) where blanks could be stripped etc. etc... Ugly outcome.
Apart from mixture of spaces and tabs, I LIKE being able to be inconsistent if I want to in specific cases. The point is, this indented programming is only "invented" for people who fidn it "easy" to program blocks using visual indenting. This makes it much more dangerous than "normal" languages where you use normal tokens to define blocks.
I mean sure, if you want to be an awful hack, go for it. For those of us who use the language and know how it works, your response is amusing. Never mind the fact you won't find a job (or keep one long) with that attitude and poor programming technique. I know Java and C++ programmers who are more fanatical over indentation than Python programmers. Good luck in your career. :cool:
 
Don't worry about my career :) . "My" languages are all braces-based and fortunately the ONLY ubiquitous "indentation" lang that I may one day need for anything is Python. You may find whatever yo like amusing and all but fanaticism is not something that has to do with sane arguments etc. and is not appropriate for our discussion, I'm sorry. It's not a good testimonial in any activity.
One argument that I'll reiterate is one stray space somewhere would not break any braces-based language. Which ever is important for me is code stability, reliability and not a fanatic love for indentations because they forced a style. I can give examples of fanatical people who are more fanatical than your Java folks and who kill people, is that relevant?! Me too, I keep indentations everywhere but that had nothing to do with my hate about forcing indentations to define blocks because it has more drawbacks than it solves. A good programmer doesn't need to be restricted this way, and the bad programmer would write buggy code regardless. Thus speaking, good luck in Your career.
Python might be ubiquitous today and I use it for small things, that doesn't mean I cannot hate aspects of it.
 
Last edited:
tab, 2 or 3 space-wide; mainly 3 ; hate 8 ... but its just me ...
oh, and I could never marry a wife who put the { in the same line ... never ...
{
}
 
I think this post deserves a poll. My opinion toward spaces versus tab is a personal preference. However if it is a coding standard mandated whether it is spaces or tab by the company then I am fine with that as well.

I personally prefer spaces over tab but that is just me.

Regarding with Python, for people who need to read spaghetti (messy) code from a day-to-day basis whether you are fixing a bug or inherited a big piece of legacy code, the way how Python enforces indention is just brilliant. It does make the code more readable (at least that's how I feel about it).

That's just my two cents.
 
beyonddc, no, Python plain fails on the most important aspect - the argument it forces indentation is its biggest drawback. The fact you stand behind "spaces" is "brilliant". It's not that about personal preference - it's about arguments.
Most important arguments are towards tabs. And what's your arguments in favor of spaces?
I have the freedom to write spaghetti code IF I like, and I like the small "moments" where I have this freedom to indent some code some more or to wrap a line with another indent. It's not my style of coding but sometimes it's easier to do such small things. And no, those small things don't impede comprehension of code - only a totally bad programmer would say that. That was about Python's (and other) forced indentation style.
 
once i found out i could have my editor map my tab key to insert 2 spaces, i didn't care about tabs vs spaces...
 
I think of it as an all or nothing situation. I had to design a compiler at one point and ignoring whitespace whether it is tabs or spaces is far easier when building the scanner,symbol table, and parser. In practice I rather like python's style of spacing. This is coming from a C background.
 
Tabs only, pressing space 2-3 times is inefficient in terms of typing speed.
 
tab, 2 or 3 space-wide; mainly 3 ; hate 8 ... but its just me ...

Where I work, we have a department requirement to use 3 spaces instead of tabs. (If you can configure a tab to be 3 spaces, that's OK. But no Tab character; it breaks some embedded file parsers).

oh, and I could never marry a wife who put the { in the same line ... never ...
{
}

We're in the minority, but yes, I very much prefer braces on their own lines.
 
The closing brace yes, but the opening brace if on its own line, is unnecessary waste of vertical space :) . Even if I'm on a 60" 8K screen, it would contain much more code and not waste a line for { . I spent hours in the past examining the effects and "ease of use and read" of code both ways. Then I used both approaches in the years after... and finally, for over a decade I use { on the same line and never looked back.
 
Vertical bias:
Code:
if ( true )
{
    ...
}

Horizontal bias:
Code:
if ( true ) { ... }

Compromise:
Code:
if ( true ) {
    ...
}

I use Compromise as default preference for bracket opening/closing. The thing I like about Compromise is that it guarantees a (virtual) space between the next statement. It even looks better than using no braces at all. Having some (not a ton) vertical space make code easier to read. However, I will fall back to Vertical if the expression before the opening brace has to be broken into multiple lines (see example below). It will look awkward otherwise.

Horizontal only works if the expression and block are extremely short and can all fit on one line. Short as in a one or two word (not compound) statement. Anything more and I find it really awkward as your brain has to parse out what is the expression and what is the statement. It's much more natural to have the expression and statement on separate lines. Seeing code with multiple statements on the same line is annoying enough already.

I'm always on the fence when it comes to tabs vs spaces. I think tabs are useful when used sparingly and only when left justifying a block. Tabs just don't work when an expression must be continued on the next line.

Tabs:
Code:
if ( a == x &&
    b == y &&
    c == z )
{
    return;
}

Spaces:
Code:
if ( a == x &&
     b == y &&
     c == z )
{
    return;
}

(I realize the expression above is concise enough to fit on one line, but use your imagination as real world variable names are much much longer. This type of compound expression where a line break is inevitable happens a lot more than you think.)

Assuming your web browser didn't pick the perfect tab spacing, in this situation, spaces simply look better. Yes, you could set your IDE to inject 4 or 5 spaces for every tab, but then you have no control over strict alignment. What happens if I use a for statement instead? What if I decide to put parenthesis around each sub-expression? Tabs are always floating and the spacing becomes variable depending on the IDE. This is fine for statement and block indentation, but not so much for corner cases like the stacked compound expression above.

(If you need yet another example, try using tabs instead of spaces with a multi-line block comment: /* ... */)

And I've used hybrid approaches before, but that ends up being more confusing to the next person who comes along who decided to modify your code using whatever IDE settings they prefer. They end up mangling your beautiful code. So to stay universally consistent, I stick with either one or the other.

An ideal IDE would detect what I'm trying to do and auto-align everything regardless of what the underlying spacing is. I've not ran into an IDE that was/is smart enough to cover almost all cases (although Visual Studio does let you configure the more common cases).

If there were ever a use-case for machine learning, code indentation beautification would be one of them.

On the one hand, tabs are more efficient (press it and move on). On the other hand, spaces make alignment picture perfect. So unless a magical solution comes along, it seems there will always be some trade-off or forced company-wide preference with neither being a clear winner.
 
Last edited:
Of course when wrapping a line on to the next one, you *might* need a space here or there, it depends on a tiny bit of style you used in your examples:
this is what I use in your example, and even if the initial comparison was on the same line as the 'if', tabs would work because I don't put spaces after the opening parenthesis (in the default 4-spaces tab config).
Code:
if (
   a == x &&
   b == y &&
   c == z
) {
   .....
}
Also I don't think this type of code smell/style would confuse any average programmer who might encounters my/your code etc.
It's more about the "on-next-line" wastes too much space, in my opinion at least.
 
Bah.. who is printing code off anymore? Any 'waste of space' is purely virtual. If I can quickly see if a block is closed or not by tracking vertically versus variable horizontal then all the better.

Hence - Allman/West Coast style works best. Non mandatory bracing for single line bodies.
 
Waste of space is on-screen, not talking anything about printing. Given the number of ifs and other block structures in code, I'll be scrolling much less to see more code in one screenfull no matter how big the monitor is.
Tracking blocks in IDEs is solved long ago - they will track the block with vertical lines with both styles equally well. The only important thing is the correct indentation of at least the first line after the { :) so it's visually clear.
 
Back
Top