15 ms·

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half

• 6gvONxR4sf7o 6y ago
  So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized as soon as I hit save. Now I don’t even really care what the standard is because it only affect reading code.
  • michaelmior 6y ago
    I agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code on read to the current user's preferred format and then back to the canonical format on commit. Although this seems potentially error prone.
    • ambicapter 6y ago
      > When it comes to modifying existing code You don't have to deal with anything as long as you're using the same formatter everyone else is using.
      • michaelmior 6y ago
        My point was that when writing new code, I can write it in whatever format I want knowing that it's going to be formatted the canonical way. But when modifying code, I have to work with code in one specific format that may not be my preferred format.
        • asutekku 6y ago
          Can’t you just set up a linter/formatter to your style, apply it to your style when editing and on save set it to the project style?
          • kevin_thibedeau 6y ago
            It fucks up the diffs in the codebase.
            • michaelmior 6y ago
              How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.
              • kevin_thibedeau 6y ago
                If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.
                • michaelmior 6y ago
                  If you're talking about moving from a codebase that did not use a consistent formatting style or a style that did not match the auto formatter configuration, sure. I was assuming a case where automatic formatting was done from the start.
                • mcgoo 6y ago
                  This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way. The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply. The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above. This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.
    • libria 6y ago
      I feel like this is a team preference problem and not a formatter problem. The formatter will only do what you tell it, spaces or tabs. Looking at this another way, formatters are designed to "frustrate" devs into working only 1 way. If you think it's more helpful to have a codebase with mixed spaces/tabs with commits that express each developer's unique flair, then a formatter is not for your team.
      • VectorLock 6y ago
        Formatters are a way for one person who likes the formatters output to enforce their will on other who might not necessarily like that.
  • closed 6y ago
    I would be a bit surprised if this is true, because it implies that when you're writing code that will be formatted you do not think of the reader's experience. This could be the case if you have extreme confidence in the formatter, but I have def seen some very funky black outputs. It seems like when writing people will likely do so with a model of how black will yield the final code in mind. (Eg "if I add more characters to this one line list statement, it will get exploded across 5 lines", and affect readability, etc..)
    • pmiller2 6y ago
      Rather than “writing... with a model of how black will yield the final code in mind,” it’s more like “Oh, shit, Black made a real mess of this. Can I fix this without butchering the code?”
      • closed 6y ago
        Yeah--we're basically second-order black formatters now. Not writing code that looks nice, but writing code so a tool that writes code will make it look nice.
        • pmiller2 6y ago
          Not really. At least that wasn't my intention to say that. Most of the time, I find Black does a Good Enough Job(tm) that I don't care to mess with it.
    • VectorLock 6y ago
      Formatters don't have the understanding like the developers do. Certain changes that might increase the understandability for a human might get obliterated if they don't conform to the rules of the autoformatter.
• rowanseymour 6y ago
  It's been go-fmt that's converted me to this way of thinking. It's such a waste of time having a linter tell me after I've checked in code that I'm missing a space on line 123... please just add the space. Please let me and my colleagues never have to argue again about what is the right way to format something.
  • FredrikMeyer 6y ago
    Many linters have built-in auto-fix features like what you describe. (eslint, for example)
    • celticninja 6y ago
      rubocop -a For the win.
      • reledi 6y ago
        Not the same experience as some of the best formatters out there. RoboCop is too configurable and too slow.
      • halostatue 6y ago
        It would be nice if Rubocop didn’t need as much customization as it does, because it promotes styles that violate everything I have done in my 18 years of writing Ruby. Some of its defaults? Fine, whatever. Others? They’re just _wrong_.
  • unfunco 6y ago
    I feel the same, fmt is a productivity boon for me too. There was a good quote from Rob Pike in his Go proverbs talk: "Gofmt's style is nobody's favourite, but gofmt is everybody's favourite."
  • deleted 6y ago
    [deleted]
• philwelch 6y ago
  I can wholeheartedly recommend Black for Python, gofmt for Go, and terraform fmt for Terraform. What are some other great formatters out there?
  • kevinastone 6y ago
    The previously mentioned prettier[0] along with swift-format[1] and rustfmt[2]. [0]: https://prettier.io https://prettier.io [1]: https://github.com/apple/swift-format https://github.com/apple/swift-format [2]: https://github.com/rust-lang/rustfmt https://github.com/rust-lang/rustfmt
  • wenc 6y ago
    Another recommendation for Black. I use 'black -l 120' because the default PEP recommended 80 chars per line is too restrictive.
    • minimaxir 6y ago
      Black uses a 88 char per line limit. In the course of normal Python coding I rarely hit it. For public code I do not recommend changing the defaults since it may make PRs a mess.
      • philwelch 6y ago
        The 88 character limit is just a best effort thing anyway. I find the double-quote coercion more disruptive.
        • wenc 6y ago
          I started programming in the 80s, so I'm used to double-quoting anyway. Apostrophes occur so often in English that it makes it easier to type strings like "I'm a dog". With single quoting you have to go 'I\'m a dog'. If I hit double quotes in a string, I just triple-quote. """He said "hah" sarcastically""". I know Guido (van Rossum) prefers single quotes -- I'm not sure why exactly -- so it's become a default Python style. I tried to adopting it but always ended up reverting to double quotes.
• protonimitate 6y ago
  Yup, we recently implemented auto linting/formatting using pre-commit hooks and it's made a huge difference in maintainability and readability. I don't care about the specific formatting/linting rules as much as I care about consistency. Auto formatting is great to reduce friction for those on the team who can't/won't convert change how they write code locally.
• BiteCode_dev 6y ago
  > This is why we allow users to use any rules for the linter as they see fit for their repository. So not like prettier/black/goftm. You get to choose. It's more of a way to group things. Which make sense. I don't mind being dictated code formatting, but linters will complain about branching, number of arguments, comments and so on. I change the settings of my linter for each project. Those should not be fixed.
• SPBS 6y ago
  I like formatters like Prettier and gofmt as well, but not StandardJS. I'd still use it if everyone used it though. I just don't like their stance of relying on automatic semicolon insertion, even if Go does the same thing
• fizixer 6y ago
  That's exactly the right way to do it and I've been advocating for this, as well as maximum use of parsing/tranformation/codegen technology (essentially compiler tech) for development productivity, long before LSP was a thing.
• honkycat 6y ago
  One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away because you like your bracket with a different spacing is IDIOTIC. Run the formatter and move on.
  • chrisweekly 6y ago
    Agreed. I adopted the Wes Bos approach (drive Prettier from ESLint) and it's fantastic.
    • antigirl 6y ago
      Any links? I only use it for react. I found eslint auto fix works well enough for node etc
      • chrisweekly 6y ago
        https://github.com/wesbos/eslint-config-wesbos https://github.com/wesbos/eslint-config-wesbos
  • ianleeclark 6y ago
    I agree with this wholeheartedly. Being introduced to gofmt a few years categorically eliminated a certain class of PR comments allowing PRs to be more focused on actual implications and logic.
  • necrotic_comp 6y ago
    Not to mention that if multiple people work on a codebase over time, if a very large project gets very old (like 20 years old), having consistent formatting goes a long way in allowing people to understand code that they may not have context for.
  • pmiller2 6y ago
• philsnow 6y ago
  Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / indentation / grouping / whatever. I want language-agnostic, AST-aware diffing, that de-emphasizes the part of a chunk that is irrelevant-in-the-world-of-auto-matic-code-formatting.
  • dllthomas 6y ago
    Hopefully you're already aware but just in case: many tools (including git and github) have an option somewhere to hide whitespace changes. In some contexts this can help a lot, though it certainly doesn't get us all the way there.
  • nxrabl 6y ago
    Append “?w=1” to the end of a Github PR URL, it’s like passing “-w” to git. (Not that that addresses all of your comment, I just wanted to share the tip. Agreed that smarter diffing would be really nice.)
    • u801e 6y ago
      git diff has a --diff-algorithm parameter that has several options to choose from. I don't know whether Github supports that via url parameters though.
  • kristo 6y ago
    Why don’t we just check ASTs in to git instead of text files ?
    • ssivark 6y ago
      I think this is the key question, and doing this will enable numerous interface improvements for people working with software (Eg: separation of content and presents means that everybody can use their favorite view — three-space-tabs, extra-long lines, whatever). The challenge is that version control on text files (list of lines) is fairly straight forward and language agnostic, while OTOH the VCS would have to run after the language parser processes on the text file, and then be able to interface with the AST generated by the parser (for multiple languages). I presume this would become easy if different languages have the same parsing setup, or we have language/project-specific VCS tools. While the answers are not obvious (to me, at least) this definitely seems like the right direction to move in, instead of getting hung up on plain text and formatting issues.
• KerryJones 6y ago
  Yeah -- we use Python Black and it's a blessing. The entire purpose was to replace linting so that we could have something extremely opinionated so that people could stop arguing. This seems like a cool tool, but I don't know if I would use it at this point. I would _pay_ for having autoformatters from Github -- it was a pain to set it up and would love to just enable on new projects.
• BurningFrog 6y ago
  I can definitely format code better than Black does. But that's probably not true for the average programmer. I do appreciate it formatting big dicts for me. If you find formatting discussions with your teammates painful, Maybe some fraction of your team are stubborn jerks? I've worked where formatting discussions were always friendly and constructive. It can be done.
  • nilkn 6y ago
    My experience with black is that it’s good enough for Python that it’s a waste of time to not use it. Sure, on many teams formatting discussions are friendly. But why even spend the time? It also really democratizes the language, because even folks brand new to Python or who are inexperienced with programming in general end up with code that is well-formatted and consistent with everything else.
    • BurningFrog 6y ago
      To me, because readability is the most important aspect of programming, and it needs to be done right.
      • nilkn 6y ago
        But what do you get in that regard by not using black? Maybe in 1% of cases you’ll find a better way of formatting that everyone will also agree is better. That doesn’t seem worth very much at all to me, especially when by not using it you have to do a lot of manual work across the entire team now to get the 99% that is free with black.
        • BurningFrog 6y ago
          Black is not free. At least not for me. I have to put in a fair amount of work to get Black to produce decent code. Things like changing names to affect line breaks, inlining or outlining expressions etc. Small things can turn 1 line into 8, and vice versa.
• vorticalbox 6y ago
  Out front end team use prettier on back team we use eslint and air bnb style. But totally agree on forced lining. Stopping things like reassign function parameters, no unused variables and the like really makes code far nicer. I also love auto formatting in vscode saves a lot of time.
• microcolonel 6y ago
  I think some mix should be reached with auto formatting. I like the automatic indentation I get in Emacs with clojure-mode, but for everything else, manual formatting is just better.
• pmiller2 6y ago
  I agree with you. We recently implemented a mandatory code formatter for Python code at work. Many people hated it, but I love it for this exact reason. Now, I never get comments about formatting! In general, I tend not to care a whole lot about style, except to try and match whatever is pre-existing, as long as it’s vaguely readable. Otherwise, it’s basically whatever python-mode on emacs does, subject to a reasonable line length. Formatting nitpicks in code review bug me enough that I always just give in and do what they suggest.
• z3t4 6y ago
  I don't like auto-formatters as they take away the personality, and sometimes even change the meaning of the code. I prefer intelligently formatted code over automatically formatted code.
• justatdotin 6y ago
  when my co-worker moves a curly boy, I'll fight to the death. When a tool does it, I shrug and move on..
• gtm1260 6y ago
  I really want to love Prettier, but I never want to spend the hours googling etc. on how to setup the frickin config files! Especially as someone who works on a wide variety of languages/file types, I really want to find a drop in formatter that works well enough in all situations.
  • CGamesPlay 6y ago
    I think you might be thinking of ESLint? Prettier has, like, 10 options, and they are all listed on this page [0], and you aren't required to even have a config file because the defaults make sense. I personally find ESLint to be a nightmare of configurability and silly defaults. [0] https://prettier.io/docs/en/options.html https://prettier.io/docs/en/options.html
• autarch 6y ago
  Universal formatter & linter tools already exist. A whole bunch of them, and they're much better than this one. I wrote about a number of them on my blog at https://blog.urth.org/2020/05/08/comparing-code-quality-meta-tools/ https://blog.urth.org/2020/05/08/comparing-code-quality-meta...
• artursapek 6y ago
  My first real software job I was subject to long, painful PRs full of semi-colon nitpicking. I fucking hated it and have made sure to use auto formatting on any project I work on from now on. gofmt paved the way, but rustfmt and Prettier are also great.
• pezo1919 6y ago
  I'd like to see robust solutions for formatting personalisation: locally I'd like to use my own style, but in repo it might be canonical so an assistance for that might be easier to create.
• OkGoDoIt 6y ago
  That would be great if I actually worked on a team who saw the light and used tabs. Unfortunately I haven’t had that pleasure in a long time, so no, I do not agree with their formatting choices to use spaces. I guess what I really need is an editor that will convert spaces to tabs when I open a file and then convert it back to spaces when I close the file. Although that’s still not quite ideal because it’s not always a lossless 2-way conversion.
  • nitroll 6y ago
    No, you need an editor that abstracts away the indentation and uses the existing style of the file. I use the tab key to indent code, my editor (Emacs) is configured to just cycle through sane choices.
• ris 6y ago
  gofmt's idiotic handling of maps and forcing them to align entries was enough to put me off the entire idea of autoformatters. Enforcing a code style where adding a single byte can result in an unlimited-number-of-lines block in a diff is pure idiocy. It's bad enough having to review someone's changes when they're polluted with this garbage, but it also makes merges fail more often and pollutes `git blame`. The idea that people will put up with this crap because they can't just unclench about a few spaces here and there I will never understand. "But it minimizes diffs because it stops people committing simple spacing changes" - people shouldn't be adding those hunks to their commits in the first place and such changes need to be pulled out in review. This will also get people out of the habit of just blindly doing a `git add`. edit: I'm certain that if slightly non-uniform formatting really sets off your OCD then this should be solvable to some degree at the editor level, but please keep your obsessions out of my repository. In return I'll keep mine out of yours.
• chriswarbo 6y ago
  IMHO there should be a distinction between code serialisation (the bytes on-disk, in version control) and code formatting for display/editing. The serialisation should be normalised automatically, preferably in a way that minimises line-based diffs. The way code is formatted for display should be distinct, and can usually be more of a personal preference. Most people seem to be happy for their editor to use syntax highlighting to make things more readable, but not much else. Indentation, line length, aligning sub-expressions, etc. can also help readability, but showing those things differently from the bytes on disk is usually avoided. Perhaps this is due to a conflation of meaning for certain bytes. For example, \n can mean "token separator" to the language, "long line splitter" or "intent separator" to the developer, "unit of comparison separator" to version control, etc.
• Insanity 6y ago
  Exactly what I love about Go and Gofmt.
• bborud 6y ago
  I used to program Java. A friend of mine put together the largest slide deck I have ever seen documenting not only how we format code, but also rules for how to structure code. We spent a lot of time on making the code look like it at least came from the same company. And weeks of my life has been wasted trying to get people to agree on code formatting and coding style. Fast forward a few years and we start using Go. I didn't agree with some of the formatting choices or code conventions. And pretty much everyone on the team had at least one thing that would grind their gears. But we agreed that we'd use the gofmt tool to format the code. As everyone now does: by ensuring whatever IDE or editor we use pipes the code through that. It took less than a week for everyone to adapt and I have hardly heard anyone complain since. There are still things I think could have been different, but for me, that's a very low price to pay for not needing to have these discussions.
• myko 6y ago
  Very frustrating working in Xcode because it doesn't support a code formatter out of the box. Some extensions do a passable job but randomly break when I have multiple versions of Xcode installed.