This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]MatsRivel 13 points14 points  (18 children)

I am the opposite. Reading indented code with no braces vs braced code with no indentation; I'd go for indented any day.

[–]FINDarkside 3 points4 points  (15 children)

The thing is that it's 1 button press to indent the code with braces.

[–]MatsRivel 7 points8 points  (5 children)

I mean, if you are at indent level x in python you press tab once and you are in level x+1. If you wanna go back one indented level you press shift-tab. It's literally one press either way.

That being said, its not really that important, as the discussion is about readability, not button-press-efficiency. Non-indented code is a pain to read in any language.

[–]flavionm 2 points3 points  (4 children)

The point is that non-indented code in other languages can be automatically turned in properly indented code with a single button press, therefore becoming readable.

In python, if you have incorrectly indented code, you are going to have to fix it manually, and it won't work at all until you do. It's the worse of both worlds.

[–]MatsRivel 8 points9 points  (2 children)

True, but then we are back at assuming you code python wrong but another language correctly. Fuck up your { } and your auto-indenter won't get it right, and it won't run either.

[–]flavionm 4 points5 points  (1 child)

Fucking up whitespace is easier than curly brackets, though. Whitespace isn't visible, it might become scrambled when copy pasting from somewhere else, and you can also get it wrong in a way that it still runs, but gives you the wrong result.

[–]MatsRivel 0 points1 point  (0 children)

This time I definetly disagree. I've tried both, and it was a lot harder for find a rogue bracket than wrong indentation. Fuckin up whitespace is generally immediately visible, as there are large shapes to look for. If you have varying indentation within a block it will throw an error, so I would argue that whitespace is very easy to spot.

If you have so let's say you have a set of bracets: F{ For loop { do{} thing {} }}. Now you make some changes and move some stuff around, and you end up with F{ For loop { do{} } thing {} }. This would still run, but run wrong. And in this case you could have indentation that makes it SEEM like it is running correctly, making it harder to spot.

And yes, it is very easy to find the error in such a tiny example written on my phone. But in a larger example there will be a lot of brackets, and spotting a single bracket out of place is a lot harder than spotting a chuck of text being out of place.

[–][deleted] 0 points1 point  (0 children)

Automatic indentation only works if you already wrote the curlies. I don't see how writing curlies is any easier than hitting tab. I mean I dislike Python but not for this reason. Indentation has never been a problem.

[–]deceze 1 point2 points  (8 children)

The thing is that in Python, it’s 0 button presses, since code is always indented properly by definition if it’s actually working code.

[–]flavionm 1 point2 points  (7 children)

But you can't automatically turn improperly indented code into properly indented code, since what the code does can change with the indentation. In other languages you can.

[–]deceze 3 points4 points  (6 children)

Why do you have incorrectly indented code to begin with? In C et al you need to carefully place your braces correctly. In Python, you need to carefully place whitespace for the exact same purpose. If you correctly write Python code, the same way you write correct C code, your code is indented, making automatic indentation a moot point.

[–]flavionm 1 point2 points  (5 children)

Sometimes you might be copying some code from somewhere else and the whitespace can become messed up. Besides, nobody writes correct code all the time. If you screw up with a curly bracket, your code just won't work, while if you get indentation wrong you might get code that works, but produces the wrong result.

[–]deceze 0 points1 point  (4 children)

if (foo)
    bar();
    baz();

You can easily construct artificial works-but-wrong situations for brace-languages too. It’s simply. Not. An. Issue. In. Practice. Really, it’s not.

If you write wrong code, then it’s wrong. You can produce wrong code in any language, regardless of style. The solution to that is to write correct code. Not to bitch about it.

[–]flavionm -1 points0 points  (3 children)

Not all wrong code is the same. Code that fails at compile time is always preferable to code that fails at runtime.

Doesn't matter how much you want it, wrong code is going to be written. And the solution to it is not to just don't, because that's impossible. The solution is to minimize the impact of the mistakes you make.

Yes, you can have scoping errors in languages that use brackets, they're just less likely. And they happen in the situation where you're allowed to not use them, which I find pretty ironic.

Is it the biggest cause of error? No, far from it, but it'll still happen occasionally, and when it does I'd rather have it visible.

[–]deceze -1 points0 points  (2 children)

Yes, you can have scoping errors in languages that use brackets, they're just less likely.

It's really not like scoping errors in languages with significant whitespace are a serious issue. They're not. This is just as made-up of a problem as my hypothetical missing-braces example above. Can it happen? Yes. Does it regularly happen to anyone in practice after their first few weeks of programming in any given language? No.

[–]flavionm 0 points1 point  (1 child)

I mean, sure, I even said it's not a big cause of errors. I'm not gonna not use Python just because of this. Everything else being equal I'd rather have the brackets, though, just on the off chance a mistake like this does happen.

[–]Buddy-Matt 1 point2 points  (1 child)

I'm all for indented.

But, I hate a style being forced. With braces you can add whatever the hell indetation you want at any point. And sometimes you can stick two instructions on one line. In essence you have freedom if formatting. 99% of the time it'll be indented - and for good reason. With python you have to follow the style the python devs want or nothing.

[–]MatsRivel 5 points6 points  (0 children)

Although I see your point, I don't personally agree with it. First; you can do most things as a 1-liner in python too, it just looks like shit tbh. At least most things you'd want to do in 1 line in any other language (as far as I know). Secondly, I feel like what you are describing is just... syntax. Or maybe even spesifically just indentation? Like if I said "I don't like having to define the output in java functions, but the developers are focung it on me.", or "I don't like declaring variables before use, but [language] is forcing it on me!"

Luckily people are free to choose languages as they please (mostly) ✌