Open Zamiell opened 4 years ago
One more reason:
Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. <...> However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them.
I also believe that Struct tags should be ignored too (they are also strings)
I made https://github.com/golangci/golangci-lint/issues/3983 to track this in golangci-lint repository.
One of, if not the most popular style guide in the world is the Airbnb JavaScript Style Guide, which represents best-practice across a lot of the JavaScript and TypeScript ecosystem.
In the style guide, it mentions:
This policy seems sensible. With the "bad" code example above, grepping through a project for "thrown because of Batman" would return 0 results.
One other problem with using string concatenation is that realignment is tedious when you have to remove a sentence. And it introduces unnecessary Git noise. e.g.
-->
In JavaScript/TypeScript land, the most popular linter is eslint, which is similar to lll in that it has a max-len rule. It has an
ignoreStrings
flag which is set to true by default - a sensible default.The implementation for this is located here: https://github.com/eslint/eslint/blob/master/lib/rules/max-len.js#L314-L315 As you can see, it is extremely simple.
In Golang land, I think the practice of ignoring strings should also apply, for precisely the same reasons. I was curious to see if other big Go projects were breaking up long strings, so I took a look at Kubernetes, which is probably the biggest. I was only able to find one instance of concatenated strings. Instead, most code is written like like this.
Similar to eslint, is it possible to add an
ignoreStrings
flag to lll? Currently, I have gotten so fed up with adding//nolint: lll
everywhere that I have stopped using the linter, but it is a great tool and I would love to be able to use it again in the future.