1. 5
  1. 2

    I’m glad that some of these tips have now been automated, in most cases. For example

    • #3; this is usually handeled by the IDE/editor
    • #4; this can be handeled by Prettier or some other CI and/or compiling tools. Which makes it easier for the maintainer to process PRs.
    • #5; on GitHub and many other git-repo hosting providers they provide automatic builds CI/CD pipelines which also can build when a PR is submitted.
    • #6; the same as #5 really, in the same procedure you can also see if all tests ran successfully.

    As for the last 4 tips, they are really quite useful. I know a lot of people, myself included, could create a lot more tests and probably document our reasoning quite a bit more.

    Modern development flows have come a long way in the recent years and I’m all for it!

    Sidenote: I really love that the author has replied to a comment made not so long ago with the excellent advice from Kent Beck;

    For each desired change, make the change easy, then make the easy change.

    1. 1

      I hate #4. I don’t hate it because of what the author said, but I hate that most projects that aren’t using an autoformatter tend to have internally inconsistent styles inside files let alone across the project. It’s a) difficult to know which style is ‘correct’ and b) hard to resist to urge to get consistency in the project. It’s not about ‘my preferred style’ but getting consistency. Even something as seemingly innocuous as EditorConfig goes a long way. Am I supposed to leave the trailing whitespace on a single line in the file to keep the diff small, or is this a case where when walking through the forest you should pick up some trash and leave the space better than before you came?