You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a go developer, especially one new to a project, when I open a go file, I find it very helpful when I can easily read and reason about which stdlib, external, and internal dependencies we have. Sorting the local (github.com/defenseunicorns/lula) packages to the bottom of the imports list is a decently widespread practice and (in my biased opinion) the sorting makes codebases look more professional/polished.
Developers can automate this with goimports, adding the -local github.com/defenseunicorns/lula flag. Modern code editors (and emacs 😉) can be configured to do this automatically on save and the linters in #742 include goimports and gofmt, so we'll get errors (non-blocking - FOR NOW) if folks forget to sort imports.
There is one annoying recurring issue with the go import sorting - something which I've already fixed in a couple of files, so it's not specific to the local package sorting, but (especially when refactoring) sometimes you'll end up with extra newlines between blocks of imports that need to be manually removed. Neither goimports nor gofmt catch that because it's something we could validly and explicitly do - we could for e.g. also have a block of non-lula defense unicorns packages (not a recommendation). But it can get annoying and I wanted to be open about that.
The following is just way too much explanation no one asked for, why did I write this, i don't know 🤷🏻
Here's a sneak peak at the before and after (in case anyone is still on the fence and wants to see):
While I do absolutely admit to a generic sorting bias, I find the bottom example easier to read and I can get an idea of what's happening in this file before reading the code in a way I could not do before.
As a go developer, especially one new to a project, when I open a go file, I find it very helpful when I can easily read and reason about which stdlib, external, and internal dependencies we have. Sorting the local (
github.com/defenseunicorns/lula
) packages to the bottom of the imports list is a decently widespread practice and (in my biased opinion) the sorting makes codebases look more professional/polished.Developers can automate this with
goimports
, adding the-local github.com/defenseunicorns/lula
flag. Modern code editors (and emacs 😉) can be configured to do this automatically on save and the linters in #742 include goimports and gofmt, so we'll get errors (non-blocking - FOR NOW) if folks forget to sort imports.There is one annoying recurring issue with the go import sorting - something which I've already fixed in a couple of files, so it's not specific to the local package sorting, but (especially when refactoring) sometimes you'll end up with extra newlines between blocks of imports that need to be manually removed. Neither goimports nor gofmt catch that because it's something we could validly and explicitly do - we could for e.g. also have a block of non-lula defense unicorns packages (not a recommendation). But it can get annoying and I wanted to be open about that.
The following is just way too much explanation no one asked for, why did I write this, i don't know 🤷🏻
Here's a sneak peak at the before and after (in case anyone is still on the fence and wants to see):
vs
While I do absolutely admit to a generic sorting bias, I find the bottom example easier to read and I can get an idea of what's happening in this file before reading the code in a way I could not do before.
I only have vscode config off the top off my head, but:
Vscode config reference (not actually very helpful): https://github.com/golang/vscode-go/wiki/advanced#formatting-code-and-organizing-imports
The actual addition to settings.json:
Or run goimports
The text was updated successfully, but these errors were encountered: