Pythonists are obsessed with standardizing and requiring something they call "white space" and then have the gall to call *us* the racists!
Pure projection (Assuming they've imported numpy).
modern aloof run worthless attraction many dinosaurs squealing swim frighten
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
If you install extension showing the straight lines for indents, it's also clear where the scope ends. I don't understand this whole discussion, both solutions are clear if used correctly
3 nested blocks is still a pretty reasonable number or screw that even just 2 and suddenly indentation could be a real fucker cause you accidentally deleted a space and some line executes in a higher closure
I always wonder how people think that would happen. Apart from some very real scenarios like when you’re generating dynamic code (you‘ll need to just get it right here) to be executed or when you‘re running a reformatting tool on your codebase (please make backups and test after reformatting) how concretely would it happen?
If you‘re so paranoid about the possibility of some whitespace being dropped how can you be sure a curly brace based scope system is absolutely safe towards these kinds of mistakes?
Well missing a curly bracket is a lot more visible and the ide usually shouts at you about it.
An accidental key press before running the code can easily delete a whitespace
Counter = 0
for n in x:
//Do some shit
Counter++ // if unindented, the value of counter changes and there is no error
Print(counter)
Excuse the syntax, I'm on mobile
Protip: don't unindent random parts of your code for no reason.
This is a problem I've literally never had in like 5 years of python. Do people really just go through their code base unindenting random stuff? Maybe stop that.
Now a problem that I have seen (and done) comes from people omitting the brackets for single statement loops/conditionals, because even the people that claim to love them don't really. Then they try to add a second statement, but forget to add the brackets that they need now, so by indentation (what we actually look at, ain't no one counting brackets) it looks right, but it's actually not.
Yeah, if you're gonna use braces for this sort of thing, that's the way to do it. Which I don't mind, it's not like braces tend to make things much worse (though now python just looks cleaner to me). I'm cool with braces existing if people want them, I'm just amused by people acting like python not having them is some huge hurdle to overcome, as if any one of us actually bothered to look at the braces in decently formatted code anyway.
I‘ll tell you that in two years of developing python I have not once run into that issue.
I agree that in the case of curly brackets missing them is less likely because the code won‘t even compile, but the danger is not missing a bracket, but misplacing one. If you work with proper indentation it‘s not the hardest thing in the world to determine whether your else clause belongs outside the third or fourth closing curly brace but it‘s still less intuitive than just checking which line of code is straight above it.
It is generally recommended not to nest anything deeper than 3 or 4 levels. If it‘s more complicated than that it get‘s broken down into smaller pieces.
Don't accept prs with crappy code. And having dealt with both legacy C code and legacy Python code, then sins I've seen in the C code were much worse, despite it having braces.
Adding to this, if your company has a style guide, enforce it on PRs. If your company doesn't have one, write or adopt one (e.g., google [publishes](https://google.github.io/styleguide/cppguide.html) their style guides) and enforce that.
As for the horrors of people not following style guides, the most frustrating one I've ever seen is actually in python. There was a function that was being called. I wanted to know what it did because I was trying to track down a bug and the stack trace went through it. I grep'd the whole code base, but the call site was the only place that it existed. The function wasn't defined **anywhere** in the code base. It took me forever to realize that the author had used metaclasses to define the function (which are banned by our style guide) and it took me even longer to figure out what the function was doing.
> What about the others?
They can switch professions to do a job they're actually qualified for, like doorstop or paperweight.
> What about legacy?
Fix it like other legacy errors?
Damn! All that just because you prefer significant white spaces? Hahahaha.
Holy shit. What a fanboy! I thought refactoring was about logic and architecture :-)
as someone who writes both I can say that both can be clear and both can be unreadable shite.
this is a developer skill issue, not a problem of the languages.
who woulda thought that IF/ELSIF/ENDIF are the actual braces/colons/brackets/pairs
God in COBOL it used to be a PERIOD
how anything other than IF/ELSIF/ENDIF are used by the myriad of languages is beyond me
What is wrong with an explicit terminator
The problem with Python example is the fact the WHITE SPACE matters. E.g - move the last line one tab to the left, and you just took it out of the 'else' scope. Do the same on languages that mark scope with curly braces - and nothing terrible happens, just a tiny cosmetic issue at worst.
White space shouldn't be part of the code, Python disagrees.
Using an invisible character as a code instruction (in if or out of if) always felt terrible.
At least lint has improved it all, but still very easy to get confused to me.
The only time that this is ever a problem is when you're doing a merge, say, and trying to resolve a change that nested some code. The change in indentation can screw things up.
But when I do a merge in c++, sometimes I'll accidentally clobber a brace and get a problem anyway. But odds are that when this happens in c++, the compiler will catch it.
> only time that this is ever a problem is when you're doing a merge
Or a refactor. Extract _most but not all_ of a block into a new function, need to un-indent it, oops accidentally un-indented something that was left behind, have a free bug.
Like, I don't hate python by any means, but whitespace-based blocks are fragile in ways that explicit blocks aren't. We shouldn't pretend that they aren't.
Which is why Google coding style requires braces always, even for one-liner blocks.
I would argue that a one-liner without braces is even more dangerous than the significant whitespace of python.
This isn't true--though I wish it was. [The guide](https://google.github.io/styleguide/cppguide.html#Formatting_Looping_Branching) allows omitting of braces for one-line statements or for statements where the condition fits on one line and the body fits on another:
> For historical reasons, we allow one exception to the above rules: the curly braces for the controlled statement or the line breaks inside the curly braces may be omitted if as a result the entire statement appears on either a single line (in which case there is a space between the closing parenthesis and the controlled statement) or on two lines (in which case there is a line break after the closing parenthesis and there are no braces).
My company uses the google c++ style guide, but I don't approve things that omit the braces.
I worked at Google and I didn't remember that being allowed. Anyway, fuck that. Apple literally had a major security flaw because of exactly this.
https://oscarbonilla.com/2014/02/could-this-recent-apple-bug-be-a-bad-merge/
The two seconds that it takes to put in the braces is well worth the possibility of preventing a bug in security software! Security software should have strict standards!
Google style got this one wrong. In my time there, I don't remember reviewing any code that did this.
Making something not compile is better than catching it by testing. This is like saying garbage collection and rust's borrowchecker is worthless because valgrind exists.
YAML has far more problems than just being whitespace dependant lol
[https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
I don't understand why this is such an issue for people. As if the code base you're working on doesn't have style guides for white space you have to follow anyway.
The great thing about the way python does it is that style guides are basically identical across the entire language. Everyone follows PEP8 so you don't have to get used to a different style guide again when you're reading a new code base.
>White space shouldn't be part of the code, Python disagrees.
You'reright,whitespacehasnoplaceinlanguage,it'scompletelyunnecessary.Idon'tseewhyanybodyshoulduseitanywhere.It'sbesttojustgetridofitall,unlessyouwanttowritepolyglotcodethatalsorunsintheWhitespaceinterpreter.
Okay, but still. How many of us REALLY write code without proper indentation? And if you're going to indent properly anyway, why should you repeat yourself with braces?
I am firmly of the opinion that we should be using automatic brace insertion rather than automatic indentation. Both of them use one part of a programmer's input to provide the other, and brace insertion uses the much more visually obvious one as its basis. Python simply does the brace insertion at runtime, fully automatically.
>Okay, but still. How many of us REALLY write code without proper indentation?
The problem is not when writing code, it's when modifying code, where it's quick to make mistakes. You want to refactor some stuff, you copy paste, you screwed the indentation, you have a bug.
The goto fail from apple was partly because wrong indentation made it look ok. It would not have happened if they used braces.
And yet the goto fail didn't happen in Python, so that can't really be blamed on "significant indentation", can it? It was a failure of process, nothing to do with the language.
Maybe if people cared more about indentation and less about braces, they'd notice these sorts of bugs more easily.
>Maybe if people cared more about indentation and less about braces, they'd notice these sorts of bugs more easily.
The point is that the bug could go through because the people reviewing it cared more about the indentation than about the braces. If they did, they'd have spotted the bug.
>The point is that the bug could go through because the people reviewing it cared more about the indentation than about the braces.
And if there hadn't BEEN braces in the language, the indentation would have defined it, and there would have been no bug. Alternatively, if there'd been automatic brace insertion, it would have followed the indentation, and fixed the bug.
The indentation was right and the braces were wrong. This is not an unusual situation.
>And if there hadn't BEEN braces in the language, the indentation would have defined it, and there would have been no bug.
Indeed, but as said above, that makes the code more fragile and more prone to bugs during modification and refactoring.
>Alternatively, if there'd been automatic brace insertion, it would have followed the indentation, and fixed the bug.
>
>The indentation was right and the braces were wrong. This is not an unusual situation.
It is an unusual situation considering every IDE or even text editor is able to automatically fix the indentation, and many automatically do it on save or after a few seconds of inactivity. Except Apple's apparently...
The goto fail is a combination of the bad practice of not using braces for one line blocks and the reliance on indentation by the people reading it.
Using braces absolutely define your blocks and make such mistakes nearly impossible.
>Indeed, but as said above, that makes the code more fragile and more prone to bugs during modification and refactoring.
Maybe you need better tools? I've never had any issues with that, and I've been working in Python for many, MANY years. Also, in all my non-Python projects, I maintain proper indentation, even during "modification and refactoring". It isn't hard.
>Using braces absolutely define your blocks and make such mistakes nearly impossible.
Using indentation does, too. There's no fundamental difference here.
I shouldn't have to care about how you define proper indentation.
I can copy-paste easily when this is done through braces. Otherwise, i am going to need an IDE that does formatting for me. And before you go there, yes, I want to be able to code without an IDE, just a simple text editor if and when needed.
Even with an IDE, the only reason I trust it to add indentation is that it's only there for readability.
You can't trust the IDE to chose between
if (foo)
bar();
bar2();
and
if (foo)
bar();
bar2();
It just makes it easier. I can simply paste something and use my IDE's formatter to make the indentation look nice, without worrying about aligning everything correctly.
>E.g - move the last line one tab to the left, and you just took it out of the 'else' scope.
But why would you do that? Is this a real problem people have, or does it just bother you on animal level that it's possible? I don't even use python often, but I've never accidentally put anything into a wrong scope. I also always properly indent my non-python code because I'm not a monster
You wouldn't do that on purpose, but when copy pasting something or simply getting interrupted while working it can happen. Also, if you have a cat or kids.
Using curly braces, it's very unlikely you'd accidentally delete both of them without getting an error.
Without curly braces, the code will compile and "work". You better hope the method you inadvertently corrupted is used often enough for you to notice immediately.
The problem with curly braces example is the fact that the white space DOESN'T MATTER. E.g. you move the last line one tab to the left - but it is still in the 'else' scope, even though it looks like it isn't. Do that on languages that mark scope with indentation - and you moved it out of the scope, just as intended.
Sometimes white space should be a part of the code - `int main` is not the same as `intmain`. Curly braces disagree.
The thing is automatic formatting (which you should be using) can easily align everything when you use the curly braces but it can't do that as well when white space matters.
No, automatic formatting cannot solve the problem because you are forced to do it manually
Curly way: just put braces around the scope and IDE will make it look nice.
Python way: you MUST make your code look nice BY HAND
It’s been years since I used an IDE for Python that didn’t auto-indent after lines that are always followed by blocks (for, while, if, try, etc.).
Are you saying that if you go through to make changes, the IDE doesn’t automatically update the indents?
Edit: I suspect they are referring to more complicated code changes like pasting in code or deleting a block but not the nested block which would still be at its own indentation
int main vs intmain is being disengenuous.
White space at the beginning of a line is the problem. Ending the scope of an if statement with change of spacing is ridiculous. Spacing should be the peeve of the style of the overall program or the editor, not the language used.
How the fuck do you fuck up indentation like that anyways? your IDE will scream at you. Hell even neovim let's me know.
If your code looks like shit it shouldn't run thank you very much.
Just as you can make arguments about whitespace so too can I reflect them back about missing semicolons or missing braces. Except python simplifies it.
If you work in a sane coding environment and you move the last line one tab to the left, you will trigger your linter.
So, either you have a valid point and happen to give a bad example, or your point is moot. I sure hope it's the former, so can you give a better example?
Edit: for people who keep downvoting me, C/C++ compilers have options that prevent shitty indentations
GCC has: *-Wmisleading-indentation (C and C++ only)*
>Warn when the indentation of the code does not reflect the block structure. Specifically, a warning is issued for if, else, while, and for clauses with a guarded statement that does not use braces, followed by an unguarded statement with the same indentation.
Again, you won't be able to push to repo/prod if you mess up white spaces when you have a good linter.
Or are you saying it's okay for you to push codes like this to production?
int squaredError(float x, float y) {
float diff = x - y;
return diff*diff; // messed up white spaces here
}
With Python, this error wouldn't be just cosmetic, yes. It'd break test cases. Or if you don't have test cases (red flag here), you'll get incorrect results if you \*\*at least\*\* run your function. In the end, you won't be pushing that code.
In the end, the result is the same: can't push shitty code to main repo/production.
You seem to be living in a perfect world, with perfect linter, perfect gating on your repo, 100% coverage by tests, and what's not. In real life thing are far from perfect. Shitty white space remaining shitty white space is better, IMO, than shitty white space also breaking code.
if you need an entire step in your pipeline to watch for a very predictable kind of flaw, that means you acknowledge the existence of a flaw that you need to compensate for. It doesn't mean the flaw is not actually a flaw anymore.
`if (condition)`
`do thing a;`
`do thing b; // oops wrong scope, but it compiles and looks totally legal`
Linter would not magically know which of these two perfectly-valid scopes you intended thing b to happen in.
edit - I fail at reddit formatting, thing a is supposed to be indented and thing b is not, but I give up trying to figure out the markdown to make it happen. Totally listen to my advice on languages that are much more complex than markdown though
I write python all day every day but I think they have a point, in that braces and line terminators make parsing less ambiguous.
Having also written a bit of C, C++, and C# I can say that not being constrained by indent allows you to reformat code in some really nice clear ways.
In the end everything is a trade off. The only hard to read code I see is due to skill issues
Reminds me of
(if condition
(block (do-stuff)
(do-more-stuff))
(block (do-something-else)
(do-one-last-thing)))
OMG!
The parens!
Why can't I have curly braces or colons instead of these terrible parens!?
`(((((((((((ugh-this-is-terrible-!)))))))))))`
It objectively can mess up your control flow if you mess up the indentation because you moved it from one place to another where it had a different indentation level for example.
Making good indentation isn't harder than the correct use of curly braces. And even if you use curly braces, you shouldn't allow yourself to make bad indentation.
It automatically happens if you move code around, just look at this: https://i.imgur.com/pPLrzki.gif
At the beginnig I move a piece of code from one place to another. It is incorrectly indented by default. This curly braced language does not mind, it is still semantically correct. The auto formatter then ensures it is correctly indented as well. A language without curly braces will be semantically incorrect right after moving the code. An auto formatter will not know how to fix the indentation and it will stay semantically incorrect.
It of course isn't THAT big of a deal, but it's still a little more error-prone.
That's a valid point. Auto formatting is very useful, but it can't automate writing the code logic.
In a similar situation, I pay attention to indentation, which takes more energy.
LOL.
The fact that you use a formatter to fix code produced by others (or maybe even you) tells me that you think formatting is important. You are already fighting against your language because it deems formatting irrelevant.
I would bet real money that 99% of the people whining about whitespace in python have never actually used the language seriously.
PEP8, there are no tabs to indent, 4 spaces always.
There's nothing infuriating to be had, there's just the right way and the wrong way. Any of your devs using tabs are doing the wrong thing, and that's the end of it
Hard to say you're doing it wrong considering a python script will execute with tabs as indentation. A style guide shouldn't be a bandage for a poorly implemented system.
I don't need to go and specifically turn on whitespace highlighting in my text editor for other languages to ensure my braces are correct and consistent
For python to conflate style with substance and then force everyone to use their personal style like it's some objective truth is (say it with me now!) frustrating.
Except then the condition gets evaluated twice, which can cause some hilarious bugs (and more mundane stuff like more compute time and extra log messages and stuff) if any part of it is a function or if you're doing microcontroller stuff and a variable's volatile.
Suppose we have this code:
if condition:
if condition2:
if condition3:
if condition4:
if condition5:
function()
function()
function()
function()
function()
I find the C-Style equivalent way more readable:
if (condition) {
if (condition2) {
if (condition3) {
if (condition4) {
if (condition5) {
function();
}
function();
}
function();
}
function();
}
function();
}
Vs code has line guides for indentation. Clean and easy to read for your example. With that showing what’s what, extra curly braces and line spaces only make it less readable, however with a colored bracket extension, maybe it’s a wash.
The real clowns are the languages that went with elif/elseif (ElseIf Expression) instead of else + if (Else expression with “If” expression body)
Lots of curly bois and lots of tabby bois have made this rookie mistake!
I mean, I like both. Semicolons + braces is a more flexible approach, but I also appreciate the conciseness of python and how it makes proper code style a part of the development process
If you think whitespace is a bad way of defining a scope try to not ident your code in a language that use brackets and see if what you're saying make any sense 🙃
You're right. Everybody know the best naming convention is lowercase, where all words are simply concatenated without any separators or capitalization.
Amen.
Code is primarily for *humans* to read.
The computer's interpretation of code should always match the human's instinctive interpretation, *not the other way around*. If people use indentation to indicate level, and instinctively evaluate level based on indentation, then the computer should follow that convention. Whitespace should be significant because that's how humans see. Same with line termination -- lines should end at newlines, not semicolons, because that's how the human eye works, and code is for the human eye.
There are bigger considerations to make.
Which one is the right one knowing my cat just walked on the keyboard?
if (foo)
bar();
bar2();
if (foo)
bar();
bar2();
Now try it again with braces.
if (foo)
{
bar();
bar2();
}
if (foo)
{
bar();
bar2()
}
Yeah, I suppose if your program only has two levels of indentation, it's still easy to read without braces, but it sure is useful in the majority of real code
I also have been trying to avoid else statements. I look back at my own legacy code and I cringe.
Then the question in my head goes: "should I spend time rewriting this ugly code that has been working without fail for years or leave it be?"
"colon"ialism.
Pythonists are obsessed with standardizing and requiring something they call "white space" and then have the gall to call *us* the racists! Pure projection (Assuming they've imported numpy).
Its black space on my system because I use dark mode. Checkmate atheists.
I can't be bracist, all of my whitespace is black
well it's more of a navy blue for me so.....
Hey ! Keep your kinks for NSFW subreddit. There are kids around here.
I think that the c/c++/java syntax style stuck around for a reason
If it ain't broke....
Yeah... Now compare real code from real people with many lines and many nested blocks... That would do it.
I'm K&R until my death
Does my nested JS code block with an inline function definition end in )})); or })}); or )})); ?
);
Every method now ends with a sad wink and I cannot unsee it
If you were wise enough to use Lisp, it wouldn't be a problem, it's always )))))
Languages like this also Scheme against curly braces
modern aloof run worthless attraction many dinosaurs squealing swim frighten *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Does my nested Python code block with an inline function definition end in or or ?
At least it's clear where every scope is ending
How is that more clear than just counting the number of indents?
If you install a plugin/extension that colours your brackets, you don't even have to count indents, it will all be colour coordinated.
If you install extension showing the straight lines for indents, it's also clear where the scope ends. I don't understand this whole discussion, both solutions are clear if used correctly
Yeah, you just need to count the colors now. Good luck for colorblind people 👍
I'd rather not have to slap a ruler on my screen to know where nested blocks begin and end.
Personally, I just slap my c\*ck on my screen, like a real sigma indentmaxxed whitespacepilled Python dev.
Code with many nested blocks is unreadable wether there are curly braces or not. Write better code.
3 nested blocks is still a pretty reasonable number or screw that even just 2 and suddenly indentation could be a real fucker cause you accidentally deleted a space and some line executes in a higher closure
I always wonder how people think that would happen. Apart from some very real scenarios like when you’re generating dynamic code (you‘ll need to just get it right here) to be executed or when you‘re running a reformatting tool on your codebase (please make backups and test after reformatting) how concretely would it happen? If you‘re so paranoid about the possibility of some whitespace being dropped how can you be sure a curly brace based scope system is absolutely safe towards these kinds of mistakes?
Well missing a curly bracket is a lot more visible and the ide usually shouts at you about it. An accidental key press before running the code can easily delete a whitespace
... Which makes the IDE shout at you about an indentation error.
Not if the statement is at the end of the indentation block, and refers to nothing local to that scope
Counter = 0 for n in x: //Do some shit Counter++ // if unindented, the value of counter changes and there is no error Print(counter) Excuse the syntax, I'm on mobile
Protip: don't unindent random parts of your code for no reason. This is a problem I've literally never had in like 5 years of python. Do people really just go through their code base unindenting random stuff? Maybe stop that. Now a problem that I have seen (and done) comes from people omitting the brackets for single statement loops/conditionals, because even the people that claim to love them don't really. Then they try to add a second statement, but forget to add the brackets that they need now, so by indentation (what we actually look at, ain't no one counting brackets) it looks right, but it's actually not.
[удалено]
Exactly, how often are you accidentally deleting your code lmfao What happens if I accidentally delete the print statement??
that is why golang requires braces instead of parentheses. instead of ``` if(a) b; ``` go chose ``` if a { b } ```
Yeah, if you're gonna use braces for this sort of thing, that's the way to do it. Which I don't mind, it's not like braces tend to make things much worse (though now python just looks cleaner to me). I'm cool with braces existing if people want them, I'm just amused by people acting like python not having them is some huge hurdle to overcome, as if any one of us actually bothered to look at the braces in decently formatted code anyway.
[удалено]
I‘ll tell you that in two years of developing python I have not once run into that issue. I agree that in the case of curly brackets missing them is less likely because the code won‘t even compile, but the danger is not missing a bracket, but misplacing one. If you work with proper indentation it‘s not the hardest thing in the world to determine whether your else clause belongs outside the third or fourth closing curly brace but it‘s still less intuitive than just checking which line of code is straight above it.
aware oatmeal tidy slap one subsequent automatic degree books unpack *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Modern IDEs take care of this pretty easily
Call functions or go recursive?
It is generally recommended not to nest anything deeper than 3 or 4 levels. If it‘s more complicated than that it get‘s broken down into smaller pieces.
This is part of the solution object oriented languages provide.
class method try puts you at 3 levels before you've even started writing any real code. Sometimes nested code is just unavoidable.
>Write better code. Hahahaha, I was expecting something like that. Let's suppose you or I do :-) What about the others? What about legacy?
Don't accept prs with crappy code. And having dealt with both legacy C code and legacy Python code, then sins I've seen in the C code were much worse, despite it having braces.
Adding to this, if your company has a style guide, enforce it on PRs. If your company doesn't have one, write or adopt one (e.g., google [publishes](https://google.github.io/styleguide/cppguide.html) their style guides) and enforce that. As for the horrors of people not following style guides, the most frustrating one I've ever seen is actually in python. There was a function that was being called. I wanted to know what it did because I was trying to track down a bug and the stack trace went through it. I grep'd the whole code base, but the call site was the only place that it existed. The function wasn't defined **anywhere** in the code base. It took me forever to realize that the author had used metaclasses to define the function (which are banned by our style guide) and it took me even longer to figure out what the function was doing.
> What about the others? They can switch professions to do a job they're actually qualified for, like doorstop or paperweight. > What about legacy? Fix it like other legacy errors?
Damn! All that just because you prefer significant white spaces? Hahahaha. Holy shit. What a fanboy! I thought refactoring was about logic and architecture :-)
>complaining about syntax because your code is shit Pal, if anything you need the python way, you need less nested blocks
as someone who writes both I can say that both can be clear and both can be unreadable shite. this is a developer skill issue, not a problem of the languages.
As someone who does 99% of his coding in either C++ or python, I can attest that you can write unreadable garbage in both.
who woulda thought that IF/ELSIF/ENDIF are the actual braces/colons/brackets/pairs God in COBOL it used to be a PERIOD how anything other than IF/ELSIF/ENDIF are used by the myriad of languages is beyond me What is wrong with an explicit terminator
END SUB END IF END TYPE Actually good. It's very clear what ends where.
And then there's shell scripts with `if` … `fi` and `case` … `esac`.
Yeah and `do` ... `done`
Yeah, that sucks. I understand, but it’s incredibly annoying.
Fortran has this - except you can also just write `end` 🙃
The problem with python is that one cannot use a beautifier to restore indentation.
The problem with Python example is the fact the WHITE SPACE matters. E.g - move the last line one tab to the left, and you just took it out of the 'else' scope. Do the same on languages that mark scope with curly braces - and nothing terrible happens, just a tiny cosmetic issue at worst. White space shouldn't be part of the code, Python disagrees.
> and nothing terrible happens, just a tiny cosmetic issue at worst. Not a mistake, just happy little accidents.
Production fails for 20 minutes; millions dead.
I blame whoever pushed the code without running, whoever wrote the tests for not finding it and QA for somehow letting such a fatal error get to prod
It's always better not to have an incident requiring to put the blame in the first place.
Production has fallen, millions must debug
Using an invisible character as a code instruction (in if or out of if) always felt terrible. At least lint has improved it all, but still very easy to get confused to me.
Lua has left the chat
No brackets, no colons, just simple conditional statements living in the moment.
The only time that this is ever a problem is when you're doing a merge, say, and trying to resolve a change that nested some code. The change in indentation can screw things up. But when I do a merge in c++, sometimes I'll accidentally clobber a brace and get a problem anyway. But odds are that when this happens in c++, the compiler will catch it.
> only time that this is ever a problem is when you're doing a merge Or a refactor. Extract _most but not all_ of a block into a new function, need to un-indent it, oops accidentally un-indented something that was left behind, have a free bug. Like, I don't hate python by any means, but whitespace-based blocks are fragile in ways that explicit blocks aren't. We shouldn't pretend that they aren't.
Which is why Google coding style requires braces always, even for one-liner blocks. I would argue that a one-liner without braces is even more dangerous than the significant whitespace of python.
This isn't true--though I wish it was. [The guide](https://google.github.io/styleguide/cppguide.html#Formatting_Looping_Branching) allows omitting of braces for one-line statements or for statements where the condition fits on one line and the body fits on another: > For historical reasons, we allow one exception to the above rules: the curly braces for the controlled statement or the line breaks inside the curly braces may be omitted if as a result the entire statement appears on either a single line (in which case there is a space between the closing parenthesis and the controlled statement) or on two lines (in which case there is a line break after the closing parenthesis and there are no braces). My company uses the google c++ style guide, but I don't approve things that omit the braces.
I worked at Google and I didn't remember that being allowed. Anyway, fuck that. Apple literally had a major security flaw because of exactly this. https://oscarbonilla.com/2014/02/could-this-recent-apple-bug-be-a-bad-merge/ The two seconds that it takes to put in the braces is well worth the possibility of preventing a bug in security software! Security software should have strict standards! Google style got this one wrong. In my time there, I don't remember reviewing any code that did this.
and when it happens in python your test suite will catch it…
That is if people wrote good tests....
That’s if people wrote tests…
Trying to convince my boss to use typescript or write tests... or documentation is basically impossible.
Making something not compile is better than catching it by testing. This is like saying garbage collection and rust's borrowchecker is worthless because valgrind exists.
If I had a nickel for every codebase with anything resembling decent test coverage (out of the hundreds I've encountered in the wild) I'd have $0.03.
See also: JSON good YAML bad. At least for me. I always mess up YAML.
YAML has far more problems than just being whitespace dependant lol [https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell](https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell)
Ooof. Now I hate it even more.
Anything related to XML is my bane. I absolutely HATE SOAP APIs, please, *please* let me use a REST API!
Beat me to it. Take my updoot.
I don't understand why this is such an issue for people. As if the code base you're working on doesn't have style guides for white space you have to follow anyway. The great thing about the way python does it is that style guides are basically identical across the entire language. Everyone follows PEP8 so you don't have to get used to a different style guide again when you're reading a new code base.
Nah bro, Python is unusable because whitespace can magically appear/disappear in your code and there's nothing we can do to stop it
I've been working in Python for the better part of a decade at this point. Sounds to me like you have a buggy editor or PEBKAC.
I was being sarcastic
>White space shouldn't be part of the code, Python disagrees. You'reright,whitespacehasnoplaceinlanguage,it'scompletelyunnecessary.Idon'tseewhyanybodyshoulduseitanywhere.It'sbesttojustgetridofitall,unlessyouwanttowritepolyglotcodethatalsorunsintheWhitespaceinterpreter.
🙄 Ok Mr Pedantic, let's amend his statement to "different amounts of white space between code should not make the code mean something else"
Okay, but still. How many of us REALLY write code without proper indentation? And if you're going to indent properly anyway, why should you repeat yourself with braces? I am firmly of the opinion that we should be using automatic brace insertion rather than automatic indentation. Both of them use one part of a programmer's input to provide the other, and brace insertion uses the much more visually obvious one as its basis. Python simply does the brace insertion at runtime, fully automatically.
>Okay, but still. How many of us REALLY write code without proper indentation? The problem is not when writing code, it's when modifying code, where it's quick to make mistakes. You want to refactor some stuff, you copy paste, you screwed the indentation, you have a bug. The goto fail from apple was partly because wrong indentation made it look ok. It would not have happened if they used braces.
And yet the goto fail didn't happen in Python, so that can't really be blamed on "significant indentation", can it? It was a failure of process, nothing to do with the language. Maybe if people cared more about indentation and less about braces, they'd notice these sorts of bugs more easily.
>Maybe if people cared more about indentation and less about braces, they'd notice these sorts of bugs more easily. The point is that the bug could go through because the people reviewing it cared more about the indentation than about the braces. If they did, they'd have spotted the bug.
>The point is that the bug could go through because the people reviewing it cared more about the indentation than about the braces. And if there hadn't BEEN braces in the language, the indentation would have defined it, and there would have been no bug. Alternatively, if there'd been automatic brace insertion, it would have followed the indentation, and fixed the bug. The indentation was right and the braces were wrong. This is not an unusual situation.
>And if there hadn't BEEN braces in the language, the indentation would have defined it, and there would have been no bug. Indeed, but as said above, that makes the code more fragile and more prone to bugs during modification and refactoring. >Alternatively, if there'd been automatic brace insertion, it would have followed the indentation, and fixed the bug. > >The indentation was right and the braces were wrong. This is not an unusual situation. It is an unusual situation considering every IDE or even text editor is able to automatically fix the indentation, and many automatically do it on save or after a few seconds of inactivity. Except Apple's apparently... The goto fail is a combination of the bad practice of not using braces for one line blocks and the reliance on indentation by the people reading it. Using braces absolutely define your blocks and make such mistakes nearly impossible.
>Indeed, but as said above, that makes the code more fragile and more prone to bugs during modification and refactoring. Maybe you need better tools? I've never had any issues with that, and I've been working in Python for many, MANY years. Also, in all my non-Python projects, I maintain proper indentation, even during "modification and refactoring". It isn't hard. >Using braces absolutely define your blocks and make such mistakes nearly impossible. Using indentation does, too. There's no fundamental difference here.
Read what you just pasted, problem solved
I shouldn't have to care about how you define proper indentation. I can copy-paste easily when this is done through braces. Otherwise, i am going to need an IDE that does formatting for me. And before you go there, yes, I want to be able to code without an IDE, just a simple text editor if and when needed.
Even with an IDE, the only reason I trust it to add indentation is that it's only there for readability. You can't trust the IDE to chose between if (foo) bar(); bar2(); and if (foo) bar(); bar2();
It just makes it easier. I can simply paste something and use my IDE's formatter to make the indentation look nice, without worrying about aligning everything correctly.
>E.g - move the last line one tab to the left, and you just took it out of the 'else' scope. But why would you do that? Is this a real problem people have, or does it just bother you on animal level that it's possible? I don't even use python often, but I've never accidentally put anything into a wrong scope. I also always properly indent my non-python code because I'm not a monster
You wouldn't do that on purpose, but when copy pasting something or simply getting interrupted while working it can happen. Also, if you have a cat or kids. Using curly braces, it's very unlikely you'd accidentally delete both of them without getting an error. Without curly braces, the code will compile and "work". You better hope the method you inadvertently corrupted is used often enough for you to notice immediately.
No no you don't understand IDE's love adding and deleting whitespace when we're not looking
This is literally what they're doing based on curly braces.
The problem with curly braces example is the fact that the white space DOESN'T MATTER. E.g. you move the last line one tab to the left - but it is still in the 'else' scope, even though it looks like it isn't. Do that on languages that mark scope with indentation - and you moved it out of the scope, just as intended. Sometimes white space should be a part of the code - `int main` is not the same as `intmain`. Curly braces disagree.
The thing is automatic formatting (which you should be using) can easily align everything when you use the curly braces but it can't do that as well when white space matters.
So, automatic formatting cannot solve the problem... because the problem does not exist in the first place? How is that a negative?
No, automatic formatting cannot solve the problem because you are forced to do it manually Curly way: just put braces around the scope and IDE will make it look nice. Python way: you MUST make your code look nice BY HAND
It’s been years since I used an IDE for Python that didn’t auto-indent after lines that are always followed by blocks (for, while, if, try, etc.). Are you saying that if you go through to make changes, the IDE doesn’t automatically update the indents?
Edit: I suspect they are referring to more complicated code changes like pasting in code or deleting a block but not the nested block which would still be at its own indentation
Yep
Gotcha, that makes more sense then
int main vs intmain is being disengenuous. White space at the beginning of a line is the problem. Ending the scope of an if statement with change of spacing is ridiculous. Spacing should be the peeve of the style of the overall program or the editor, not the language used.
How the fuck do you fuck up indentation like that anyways? your IDE will scream at you. Hell even neovim let's me know. If your code looks like shit it shouldn't run thank you very much. Just as you can make arguments about whitespace so too can I reflect them back about missing semicolons or missing braces. Except python simplifies it.
>If your code looks like shit it shouldn't run I take it you've never gotten your code to run then?
Code formatter entered the chat.
If you work in a sane coding environment and you move the last line one tab to the left, you will trigger your linter. So, either you have a valid point and happen to give a bad example, or your point is moot. I sure hope it's the former, so can you give a better example? Edit: for people who keep downvoting me, C/C++ compilers have options that prevent shitty indentations GCC has: *-Wmisleading-indentation (C and C++ only)* >Warn when the indentation of the code does not reflect the block structure. Specifically, a warning is issued for if, else, while, and for clauses with a guarded statement that does not use braces, followed by an unguarded statement with the same indentation.
I've seen people messing up white space during merges. Don't ask me how, but i've seen it, in real life. With Python this wouldn't be just cosmetic.
Again, you won't be able to push to repo/prod if you mess up white spaces when you have a good linter. Or are you saying it's okay for you to push codes like this to production? int squaredError(float x, float y) { float diff = x - y; return diff*diff; // messed up white spaces here } With Python, this error wouldn't be just cosmetic, yes. It'd break test cases. Or if you don't have test cases (red flag here), you'll get incorrect results if you \*\*at least\*\* run your function. In the end, you won't be pushing that code. In the end, the result is the same: can't push shitty code to main repo/production.
You seem to be living in a perfect world, with perfect linter, perfect gating on your repo, 100% coverage by tests, and what's not. In real life thing are far from perfect. Shitty white space remaining shitty white space is better, IMO, than shitty white space also breaking code.
If you work in a sane coding environment with a real language you don’t need a linter.
if you need an entire step in your pipeline to watch for a very predictable kind of flaw, that means you acknowledge the existence of a flaw that you need to compensate for. It doesn't mean the flaw is not actually a flaw anymore. `if (condition)` `do thing a;` `do thing b; // oops wrong scope, but it compiles and looks totally legal` Linter would not magically know which of these two perfectly-valid scopes you intended thing b to happen in. edit - I fail at reddit formatting, thing a is supposed to be indented and thing b is not, but I give up trying to figure out the markdown to make it happen. Totally listen to my advice on languages that are much more complex than markdown though
you adapt, no language syntax is that bad, just is what it is
\*Malbolge enters the chat\*
no, relying on whitespace is bad
Without semicolons, I can't understand any of this;
Worrying about language syntax is such a /r/ProgrammerHumor tier concern.
I write python all day every day but I think they have a point, in that braces and line terminators make parsing less ambiguous. Having also written a bit of C, C++, and C# I can say that not being constrained by indent allows you to reformat code in some really nice clear ways. In the end everything is a trade off. The only hard to read code I see is due to skill issues
This child hasn't discovered nesting yet
I don't use curly braces after if only when there is only one line under it, eg. It's a guard clause with only a return
As a cs dev, I stand with curly bRacism
How do we feel about if condition { do_stuff() do_more_stuff() } else { do_something_else() do_one_last_thing() }
Reminds me of (if condition (block (do-stuff) (do-more-stuff)) (block (do-something-else) (do-one-last-thing))) OMG! The parens! Why can't I have curly braces or colons instead of these terrible parens!? `(((((((((((ugh-this-is-terrible-!)))))))))))`
whitespace should not be a control structure
It is completely subjective and depends on your preference. I think there is nothing wrong with using whitespace as a control structure.
It objectively can mess up your control flow if you mess up the indentation because you moved it from one place to another where it had a different indentation level for example.
Making good indentation isn't harder than the correct use of curly braces. And even if you use curly braces, you shouldn't allow yourself to make bad indentation.
It automatically happens if you move code around, just look at this: https://i.imgur.com/pPLrzki.gif At the beginnig I move a piece of code from one place to another. It is incorrectly indented by default. This curly braced language does not mind, it is still semantically correct. The auto formatter then ensures it is correctly indented as well. A language without curly braces will be semantically incorrect right after moving the code. An auto formatter will not know how to fix the indentation and it will stay semantically incorrect. It of course isn't THAT big of a deal, but it's still a little more error-prone.
That's a valid point. Auto formatting is very useful, but it can't automate writing the code logic. In a similar situation, I pay attention to indentation, which takes more energy.
But it's a lot easier to break.
All of these hypothetical problems that I have never encountered in more than 20 years of programming with Python.
Yes, I love it when my formatter has, in principle, the power to change behaviour.
LOL. The fact that you use a formatter to fix code produced by others (or maybe even you) tells me that you think formatting is important. You are already fighting against your language because it deems formatting irrelevant. I would bet real money that 99% of the people whining about whitespace in python have never actually used the language seriously.
The tabs/spaces thing in python is fucking infuriating if you've got a few different people working on different OSes or just with different styles
PEP8, there are no tabs to indent, 4 spaces always. There's nothing infuriating to be had, there's just the right way and the wrong way. Any of your devs using tabs are doing the wrong thing, and that's the end of it
Hard to say you're doing it wrong considering a python script will execute with tabs as indentation. A style guide shouldn't be a bandage for a poorly implemented system. I don't need to go and specifically turn on whitespace highlighting in my text editor for other languages to ensure my braces are correct and consistent
For python to conflate style with substance and then force everyone to use their personal style like it's some objective truth is (say it with me now!) frustrating.
In company where I work else is just forbidden
In my startup, the only forbidden keyword is fun.
Kotlin devs: oh fuck
What the fuck ?
if (condition): stuff() if not (condition): other_stuff() Easy fix for the dumbest problem ever
Except then the condition gets evaluated twice, which can cause some hilarious bugs (and more mundane stuff like more compute time and extra log messages and stuff) if any part of it is a function or if you're doing microcontroller stuff and a variable's volatile.
Suppose we have this code: if condition: if condition2: if condition3: if condition4: if condition5: function() function() function() function() function() I find the C-Style equivalent way more readable: if (condition) { if (condition2) { if (condition3) { if (condition4) { if (condition5) { function(); } function(); } function(); } function(); } function(); }
My son, in _both_ cases it's time to rethink the choices that have lead you down this path of sin
Of course!
A switch case would be more readable if you're going to do 5 nested statements. Switch cases were added only recently in python however
Vs code has line guides for indentation. Clean and easy to read for your example. With that showing what’s what, extra curly braces and line spaces only make it less readable, however with a colored bracket extension, maybe it’s a wash.
I get it, we need braces to make shitty code slightly more readable.
As a python user, I urge you to use JS…
how is that more readable? it just makes longer code with the same readability. it being longer imo makes it less readable...
So Python ~~prevents~~ deters you from doing bad code. Imo, that's a good thing.
No? It just makes the bad code worse.
Where the heck is the endif? Semantic spaces need to die a hard death.
Where are the semicolons. How can anybody even read this!
If only people could write code like this into one-task functions with explaining name I would be so happy.
Not fine, You forgot the semicolons from the end of the function calls
The real clowns are the languages that went with elif/elseif (ElseIf Expression) instead of else + if (Else expression with “If” expression body) Lots of curly bois and lots of tabby bois have made this rookie mistake!
We have a WHITESPACE Supremacist here
I mean, I like both. Semicolons + braces is a more flexible approach, but I also appreciate the conciseness of python and how it makes proper code style a part of the development process
Why is "racism" a boolean
If you think whitespace is a bad way of defining a scope try to not ident your code in a language that use brackets and see if what you're saying make any sense 🙃
them damn python users are wanting their “*white* space” in their code!! Racism!! Our braces are inclusive of everything in them!
These days I only react to bracketing when 2 files of the same language, in the same project, are bracketed differently.
The only way to do it is `if .. then .. end` :)
I raise you an IF ... THEN ... ELSE ... END IF
Why not if .. then .. else .. fi ?
A good variant.
The first one is truly monstrous because the brackets and the "else" should all be on separate lines
Honestly I'm fine with colons. I'm less okay with snake\_case.
Depends on the language. this_looks_odd_in_jave thisLooksOddInC
You're right. Everybody know the best naming convention is lowercase, where all words are simply concatenated without any separators or capitalization.
ok, let me just apply that to my favourite variables, kids_exchange and pen_island.
Amen. Code is primarily for *humans* to read. The computer's interpretation of code should always match the human's instinctive interpretation, *not the other way around*. If people use indentation to indicate level, and instinctively evaluate level based on indentation, then the computer should follow that convention. Whitespace should be significant because that's how humans see. Same with line termination -- lines should end at newlines, not semicolons, because that's how the human eye works, and code is for the human eye.
There are bigger considerations to make. Which one is the right one knowing my cat just walked on the keyboard? if (foo) bar(); bar2(); if (foo) bar(); bar2(); Now try it again with braces. if (foo) { bar(); bar2(); } if (foo) { bar(); bar2() }
Yeah, I suppose if your program only has two levels of indentation, it's still easy to read without braces, but it sure is useful in the majority of real code
True, but the curly bracket in front of the else is gross. Put the else on a new line
you have that backwards.
Both choices are wrong. Curly braces should be on their own lines with nothing else Because that's my preference
I don't like else statement at all I avoid them all the time
Just like me with my responsibilities.
I also have been trying to avoid else statements. I look back at my own legacy code and I cringe. Then the question in my head goes: "should I spend time rewriting this ugly code that has been working without fail for years or leave it be?"
[удалено]
Yes, they do. Google "Python programming language"
Missed the colon. RIP.
Most racists code is: var blackguy = new BlackGuy(); while (blackguy.Energy > 0) { blackguy.ConsumeCotton(); } delete blackguy;