> Code formatting, code style, and linting is a solved problem.
Only the low hanging fruit. Yes, they'll reduce tabs vs spaces debates. No, I haven't found a linter that can suggest good function naming, and if I did it probably wouldn't work across all of the 10+ languages I get to use at a typical gamedev job. Most stylers and linters don't even catch basic spelling mistakes.
Sure, use tools to help, and push to adjust your coding standards to conform to the limits of those tools where practical and sensible - but even that's no panacea, it won't solve everything.
> If you're relying on individual developers to setup their Dev Env to do this you're doing it wrong. You need to have it automated with commit hooks.
Considering you commit locally in git I'm confused how you're supposed to avoid having any dev env setup. Maybe you'd suggest imaging your dev machines, but that's a massive waste of time for smaller shops where your install requirements change more frequently than your image gets installed, and tend to be user specific. You want a living document/checklist that you can update before setting up a new box, and default settings files, not constantly rebroken over-automation. Nor is the average FOSS contributor going to download gigs of images just to format a bugfix patch when trying to contribute back upstream.
> Anything else is a solution that results in aggregating nitpick reviews that ignore glaring structural problems.
You can't technology your way out of a social problem. I have seen low-automation environments without this problem, and I have seen high-automation environments with this problem.
You're not going to convince your coworkers to spend more time/brainpower into spotting glaring structural problems by ignoring half their feedback. They'll rightfully assume you'll likely ignore half their suggestions for structural fixes too, wasting their effort. Especially if your claim is that you "ain't got time for that" - don't got time for a quick and easy code style fix? How the heck am I supposed to convince you to spend the time to do more serious refactoring to fix structural problems, or add unit test coverage to catch what my reviews will miss, then?
I'm not saying you should manually fix up every style issue in your code, but if code formatting/style/linting is truly such a solved problem, then it's going to be way more constructive to setup the configs/rules/hooks to fix it for everyone once and for all, than to simply ignore it.
Only the low hanging fruit. Yes, they'll reduce tabs vs spaces debates. No, I haven't found a linter that can suggest good function naming, and if I did it probably wouldn't work across all of the 10+ languages I get to use at a typical gamedev job. Most stylers and linters don't even catch basic spelling mistakes.
Sure, use tools to help, and push to adjust your coding standards to conform to the limits of those tools where practical and sensible - but even that's no panacea, it won't solve everything.
> If you're relying on individual developers to setup their Dev Env to do this you're doing it wrong. You need to have it automated with commit hooks.
Considering you commit locally in git I'm confused how you're supposed to avoid having any dev env setup. Maybe you'd suggest imaging your dev machines, but that's a massive waste of time for smaller shops where your install requirements change more frequently than your image gets installed, and tend to be user specific. You want a living document/checklist that you can update before setting up a new box, and default settings files, not constantly rebroken over-automation. Nor is the average FOSS contributor going to download gigs of images just to format a bugfix patch when trying to contribute back upstream.
> Anything else is a solution that results in aggregating nitpick reviews that ignore glaring structural problems.
You can't technology your way out of a social problem. I have seen low-automation environments without this problem, and I have seen high-automation environments with this problem.
You're not going to convince your coworkers to spend more time/brainpower into spotting glaring structural problems by ignoring half their feedback. They'll rightfully assume you'll likely ignore half their suggestions for structural fixes too, wasting their effort. Especially if your claim is that you "ain't got time for that" - don't got time for a quick and easy code style fix? How the heck am I supposed to convince you to spend the time to do more serious refactoring to fix structural problems, or add unit test coverage to catch what my reviews will miss, then?
I'm not saying you should manually fix up every style issue in your code, but if code formatting/style/linting is truly such a solved problem, then it's going to be way more constructive to setup the configs/rules/hooks to fix it for everyone once and for all, than to simply ignore it.