* Indenting consistent with the curly braces, and well enough defined that when you remove an outer loop and want to unindent the code from that block, you don't have to do it by hand.
* A one-line code change doesn't bring with it a 500-line style change because the file passed between people with different style tastes.
Unfortunately, it's often difficult to achieve these modest desires without someone also wanting to limit line lengths, ban the ternary operator, ban nulls, and so on...
In general, one should refrain from drive-by refactoring.
That’s much closer to being “the way infrastructure operates” than formatting is.
I suppose 100% of IAC is right out, then.
[edit] naming, yes. That’s important. Static types are enormously important—machine-checkable documentation is the best sort. Comments are excellent if names and types aren’t enough. Separate documentation if all of those fail. Where my braces go or tabs-v-spaces or what have you? Not so much, but again, maybe it’s because we write different languages.
things
.where($"key" === lit(key))
.select("value")
.as[String]
.repartition(N1, $"value")
.flatMap(new ThingIterator(_))
.repartition(N2)
.write
.parquet(
s"s3a://bucket/things/key=$key")
When I've led teams, I've never enforced things like indentation or bracketing styles. Things I do enforce are (1) explain complicated code with comments, (2) make it readable (for whatever definition of readable), and (3) reasonable naming conventions (i.e., don't name every variable i, j, k). These guidelines are useless for automated tooling. Perhaps in the age of LLMs this will change (who knows).
I've found the strict requirements and automated tooling absolutely terrible. I often align things to keep parallel structure to show how different lines are the same or to create 'tables', etc. Formatting tools destroy this. For me, using my emacs rectangular editing, the alignment greatly increases productivity. This is one example. I'm much faster at editing personal projects / projects I've led than ones with strict style guidelines.
For me, I always tell my guys: edit in the style in which you are fastest and most efficient. I believe this greatly increases productivity rather than having a team 'nosy neighbor' that cares whether you use two or four spaces for indentation.
My two cents.
I work at a large tech company, and while I don't really participate in style wars, I do care that there is a single enforced standard across any particular codebase.
I disagree for two reasons:
1. Optimizing for what each dev is used to is optimizing for a local maximum. If they’re THAT good it won’t take them long to adjust to new defaults. Good engineers should be able to pick up a new lang quickly so some changes in the context of a language should not bog them down significantly in the long term.
2. The overly long time it took to set up tooling in a particular company or language do not outweigh the bigger advantage of being able to quickly get a grasp about what a piece of completely unfamiliar code does.
I also think this is more of a Zeitgeist thing, to be honest.
It doesn't matter what the style convention is so long as you have one, you have automated tooling that creates and validates it, and that enforcement is done by machines as part of the delivery process.
Not because style is valuable but because time is a valuable resource and spending it on preference differences and dealing with variances is wasteful.
I might paste something, but mess up and forget to select one of the curly braces or select too many. I am seriously considering closing all of them on the same line in this style
if blah {
thing; }