Hacker News Reader

Comment by hoosieree | Hacker News Reader

    “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

stand

OUT!

View on HN

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

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

Good formatters do understand the code, though. They parse it much like a compiler does.

They understand the syntax of the code. They may even understand the types and relationships. They don't understand meaning and can only have very rough estimates at logical complexity.

I've yet to experience a good formatter.

I tried your code on prettier.io and got a result that was more visually consistent than what you pasted here.

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

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

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

So you just railroad a potential majority that would prefer to use it?

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

Companies are not a democracy.

so, companies are dictatorships? or what do you mean more precisely?

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

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

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

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

Reply on news.ycombinator.com