I am pro-standardize, but this isn't a great argument. Enforcing a standard style takes resources from both the language and the people using it. You don't spend resources on something that isn't important.

Coming up with and agreeing on a standard takes work, but in most cases unofficial standards already exist - one merely needs to be blessed. (And if some project wants to not use it, that's also free)

Yes, as you say because the style is not important. Consider the wasted time on arguments between tabs and spaces and how many spaces; the noise in PRs from style conversions that hide the actual additions and alterations; the increased efficiency that comes from learning and using the shapes of a codebase to more quickly seek.

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.

Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style. This really doesn't matter. Maybe it's just me, but I feel that a good engineer ought to be able to read code regardless of the indentation or particular language dialect (within reason).

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.

Your approach seems like the worst of both worlds: a single codebase with mixed styles.

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.

> Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style

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.

That is my take, after having written in many languages over many years.

I also think this is more of a Zeitgeist thing, to be honest.