| > >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. |