Hacker News new | comments | show | ask | jobs | submit login

gofmt took a different approach where it respects the author's line breaks. So the following are all going to remain as is with gofmt:

    f(a, b)
    f(
      a, b)
    f(a,
      b,
    )
    f(a,
      b)
    f(
      a,
      b,
    )
My original motivation for prettier was this particular example where I was sick of having to add/remove all those newlines when the line would go below or above 80 columns. So prettier only allows the following two forms and will format code for you as you save:

    f(a, b)
    f(
      a,
      b,
    )



Well okay, but this raises the question of why code needs to always fit within 80 columns. The Go developers decided that it doesn't, and it's fine to check in the code as-is.

(In particular, automatic refactoring tools don't need to wrap lines when they get longer.)

And everything seems to have worked out fine.

It's not the only way to do it, but I think it's interesting how getting everyone to agree that a problem doesn't need solving sometimes simplifies things a lot.


You want to break --at some point--. The question is, who decides where to break? For gofmt, they decided that the person writing the code is going to make this decision everywhere. For prettier, we decided that the tool was going to make that decision, so that the humans don't have to.

If we want to do it automatically, we need to figure out an algorithm to do that. It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine. A lot of people (myself included) tried to use different algorithms but couldn't beat that heuristic.

If you know of a better way, please let me know :)


> It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine.

I'm not sure what corpus was used to determine that heuristic (nor what tab size). But it would trash a lot the projects I work on.


The goal of prettier is not to format code exactly as you would have written but to format it in a reasonable way.

The upside is that as a developer you don’t need to worry about formatting yourself as you can just write code in a bad way, save the file and it’s formatted. And as a team, you will no longer spend any time in code review arguing about formatting and doing roundtrips to change small nits.

If the result is good enough that you are willing to let go of your manual formatting, the upsides are nontrivial.


Are these projects still JS?


I was speaking in general, I don't have any dart projects which I believe is what the OP is about. I do have JS projects that I think would be rather ugly if limited to 80 char line length is that is what you are asking.


Yeah, I mean the project is specific to JS so not do relevant to consider other languages here


If you do code reviews and your code reviewers take thier role seriously, and so will push back with comments like “this is hard to read, consider breaking it into two lines” then you don’t need automated enforcement. But if code reviewers look for sufficient units tests, obvious errors, and then dash off a LGTM, software style enforcement is second best.


In practice, this doesn't come up in review and Go code is quite readable anyway. Apparently people just don't need much help to get line lengths more or less right.


> [..] why code needs to always fit within 80 columns.

Optimal text width for readability is 4-6 inches or (typically) 50-75 characters. Code, with its indented nature, tends to fit nicely within this if you keep to the 80 column rule.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: