[ryanseys]

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

[Someone]

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.

[jamesrom]

> 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.

[afiori]

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