Hacker News Reader

>Yes, for prose. And no one actually said easier, they said faster. Code is typically full of parenthesis special notations and characters. Nobody's speed-reading code. That doesn't make sense.

Because code is harder to read that prose I think that favoring short lines is better. It forces you into breaking your code in more digestible bits rather than a 500 char single-line monster statement. Honestly it's very similar to the argument against very deep indentation (forcing you to break your code in subfunctions) so I wonder why you feel differently about this.

>Marginally. Most code is pretty succinct anyway and you can easily compare it side to side. In real life, this is almost never a problem.

I don't understand what you mean. Succinct how? If you have only ever encountered succinctly written code I envy you.

And it's not just about comparison, I generally have two or three different code listings side-by-side, or maybe some code on one side and a manpage on the other for instance.

>> It encourages shorter names

>Arguably an anti-patern.

Agreed. Sure you shouldn't go overboard java-style but very explicit names are never a bad idea. That being said even a very long symbol will seldom exceed 30 chars in my experience, so it's not really an argument against 80 columns either.

We all agree on indentation.

>> Enforced by a tool

> The root of all evil. A tool for stripping away context and making hackily written code under pressue and time limitations and carefully planned out code look the same to the naked eye.

Now that I 100% disagree with. If your code is supposed to be a quick hack and a placeholder then add a comment saying that, relying on subtle formatting cues to judge the quality of some code seems very fragile.

Tool-enforced coding style is good. It saves puppies. It makes waterfalls taller. It makes the air taste sweet. And more importantly it means no more bickering and bikeshedding about coding style.

Uniform code will always be more readable than a codebase where everyone has their own idiolect.

I often find myself working with Fortran, you know, back when punch cards only had 80 columns.

Let me tell you my friend, nothing about it is "more readable". In fact, you are likely to find lots of dirty tricks to make the code fit om cards which ends up obfuscating things.

> >Yes, for prose. And no one actually said easier, they said faster. Code is typically full of parenthesis special notations and characters. Nobody's speed-reading code. That doesn't make sense.

> Because code is harder to read that prose I think that favoring short lines is better. It forces you into breaking your code in more digestible bits rather than a 500 char single-line monster statement. Honestly it's very similar to the argument against very deep indentation (forcing you to break your code in subfunctions) so I wonder why you feel differently about this.

That's the thing. It forces a limitation on me that's not designed for making code more legible. Look at this example from the curl project: https://imgur.com/gallery/yialLe7

Making the code legible has nothing to do with the number of chars. It's about the effort. The 80 chars limit is not helping.

> >Marginally. Most code is pretty succinct anyway and you can easily compare it side to side. In real life, this is almost never a problem.

> I don't understand what you mean. Succinct how? If you have only ever encountered succinctly written code I envy you.

I do end up re-writing a lot of code =). But I'm not shy about fixing it where I see it. Legibility and skimability are the two major driving forces.

But comparing once method to another in code and implementing algorithms is almost never a problem on a big screen. I find that it's very seldom something interesting happens on the far end of 150 characters. That's usually debug output or some line I'm not gonna be interested in any way. I'd much rather fit an entire class in one view than having 2/3 of my screen empty as I scroll up and down.

Particularly with something like rust_fmt. shivers

>>> Enforced by a tool

>> The root of all evil. A tool for stripping away context and making hackily written code under pressue and time limitations and carefully planned out code look the same to the naked eye.

> Now that I 100% disagree with. If your code is supposed to be a quick hack and a placeholder then add a comment saying that, relying on subtle formatting cues to judge the quality of some code seems very fragile.

See the image above and find me a formatter that will let me keep that thing legible.

I'm not against formatters or formatting. I'm against the rust_fmt way. You're cover up the signal with a bunch of whitespace vertical noise.

Code comments are also an anti-pattern in my mind. If you need to put comments in your code, you aren't done yet. Use a method and make it describe what it's doing. Comments are an absolute last resort.

> Tool-enforced coding style is good. It saves puppies. It makes waterfalls taller. It makes the air taste sweet. And more importantly it means no more bickering and bikeshedding about coding style.

Huh. I've been wondering what all these puppies were about.

> Uniform code will always be more readable than a codebase where everyone has their own idiolect.

I find it wont. Not really. It'll just disguise all code to look the same and force you to actually read code to figure out what's going on rather than just skimming it.

Besides, healthy discussion within a team are a good thing. We might come around to each other opinion. Something extraordinary maybe makes sense for us. The conformist view of one size fits all is .. just wrong. imho.

> It forces you into breaking your code in more digestible bits rather than a 500 char single-line monster statement. Honestly it's very similar to the argument against very deep indentation (forcing you to break your code in subfunctions) so I wonder why you feel differently about this.

Breaking code into digestible bits is only a solution when you can use it. I believe it is good if you take it as a guideline not as a rule.

Having extensively programmed in SQL, I've had to deal with monstruous pieces if code. And sometimes there is no way to refactor them. Sometimes because of quirky performance, sometimes because of legacy, sometimes because higher-ups decide to incur tech debt. Views, functions, CTEs and temporary tables help but are no panacea.

In SQL, you can quite easily enforce a line length limmit (though you might want to break it at times for table style readability) but enforcing a line count limmit is unphesable.

I imagine enforcing a line length limmit on a language with line breaks as instruction separators to be a cripling rule. Yes, you can store things in variables, you can split code into functions, and all of these might help readability but they might also hinder readability.

Anytime you work with things resembling wide two dimensional arrays (arrays, consecutive assignments of functions with the same signature, members of a structure, etc.), linebreaks in any other place other than between rows of the array are a hindrance to readability. You can break the line at predetermined points (e.g.: after the fifth, ninth and twelveth parameter for a particular function) and if there is code between the "rows" or if you need comments this approach is preferable. But if the "rows" are consecutive and there is nothing to explain in comments and the languages does not allow you to colapse "columns" and you need to do this often enough, then enforcing a line length limmit is harmful to readability.

Rather than blindly following a rule like 80 char limmit, I prefer to try to stick to the prefferd conventions of each language. If there are none appliable, find what works for the project. Line length limmit is helpful, but not paramount.

>Yes, for prose. And no one actually said easier, they said faster. Code is typically full of parenthesis special notations and characters. Nobody's speed-reading code. That doesn't make sense.

You speed read code all the time - when working on a codebase you can pinpoint the exact segment of a line you're interested without even parsing the whole line. For example if you're trying to modify an argument that's being passed from parent scope - you navigate there and just go to the argument on the caller - you don't read the previous arguments or call definition, you don't read surrounding lines, etc. you just know where you are and what you want to change.

Having a limit on width is very useful - but 80 is too constraining because of indentation and using descriptive names (assuming you don't obfuscate your function names, like you said an anti-pattern).

I personally like 120 characters :

- beyond that and the editor takes up too much horizontal space and my eyes need to jump too far from line start to end, I've worked on a ruby project that had unconstrained line length and it was a nightmare even after a year spent on the project

- below that I have to break too many lines that shouldn't really be broken, worked on a project in JavaScript that had 80 character limit as well a long time ago and it was a complete mess, it directly impacts the way you organise code and not in a good way IMO

> Nobody's speed-reading code. That doesn't make sense.

Well, I speed-read code all the time.. it's a necessity in my role as independent consultant. Clients have a lot of half-baked/unfinished projects, and I'm called in to get it progressing. Speed-reading enables me to assess the state of the existing code and suggest a way to move forward, without breaking the bank up front.

That said, for me column width is irrelevant for speed-reading. The typical time-killer is lacking separation of concerns and poor naming conventions (God classes, or worse, God files with 20 classes)

>Well, I speed-read code all the time...

I skim code a lot. like A LOT. But I don't _read_ it. I try and figure out where I am by looking at context and clues and only drill down into the important looking tricky buts. It kinda sounds like we're on the same page here

> That said, for me column width is irrelevant for speed-reading. The typical time-killer is lacking separation of concerns and poor naming conventions (God classes, or worse, God files with 20 classes)

Exactly. Couldn't have said it better