You're right to an extent, but I don't think "Run your code through a formatter when you're done hacking it together" is a viable, maintainable, or scalable policy. Especially not for enterprise or team based workflows.
Also, #'s 1, 2, 4, and to a certain extent 8 are more questions of design pattern than 'style'.
> 2. Use consistent spacing and use whitespace liberally.
The very definition of a formatting bikeshed.
> 1. No instance variables.
I'm not convinced here - he certainly doesn't explain why you shouldn't use them. I guess he likes to use self.var rather than var - but it's important to note that this does have some performance implications.
> 4. Modularize and model.
I'll give you 4 though - using compiler recognizable types is always a boon. I'm not sure if anybody really needs to be told to modularize and model, most people would understand that without being told. It does lock-in your public API though, making changes to a library require updating all apps that use the library. Meanwhile, adding a new field into a dict means existing apps can upgrade the library easily. Still, I'd definitely agree that types are always a better bet in the long run.
> but I don't think "Run your code through a formatter when you're done hacking it together" is a viable, maintainable, or scalable policy.
Just hook clang-format or clang-tidy with your build system. A lot of projects do it.
You will be surprised how inconsistent people actually are, even in project where almost everyone is sticking to these practices at 100%. And the larger the project, the worse it gets (most people are inconsistent in different ways).
The only way to get this right is to either produce hard errors when they are violated (e.g. your code won't compile, or won't be committed) or do it automatically. clang-tidy is just the way to go.
Also, #'s 1, 2, 4, and to a certain extent 8 are more questions of design pattern than 'style'.