Repository navigation
stylecheck: allow errors to begin with proper nouns #424
Description
Example error: "Travis CI blew up, oh noes"
We probably want to maintain a configurable list of proper nouns, similar to our list of initialisms. By default we should add some of the common tech companies that provide APIs. Consider using BigQuery to farm common names.
Reacted by Dmitri Shuralyov and Ainar Garipov
Activity
dominikh commentedon Apr 4, 2019
If anybody wants to help out with this, they could run a BigQuery query over all Go code, get all error strings (calls to errors.New and fmt.Errorf) and return all the first words of the strings that start with a capital letter. Either an undeduplicated list, or a deduplicated list with counts per word.
ainar-g commentedon Apr 4, 2019
Do we really want this? I would honestly prefer to live in a world where all logs are all lowercase, all the time. It's more consistent, more greppable (hello
-F, goodbye-i), and (arguably) more aesthetically pleasing.dominikh commentedon Apr 5, 2019
I would say so, yes. The reason error strings in Go should start with a lowercase letter is to allow correct wrapping, so that
%s: %sturns intofoo went wrong: bar went wrong– the goal is to have proper English sentences. That does, however, mean that proper nouns can, and IMO should, be capitalized correctly. We already do so with initialisms and function names.In fact, log messages (i.e.
log.Print*) commonly start with uppercase letters and no official style guide recommends otherwise.grep -iseems like a red herring to me. If everyone spelled proper nouns correctly, you'd not need-i. Travis CI would always be Travis CI, GitHub would always be GitHub.zx8 commentedon Jul 14, 2021
Just got bitten by this today using
golangci-lintand ended up having to add a// nolintcomment to silence it, so came to raise a feature request to allow configuring proper nouns... and ended up here instead! 😄I realise it's not a groundbreaking feature (especially since the comment more or less solves the problem anyway), but am just curious if it's still planned to make this configurable?
dominikh commentedon Jul 14, 2021
It is still planned, yes.
nirui commentedon May 19, 2023
Hi @dominikh, is there any update on this?
The warning
error strings should not be capitalized (ST1005)has a completely different meaning thanError strings should not be capitalized (unless beginning with proper nouns or acronyms).Current behavior of
staticcheckis effectively banning (almost) all nouns from appearing at the beginning of an error message, which is not really ideal and don't actually match the review requirements.Thanks!
dominikh commentedon May 19, 2023
No updates, sorry.
nirui commentedon May 19, 2023
Oh OK. Thanks for the work anyways. Also,
This might be not a good idea since it could create some confusions (for example, on why some words are sanctioned, while not the others). If possible, I would vote for a zero-default approach, that is, by default, there is no noun on the redemption list, user must add in their own words of choice manually as needed. This approach also has the benefit of keeping the initial behavior of
staticcheckunchanged, as well as making the implementation simpler.Just my two cents :)
dominikh commentedon May 19, 2023
We already provide a default list of acronyms, so providing a default list of proper nouns seems consistent with that. People don't seem to be confused when their acronym of choice is missing from the list.
We don't strive to maintain old false or noisy positives.
It wouldn't make it any simpler. If we need a configurable list of names, then we can provide a default value for that list. That functionality already exists.