RFC: build/analysis: add commentwrap
This adds a Go analyzer which limits the length of comment lines to 80
characters.
Rationale:
Monogon currently follows gofmt style. Gofmt in itself is already quite
opinionated, but one thing it explicitly does not check for is maximum
line length.
This implements a limit for the maximum length of a comment line in Go
source within Monogon. It explicitly does not limit code line length, as
these can be handled much more easily by soft reflows.
The tool used, github.com/corverroos/commentwrap, will now be
automatically ran by our nogo pass, and prevent any line of commnets
within Go to be longer than 80 characters, with the exception of:
- cgo/generate directives
- TODOs
- indented comments (eg. sample code or long URLs)
Downsides:
1. We have to reformat the entire codebase. CR/67 does this.
2. We end up with a bulk Git commit that will pollute Git history. A
followup CR attempts to resolve this by using Git's ignoreRevsFile
functionality.
3. There's currently no integration with IntelliJ and no way to
automatically reformat code. If this RFC gets approved, a follow up
CR will be created that adds integration/automation to make this
easier to work against.
Open questions:
1. Is 80 characters the right limit? I, personally, quite like it, but
am willing to compromise on line length.
Change-Id: I063d64596ca5ef038a8426c6b9f806b65c18451e
Reviewed-on: https://review.monogon.dev/c/monogon/+/66
Reviewed-by: Leopold Schabel <leo@nexantic.com>
diff --git a/build/fietsje/main.go b/build/fietsje/main.go
index 1345644..50055ab 100644
--- a/build/fietsje/main.go
+++ b/build/fietsje/main.go
@@ -135,6 +135,18 @@
// goimports
p.collectOverride("golang.org/x/tools", "v0.0.0-20201215171152-6307297f4651")
+ // commentwrap is used as a nogo analyzer to stick to a maximum line
+ // length for comments.
+ // We have to patch both it and its only direct dependency to add generated
+ // go_tool_library targets. This is needed as Gazelle doesn't generate them,
+ // because they're a temporary solution to a problem that shouldn't exist soon:
+ // https://github.com/bazelbuild/rules_go/issues/2374
+ p.collect("github.com/corverroos/commentwrap", "2926638be44ce0c6c0ee2471e9b5ad9473c984cd",
+ patches("commentwrap-tool-library.patch"),
+ ).with(patches("reflow-tool-library.patch")).use(
+ "github.com/muesli/reflow",
+ )
+
// First generate the repositories starlark rule into memory. This is because rendering will lock all unlocked
// dependencies, which might take a while. If a use were to interrupt it now, they would end up with an incomplete
// repositories.bzl and would have to restore from git.