Hacker News Reader

Comment by ssivark | Hacker News Reader

It really doesn’t matter.

We must strive to separate content and presentation, so people could choose whatever presentation they like (and have the editor do the wrapping as desired), for whatever whimsical reason that is nobody else’s business. It’s crazy to keep having this discussion and debating what the “research” indicates.

C’mon, haven’t we made any progress in forty years!? Everybody can have their own damn bikeshed, and paint it a different color every day.

Personally, I like to see more things happening in one screenful, so artificially imposed line breaks are really really annoying and break momentum when reading/scanning code.

View on HN

This. The problem itself has nothing to do with the number of characters you have on a line - the problem is that the vast majority of programming tools today conflate content and presentation.

The job of making sure the line length is reasonable is not up to the writer of the code - it is up to the tools that are used to read it. Lines should be as long as necessary, and then intelligently (i.e. syntactically-aware) soft line-wrapped by the editor when opened.

> the problem is that the vast majority of programming tools today conflate content and presentation.

This is not a problem, but a beautiful and crucial property of text files. I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

With that in mind, you are free to reformat the file to your tastes on checkout and do it with repo-compliant standards on commit.

If I did work for Google, with their heinous 2-space tabs, I'd certainly do that all the time.

> I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

Adjustable tab display width and automatic line wrapping are features any good text editor offers that do not interfere with the use of any other text manipulation tools on that file.

Now, if you're forced to work in an environment where someone wrongheadedly decided to adapt to users who have bad or badly configured editors and standardized on space indentation that sucks, but that's the fault of whoever made that bad decision.

I try to keep my Clojure code under 80 characters (so that I can have three editors comfortably side by side at my preferred font size) and keeping lines short is more than just where to wrap or other visual-only things. Usually when I have a long line, it makes me reconsider the structure of the code and I refactor it into something else. Most of the time, the new structure not only has shorter lines, but is simpler too, so its a double win. This isn’t always a task that the tools could do for mem, though, as it sometimes rewuires rethinking what I’m trying to accomplish.

Ah so you're "tabs" haha

100% the reason I'm a tab guy.

If I'm glancing at some code on my phone, I can have it set to two space tabs to maximize the amount that fits on screen. If I'm on my desktop they're four spaces because my screen is huge and more visibly apparent indentation is valuable. Same editor, same data. If it's a shared codebase and someone else likes 8 space tabs, 6 space, or whatever they want (13 space? no kinkshaming here...).

To me that is a significant objective advantage of tabs, where the only advantage spaces seem to offer is that you can align text on multiple levels of indentation.

Yep. I have yet to hear a coherent argument against tabs.

It’s such a tiresome squabble.

Douglas Crockford made an interesting argument in favour of spaces: https://www.youtube.com/watch?v=En8Ubs2k1O8

Vertical alignment of related lines.

If you indent with tabs, you can still align with spaces for vertical alignment.

That’s the whole point of tabs. How is this an argument against them?

Because it doesn't work with tabs, someone else will have a different tab-width.

Reply on news.ycombinator.com