Comment by jillesvangurp
Comment by jillesvangurp 2 days ago
It's a minor issues in teams where people use inconsistent formatting. This causes needless complications when merging code and additional work related to resolving conflicts that shouldn't exist to begin with.
Some languages (Go, Rust) have essentially solved this issue to the point where blindly running the formatters these languages have solves the problem and is uncontroversial.
Sadly, the language of choice for me (Kotlin) has a big unaddressed problem here where what the IDE does for formatting and what independent formatting tools do are two things that are hard to align for mostly the historical reasons that what the IDE does is fragmented over different bits of code that don't listen to the same configuration. There is a lot of variation in preferences for indentation, where to put new lines, line length, what order to put imports in, which imports to use wildcards for (if any at all), etc. Particularly imports are a problem because the bit of code that organizes imports is separate from the bit of code that formats code in the IDE.
The common solution of using IDE plugins to work around this is a bit of a kludge. The proper solution would be a more sane way to just make the IDE externally configurable so that build tools can make the IDE do exactly the same as what they do without requiring users to manually configure their IDEs just right by installing plugins or fiddling with configuration. This stuff should not be user controllable if there is a build file that defines the proper formatting.
Coding agents actually add to this problem. Because getting those to stick to formatting conventions is tricky. Unless you have tools that just fix that properly.
So good change in uv and probably something I'd be using on my next python project (I do those once in a while).
Easily solvable with SCM pre-commit hooks, at very least since CVS days.
All major IDEs allow to save the format configurations, which can be stored on the repo alongside the code as the team official's configuration.
Coding agents solve this problem in that eventually all programming languages will be as relevant as mastering Assembly is nowadays.
I already do stuff in low code/no code, that in the past I would be manually writing code to sort out those issues.
In the meantime, you can also ask them to format generated code in whatever way one feels like it.