Live data from Hacker News

Tabs or spaces – Parsing a 1B files among 14 programming languages

medium.com

121–124 of 124 posts

Re: Tabs or spaces – Parsing a 1B files among 14 programming languages

#121
post #118

Earlier quoted context omitted.

Personally, I don't find the value in alignment - indentation is all I do. I especially dislike alignment of this sort: var a_variable = 1; var another_variable = 2; var yet_another_variable = 3; which is just too fiddlesome and in fact makes it _harder_ for me to read.

There's different kind of alignment, the one you get from breaking too long line. // some code // ... var some_call_result = some_object.a_method(with, quite_long, list_of, parameters) In the second line you get indent (up to `var' keyword level), and then alignment. The former would be fine with tabs, but the latter must be spaces. Unfortunately there's no editor that deals with tabs in this situation correctly , wh…

While I see what you're getting at, I actually prefer indentation in this case as well. Something like:

    var some_call_result = some_object.a_method(
        with, 
        quite_long, 
        list_of,
        parameters
    )
Alignment adds inconsistent negative space to the code which I find breaks the flow and makes it hard to read because lines start at arbitrary columns. If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.

Re: Tabs or spaces – Parsing a 1B files among 14 programming languages

#122
post #118

Earlier quoted context omitted.

There's different kind of alignment, the one you get from breaking too long line. // some code // ... var some_call_result = some_object.a_method(with, quite_long, list_of, parameters) In the second line you get indent (up to `var' keyword level), and then alignment. The former would be fine with tabs, but the latter must be spaces. Unfortunately there's no editor that deals with tabs in this situation correctly , wh…

While I see what you're getting at, I actually prefer indentation in this case as well. Something like: var some_call_result = some_object.a_method( with, quite_long, list_of, parameters ) Alignment adds inconsistent negative space to the code which I find breaks the flow and makes it hard to read because lines start at arbitrary columns. If your method name grows or shrinks, the alignment in your example needs to be…

What you presented indeed has no alignment spaces, so all-tabs approach works.

The thing is, there are codebases that use "my" line breaking, and with no editor that handles that case correctly, tabs are just no-go.

> If your method name grows or shrinks, the alignment in your example needs to be fixed whereas with simple indentation there's no such need.

I gladly accept this drawback, for the sake of situations when a linebreak is necessary, but the argument list is just too short to be split it into separate lines like in your example. (The necessity is a matter of taste, obviously.)

I admit, these situations are rare, but they happen from time to time, so I simply don't use tabs.

Re: Tabs or spaces – Parsing a 1B files among 14 programming languages

#123
post #31

Earlier quoted context omitted.

With spaces you can position the cursor anywhere you want, with tabs you can not position the cursor in the middle of a tab.

Why would you want to do that? In fact, isn't it much more convenient to be able to jump over one tab with a single keystroke, rather than 2, 4 or 8?

If you use the mouse then you want the cursor to appear exactly where you clicked. It's just a UX problem, similar with clicking past the last line of a file, even if it's nothing there, the editor should append new lines until the place that you clicked becomes part of the file.

Re: Tabs or spaces – Parsing a 1B files among 14 programming languages

#124

Earlier quoted context omitted.

But if anyone looks at a diff, it looks like all the lines have changed, instead of just one, taking just a tiny bit more cognitive overhead.

`git diff -w`

But `git blame` still sees the whitespace change, right?

Edit: turns out `git blame -w` works as expected, ignoring whitespace. The More You Know™

Post reply on HN