Hacker News Reader

Comment by npsimons | Hacker News Reader

I closed the tab at the "Line Length" header; yet another person who Doesn't Get It, and proudly refuses to. There's a reason besides technical limitations (which in reality, didn't exist) that columns are best set to be no longer than 80 characters. Just as a hint, would you like to dump all your code into a single function in one file? No? Didn't think so.

Edit: I lied, I kept reading. Oh, why did I do that. Tabs instead of spaces because it looks better on his iOS devices? This article is bad, and the author should feel bad.

View on HN

Maybe I`m biased because I write C on a daily basis, and only noodle around with Python occasionally:

- Having a standard line length is awesome. I can fit 3 80x4 terminals on my 1920x1080 screen, and I never have worry about anything overflowing or wrapping. You could pick a different length, if you`d like, but 80 is convenient.

- I`ve seen the `you can set tabs to whatever you want` argument before. It`s obviously at odds with the 80-column rule, because if you open it with the wrong config, wrapping everywhere. This happens disproportionately to new users - new hires and interns - and it`s a big pain to explain every time. Then they turn around and hit space 4 times anyways.

Your code style rules should definitely match your language. The author seems to be complaining that C-style rules don`t apply to Python. You`d think he would`ve realized when they started talking about wrapping if blocks in {}

Not trying to start a flame war, but I am on the tabs side of the discussion. Most companies have rules about tabs/spaces (we use spaces, much to my chagrin), and it's pretty easy to set a rule.

I code in Go a lot now, and Go ships with gofmt, which formats your code for you (uses tabs by default). There are similar tools for every language I've used. This can be set in a pre-commit hook (or whatever the terminology is for non-git scms), so it's not really an issue. We do this, and it works like a champ.

Automation is a very nice thing. We, too, use Git hooks to run a wide array of checks and cleanup routines. The base that we use is from my hooks collection: https://github.com/amcgregor/snippits/blob/hooks/pre-commit-...

If your developers are pressing space four times instead of the tab (key), and the editors aren't capable of reasonable wrapping policies, you should probably replace either the editors they are using… or them. The key point of my article is that we have software to do all of this stuff for us. Hitting three more keys than necessary to indent is the fast road to carpel-tunnel and surely not the best use of developer time.

Oh, forgot to mention: you can embed in source files editor instructions (between -*- for emacs, something I can't remember for vim) that specify a default presentation format.

Tabs not simply because it "looks better", but because it offers me the choice. Unfortunately, like most arguments on this subject, you have brought no logical counter-arguments to the table… just personal attacks (I never feel bad ;) and a false dichotomy of collapsing large codebases into a single file. That is, I'm sorry to say, not a very good argument.

I do regret the ad hom, and I don't have time right now for a proper rebuttal with links to far better programmers than I who have come down on the side of spaces and no lines longer than column 80, but I'll give you this: your basic premise (the one on the end of the title and the article) are true, and is a point I fully emphasize with. To be honest, I don't really care too much what formatting is used (and I can configure my editor of choice for anything you can think of, natch), but I insist that it be consistent.

Unfortunately, we don't all get to choose who we work with or that they use a decent editor, and either one or the other are usually lacking, therefore: no tabs, only spaces. Also, if you have a line of code longer than 80 characters, consider that that's an indication that it's too complex, and not so much that it's breaking some arbitrary line length rule. Does a function really need more than three arguments? Why not put them each on a line for better readability? Do you really need to put 15 operations on one line, when the compiler can inline them for you, and you can give more meaningful names to constant temporary variables?

As for putting all code in one function (or even one file), I thought it was fairly obvious: you can make things hard to read by using too long a line of code, just as you can make things hard to read by dumping them all in one unbroken file (line after line with no reuse and no compartmentalization of functionality).

My main display + editor, I use in two modes, 273 columns wide, or up to 410, both of which I feel comfortable with.

I'm guilty! I'll admit, When I know it's my-eyes-only, in languages with functional features, I tend to just brain-dump one liners if I 'see' them in my mind as one sequence of operations. It's easier for me to write, and much easier to read and parse later than multi line equivalent.

But I l also know that outside of private junk, this sort of thing is usually inappropriate, and downright harmful on teams with varying skillsets, where these lines can be impenetrable to some team members, and make the codebase far more intimidating than it needs to be. I segment and format anything above ~80 if anyone else is going to be involved.

So coming from someone who would violate almost any line length rule if no one was looking: I feel like a line length is appropriate in a style guide, or at the bare minimum a consensus on how much is too much.

Same here.

80 columns-wide have another huge advantage: 3-ways merge fitting on one screen.

Even with "only" 100 columns wide it's hard to do a three-ways merge side-by-side without wrapping on a 1920x1200 screen (I basically have to temporarily use a smaller font to be able to do my three-ways merge).

I often use splits on my editors, and with 329 columns in my editor (with side-bar open) there is plenty of room. Fairly recently I was working with five simultaneous vertical splits and had no difficulty; my editor soft wrapped the few panes I wanted wrapped quite smoothly and without making the code any uglier or harder to read. While I do not agree with hard wrapping, in general, I still try to avoid run-on lines in my code, and in Python a newline is a statement separator so it's actually pretty hard to have run-on statements. (Literal definitions like lists and dictionaries can run-on, but I tend to hard wrap for SCM reasons.)

Reply on news.ycombinator.com