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