Remove or relax rule for "struct field Id should be ID"

[stevvooe]

The use of "ID" rather than "Id" breaks the rule about abbreviations vs initialisms. "ID" is an initialism for "Identifying Documents", whereas "Id" is an abbreviation for "identifier". Typically, in software engineering, we are referring to the latter.

I understand that in Google and with a lot of Go code, the use of "ID" is considered the correct style. However, there are cases where code cannot follow this convention, such as when avoiding API breakage.

It would be nice to have the ability to disable this rule, such that we continue using golint for some of its better advice, such as documentation.

[dsymonds]

The style rule is to match what is normally used in prose. In that sense, "identifier" is usually written by humans as "ID", so therefore it should appear that way in Go names.

When code can't follow the usual style conventions there's nothing to do. Just ignore what golint says. Its output is meant for humans anyway.

[chuckhacker]

I am very sad to see this closed and shot down.

Another use case that is a very strong argument for removing this rule (this rule is actually an exception to another rule instead of a rule, but I digress):

Golang ORMs that infer database table schemas from structs (some, like go-pg/pg, are pedantic about the casing of Id vs ID when determining whether a field should be considered a primary key).

[paulistoan]

I also don't agree with this issue being closed. We strive to keep our code free of lint errors and now I'm being forced to rename Uid to UID, where the Go sources themselves use Uid: https://github.com/golang/go/blob/master/src/os/user/user.go#L23 Please reconsider. golint is a great tool, and we want to keep using it. Forcing our developers to ignore certain errors is a slippery slope.

[oshalygin]

This rule seems a bit crazy, can we reopen ?

[lsgrep]

This rule seems a bit crazy, can we reopen ?

[dominikh]

This tool implements the guidelines laid out in https://github.com/golang/go/wiki/CodeReviewComments – not any alternative style. If your organisation uses a different style, you should maintain your own version of golint.

Additionally, the README has been saying this since the tool's public release:

Do not treat its output as a gold standard. We will not be adding pragmas or other knobs to suppress specific warnings, so do not expect or require code to be completely "lint-free".

And these are the conditions under which you can use the tool. If it doesn't fit your requirements, create your own. golint's license allows you to maintain your own, internal version, and making the adjustments you require should be relatively straightforward.

[eunleem]

Is there an option to disable lint for this rule?

[oshalygin]

This rule is super strict and mostly nonsensical. It's one thing to make decisions on how code is styled and where to put parens, curlies, etc, its a whole different story to start enforcing a naming convention that has 0 roi and nothing more than an opinion that few share.

What @dominikh is saying is super valid though, this linter is used for Google, they built the language and they use golint internally(likely). If you want to use your own derivation, build your own.

IMO the community needs to build their own versions like eslint and stop following Google as gospel.

[MusikPolice]

@dominikh regardless of what the README says, the statement

We will not be adding pragmas or other knobs to suppress specific warnings, so do not expect or require code to be completely "lint-free".

seems antithetical to this tool's purpose. The entire point of a linter is to warn a programmer that they might be introducing a subtle error into their code, and should consider changing their approach.

As @paulistoan pointed out, telling programmers to ignore some warnings but not others is a slippery slope towards ignoring the linter altogether because its false positives are an annoyance, particularly on a large codebase.

In this case, the linter holds a strong opinion on variable naming that does nothing to enforce code correctness or reduce bug counts, yet there's no way to suppress that opinion. Most static code analysis tools that I've used in the past (PMD, FindBugs, Sonarqube), as well as most code formatters that I've used, have provided a means to suppress warnings caused by rules that my organization chooses to ignore. I don't think it's much to ask that this tool does the same, and I'd be happy to contribute to such an effort, but it sounds like the project is diametrically opposed to such work.