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)
> >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.
First of all let me start by saying that all my lash language is tongue-in-cheek. If you need a visual, you can imagine me poking you in the ribs at the bar and having a laugh. I have nothing but respect for Daniel and his work.
That said:
* Narrower is easier to read
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.
* Side-by-side works better
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.
* Better diffs
Don't conform your code to fit your tools. Use tools that fit your code. There's plenty of good diffing tools and git clients and editor plugins that make this a breeze.
* It encourages shorter names
Arguably an anti-patern.
> I know especially Java people object to this as they’re trained in a different culture and say that a method name should rather include a lot of details of the functionality “to help the user”, but to me that’s a weak argument as all non-trivial functions will have more functionality than what can be expressed in the name and thus the user needs to know how the function works anyway.
You shouldn't have to read a lot of code to understand it and locate problems and botlenecks. If your code requires grokking and keeping vast amounts of methods in your head you're wasting valuable cognitive load
* Just a few spaces per indent level
ok, so I like this. =)
* Many indent levels is wrong anyway
Absolutely. Make methods and give them proper names. Go Daniel!
* Why exactly 80?
.. technically not a part of the argument, but I'm glad it's here. 80, 100, 120, 160, 200? It doesn't matter. Either full freedom to express myself to the best of my abilities or it doesn't matter.
* 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.
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