Honestly, this looks more readable than Python. Noticing whether something is 3 or 4 levels less indented than something else is really really hard. Noticing whether there are 3 or 4 braces is easy.
1) that looks incredibly cluttered (yes, even compared to braces), and 2) it doesn't help a whole lot when reading code in any context what so ever which is outside of my preferred editor (including in github/gitlab merge requests or 'git diff' locally)
For me, what is visual clutter is all about what I'm used to. After a short period of adaptation, I found indentation guides disappeared when I was looking for them. You can also choose your styling. As I mentioned above, that was an extreme example. Here's a style that adds very little clutter (mine look a lot like this): https://i.sstatic.net/nxPrP.png
Also in the spirit of modern tooling, VSCode has had the ability to navigate GitHub Pull Requests, with all the normal code editing tooling, since 2018. I'd be surprised if it's alone in that ability in 2024. The same is possible with Gitlab Merge Requests using Gitlab's own extension. I can also use VSCode to remotely edit on almost any Linux/Mac/Windows machine that I can ssh into, or inside Docker containers.
Indentation guides have been a thing in editors for about thirty? years. Geany supports them for example. Turn them on and never mistake a level again.
I also turn on visible whitespace but make the color very subtle in the syntax highlighting section. Makes inconsistencies jump off the screen. Other little features like deleting trailing whitespace are your friend.
Ignoring the tone of the other poster, the point they are making is that there is no clear value for indentation markers in a (unified) diff view, which is based around lines being removed and added.
Similarly, you might not even see braces for the corresponding block, so the braces-vs-spaces is not really a win for "braces".
However, I am guessing you are mostly using side-by-side diff view (as opposed to unified diff view), which might have some value to indicate indentation change for a bigger chunk of the code. But again, if you are not seeing where the block starts or ends with braces in the diff block, why is whitespace in any way "worse"?
> Everything outside of notepad already supports it—that was the point, dumbass.
As a response to me pointing out that it's not supported in the GitHub diff view. That response is nonsensical unless you meant to say that it's supported in the GitHub diff view.
No one is using block markers or indentation guides in a diff view because that doesn’t make sense. The two+ views would conflict with each other, so vast majority of such tools don’t even try to understand blocks. (difftastic however, on the terminal tries.)
If a diff is particularly complex (it shouldn’t but assuming) you’ll need to look at the destination in full and confirm tests etc have passed.
> Everything outside of notepad already supports it—that was the point, dumbass.
As a response to me pointing out that it's not supported in the GitHub diff view. That response is nonsensical unless you meant to say that it's supported in the GitHub diff view
> Everything outside of notepad already supports it—that was the point, dumbass.
As a response to me pointing out that it's not supported in the GitHub diff view. That response is nonsensical unless you meant to say that it's supported in the GitHub diff view
To reformat your code for you. Quick two strokes should do it. I use Jetbrains and it’s select all -> alt ctrl L I think. Massive timesaver. Anything a computer can do to help coders good IDEs can do in the blink of an eye.
How much Python have you ever written or reviewed? With only a bit of experience, I am sure you'd have no trouble doing that if the Python code is not using 2-space indentation.
It certainly becomes a problem if you are looking at a 100+ line method/function, but with Python being as expressive as it is, a 100+ line method/function is a problem unto itself.
Otherwise, I've never had any issues with it — even with languages other than Python, I mostly rely on white space and alignment to understand the block boundaries, only resorting to reviewing the braces carefully when something is amiss.
I hope you don't have to do that very often. Occasionally, sure, but a lot of functions that have an indentation drop of 3 or 4 levels would be better refactored.
I'll remember to tell that to everybody whose code I could ever have to read in the future but I don't think it'll have much effect, we're talking at thousands of people I'm guessing and I don't know most of them
