Yesterday, I wrote about how your code base should look like one person wrote it, even when you have a team. A big part of that is having a code style guide that documents team norms around authoring code. But in larger code bases, manually reviewing and enforcing that can become a big time suck. That’s where tooling can be useful! My favorite tool for this is ESLint. ESLint’s primary role is as a code linter to catch bugs.
    • @BatmanAoD
      11•6 months ago

      …why not both? An auto-formatter for personal use, a linter for CI checks on PRs.

      • @[email protected]
        8•6 months ago

        I agree : CI is required as a safety belt and then contributers can choose the workflow they prefer : format on save, manual invoke, precommit, …

    • @[email protected]
      2•6 months ago

      Agreed, just run it all through a formatter and save everyone some time. Those who break the formatter will learn to conform 🙃

  • @[email protected]
    12•6 months ago

    You’d be surprised what you can accomplish purely through a robust PR review process and a clear standards document.

    That said, tools to enforce and autocorrect basic syntax stuff can be quite helpful.

    • @Lmaydev
      2•6 months ago

      Absolutely but it can reduce a lot of work if as many things as possible are enforced before you get to that stage.

  • @Lmaydev
    1•6 months ago

    I recently enforced coding standards in our c# code bases.

    Basically used an editor config and project properties to enable all analysers and set all rules to warnings. Also set warnings as errors for release builds.

    I’ve then been adjusting rules by hand if they’re irritating or wrong.

    It’s having great results and has already caught a load of bugs.

    But my god do the juniors hate it haha