Establish a code formatting style and make sure that it is enforced during the build, maybe using tools like Spotless and/or Checkstyle.
I was thinking about this topic for at least two years on and off, always putting it off, as I am basically the only regular committer. OTOH, that would be the perfect opportunity to introduce such tooling without disrupting other developers. If anyone would on-board to AspectJ in the future, the infrastructure would just be in place already, including the infamous big commit (BC) reformatting everything.
But that same BC was what I wanted to avoid or put off for a while, because it would mean that git annotate|blame would become a bit more tedious in the future. The good news are:
Git config option blame.ignoreRevsFile can ignore revisions such as the BC. It might be possible to add the option to a config file committed right into the repository, I have not verified that yet. Otherwise, at least locally it could be used.
IDEs like IntelliJ IDEA have options to handle certain types of changes (whitespace, moved blocks) intelligently when annotating files:
I am quite opinionated about what code style I like. Being the sole committer would also mean that I would impose that style on future developers. But at least, it would be a clear guideline. I could just use default settings or well-known code styles for Maven plugins or IDE settings, but those are exactly what I sometimes dislike and perceive as ugly in other projects I contribute to. Spotless often just gets on my nerves - not so much, because it forces me to reformat to make a build pass but rather because it tends to destroy carefully crafted code looking good to my own eyes. Each tool has options to deactivate format enforcement for sections of code, and we should allow for that, but not make it a quasi standard to be used as an excuse to get around the formatting check. E.g., the reviewer for PRs would also decide whether or not to accept any exceptions in the PR. That would give some leeway to developers in cases where reformatting woud make the code less readable. The goal, however, should be to find settings covering most code in most situations in an acceptable way. If reformatting displeases me, but not so much that it causes "eye cancer" when reading it, it should be OK. Otherwise, a formatting exception in the source code might be the better alternative.
Establish a code formatting style and make sure that it is enforced during the build, maybe using tools like Spotless and/or Checkstyle.
I was thinking about this topic for at least two years on and off, always putting it off, as I am basically the only regular committer. OTOH, that would be the perfect opportunity to introduce such tooling without disrupting other developers. If anyone would on-board to AspectJ in the future, the infrastructure would just be in place already, including the infamous big commit (BC) reformatting everything.
But that same BC was what I wanted to avoid or put off for a while, because it would mean that
git annotate|blamewould become a bit more tedious in the future. The good news are:git blame -wignores whitespace changesblame.ignoreRevsFilecan ignore revisions such as the BC. It might be possible to add the option to a config file committed right into the repository, I have not verified that yet. Otherwise, at least locally it could be used.I am quite opinionated about what code style I like. Being the sole committer would also mean that I would impose that style on future developers. But at least, it would be a clear guideline. I could just use default settings or well-known code styles for Maven plugins or IDE settings, but those are exactly what I sometimes dislike and perceive as ugly in other projects I contribute to. Spotless often just gets on my nerves - not so much, because it forces me to reformat to make a build pass but rather because it tends to destroy carefully crafted code looking good to my own eyes. Each tool has options to deactivate format enforcement for sections of code, and we should allow for that, but not make it a quasi standard to be used as an excuse to get around the formatting check. E.g., the reviewer for PRs would also decide whether or not to accept any exceptions in the PR. That would give some leeway to developers in cases where reformatting woud make the code less readable. The goal, however, should be to find settings covering most code in most situations in an acceptable way. If reformatting displeases me, but not so much that it causes "eye cancer" when reading it, it should be OK. Otherwise, a formatting exception in the source code might be the better alternative.