4 ms·
“how much of it fits in one page” matters. This doesn’t mean that cramming everything into tight subsequent paragraphs, like a serious book, is a good idea: cod
by hoosieree 3y ago
“how much of it fits in one page” matters. This doesn’t mean that cramming everything into tight subsequent paragraphs, like a serious book, is a good idea: code isn’t supposed to be primarily read paragraph-by-paragraph. On the other hand, a two-words-per-line, twenty-words-per-page nursery rhyme-like layout means that one might need to scroll through dozens of pages to get “what’s this all about.”
I disagree that code is "supposed to" be any particular way, but in general I agree with this point. And I think it's gradually being forgotten. Automatic code formatters and mandatory style guides are becoming more common, and while they do raise the floor (by preventing some interpretation of "bad" style) they also lower the ceiling. Uniformity isn't bad, but sometimes you really need certain things
to
stand
OUT!
- mhink 3y agoThis is my biggest gripe with the widespread use of Prettier over in JS/TS land, especially when using React. It always seems to introduce *more* formatting inconsistency because it's only looking at line length to decide when to format. So in the same block of code I'll have things like: const foo = useMemo(() => { // code }, [ alfa, bravo, charlie, ]); const bar = useMemo(() => { // code }, [delta, echo]); const quux = useCallback( (arg0: string, arg1: number): SomeType => { // code }, [foxtrot, golf, hotel] ); Which is infurating because it's not visually consistent so the code starts to look like syntactic soup. It's the same thing with components, really.
- kevincox 3y agoThis is also my main gripe with automatic formatting. Since they don't really understand the code they almost all work based on number of characters in a line. However I really don't care about characters in a line (except for at the extremes). What is much more important is how many ideas are in the line. If I have an array with 3 very interesting elements I don't want them on the same line even if they happen to be quite short.
- JohnFen 3y agoGood formatters do understand the code, though. They parse it much like a compiler does.
- larschdk 3y agoI tried your code on prettier.io and got a result that was more visually consistent than what you pasted here.
- oprypin 3y agoI think the commenter meant that it can produce such an inconsistent result if the identifier names add up to approximately the line length, but the example didn't actually make it so; the identifiers are much shorter than that.
- vidarh 3y agoPrettier always makes me want to rage-quit. Thankfully I'm at a career level where I usually have the power to dictate it be removed. A formatter that does not understand or allow for careful alignment to make concepts clear is a formatter I don't want near my code.
- the_real_osho 3y agoSo you just railroad a potential majority that would prefer to use it?
- vips7L 3y agoCompanies are not a democracy.
- fsckboy 3y agoso, companies are dictatorships? or what do you mean more precisely?
- vidarh 3y agoIt's part of my job to "railroad" potential majorities that would prefer to do things that my judgment suggests will make things worse. They're free to do it in their personal trees all they want. But if they commit changes that make the code less readable because some tool is being opinionated and can't be configured properly, their change won't pass code review.
- searls 3y agoThis is a huge reason why I still use StandardJS and—shifting back to Ruby—why I rejected the countless requests for implementing line-length or any other metrics analysis rules for Standard Ruby (https://github.com/standardrb/standard https://github.com/standardrb/standard). There is always a legitimate edge case when it comes to length of lines and functions and the alternative—chopping them off arbitrarily—is rarely an improvement.
- humanrebar 3y agoCounterpoint: if you want tools to help you edit your code, like linters that supply fixes or smarter autocomplete tools, you need algorithmic code formatting. You can't code taste into every tool that might want to help you edit your source code. That being said, almost all formatters have ways to tell them to go away in especially important stretches of code, with the tradeoff being ugly generated code fixups for that need hand massaging every time.
- munificent 3y agoAs someone who maintains an automated formatter (Dart format), I agree that automated formatting raises the floor and lowers the ceiling. But my experience is that it raises the floor by a large amount and lowers the ceiling only a little. Most importantly, it reduces the engineering cost to reach the floor to zero.
- a1369209993 3y ago> But my experience is that it raises the floor by a large amount and lowers the ceiling only a little. I mean, I agree that that's true at least in relative terms, but in my experience that's because it raises the floor from "bottomless pit" (eg IOCCC entry quality) to "much worse than we usually do", whereas lowering the ceiling a proverbial meter or two still means hitting my head on it (there's a upper bound on how readable code can be when you need to actually read it).
- vidarh 3y agoThe problem for me is that the effect is that you almost never make it above the floor. Maybe I'd have a different view on it if I had to work with a bunch of beginners, but I luckily don't.