Alphabetical order seems pretty arbitrary and optimizing for the wrong thing in most cases.

The only reason as a dev you would really care about this is if you navigate / search code by scrolling until you find the function you care about. The invention of Ctrl+F makes this strategy of code navigation obsolete.

In my opinion ordering should be something along the lines of:

- initializer / constructors

- public functions from most commonly used to least common, with similar functions (perhaps with different inputs) being close to their relatives, and functions that call each other being close to each other

- deprecated public functions

- private functions following a similar ordering pattern to public ones, ordered by most used by the public functions to least used

I think doing secondary sorting within such sections might have a benefit. That’s what Java does for documentation (example: https://docs.oracle.com/javase/8/docs/api/java/util/Abstract...)

Going fully alphabetical is consistent with the go documentation, though (example: https://pkg.go.dev/bufio@go1.19.3)

A third option is what Rust does. Its documentation follows source code order (example: https://doc.rust-lang.org/std/vec/struct.Vec.html). I like that best, but it requires programmers to do more work.

Also, if alphabetical order is deemed the way to go, I would make this a formatter, not a linter.

> Going fully alphabetical is consistent with the go documentation, though

Nope, look how initializers are at the top of each section. That is not fully alphabetical at all.

The missing feature in an IDE to make this even better is to have LSP-aware regex tokens.

Let say something like /(?@<functionDef>)toErr/ that would match only the string "toErr" when it is in a function declaration/definition (decided by the LSP integration) rather than an invocation or a docstring

This is the sort of linter that almost certainly reduces productivity in the long run.

1. Spending minutes to reorganize funcs to be alphabetical (think, ci fails, commits, pipeline reruns), to save an extra second navigating the file is not a tradeoff I'd make.

2. `func NewThing() Thing` above `func (t Thing) DoStuff()` makes logical "order of operations" sense. We process code top to bottom. Not alphabetically

Blog post about this:

https://blog.steve.fi/alphabetical_linting___.html https://news.ycombinator.com/item?id=33461943

Most code structure outliners can sort the outline alphabetically, e.g. all the Jetbrains IDE. Why would you want to sacrifice logical grouping over alphabetical one?

I guess it depends on the kinda things you work on, and how you prefer to go.

Personally I tend to seperate things logically by using different files within packages - so I might have:

   foo/
   foo/maths.go
   foo/strings.go
   foo/logical.go

And then sort the implementation of each specific post. This is mentioned in the blog post linked within this thread - author here, though I wouldn't have considered submitting here.

But yes, IDEs do tend to give you an (alphabetical) tree, and personally I'd find it odd if the tree and the contents didn't match.

Why not both?

function coolThingWrap

function coolThingUnwrap

It doesn't always make sense but alphabetical ordering makes sense

But you have both for free with an idea that has an outliner that can sort alphabetically, if I was to look for function to "wrap cool thing", I would start looking at functions starting with "wrap".

Gross! NewXXXXXX and constructors should always be near the top of the file, next to the struct and interface definitions :)

does it mean my func main has to be in a middle of file if I'm just having a single file script? feels weird

Author here - suprised to see this posted - but no, "init" and "main" are excluded because that felt like a step too far.

I admit some people might find it a little bit weird to have to put "New" in the middle of a file though, as usually that would be found near/at the top.