There is value in having local consistency, which is usually achieved through having rules.

The more uniform a code base, the easier it is to breeze around and get stuff done. Naming things is already hard, so having rules around the annoying bits is nice.

Rules are best handled by automated tools with as few configuration options as possible - like gofmt or black.

This way people won't start bikeshedding about the placement of curly braces, they either accept the style or move on.

It also prevents things from getting political or personified. It's the tool that's making the decisions, not a specific person.

This is why I push for gofumpt over gofmt

These rules aren’t really about naming things, which I agree is hard. It’s pedantry around terms that really don’t matter which way you choose and thus are categorically not “best practices” let alone “idioms” one must abide by.

If the author really cares this much then they should be linter rules instead of a blog post.

I don't know, code that isn't at least internally consistent with itself in capitalization is a pet peeve. There should be one way to do a thing.

When is agree when talking about all caps terms like HTTP or even just camel case verses snake case. But it’s really scraping the barrel of usefulness when you’re debating whether the H in Github or A in OAuth is capitalised.

Just write a linter rule and be done already.

Github has a neat extension to its' markdown syntax where if you comment with a block for a specific line or lines, it will render to have a "commit suggestion" button.

```suggestion

my_change

```

if there's someone on your team prone to style nitpicks like this, this can often sate them, and it's convenient for you to merge into your branch

A project should have an .editorconfig setup that automatically hints or enforces the correct code style in the IDE.