How do you order your functions?

Uncle Bob says we should order our functions by abstraction level and I've found that I like that approach best, as the code reads like a book.

function doSomething() {
    readInput()
    writeOutput()
}

function readInput() { 
   lowLevelImplementation()
}

function writeOutput() {}

function lowLevelImplementation() {
    ...
}

I always declare first and call then later, like the following:

function second() {}

function first() {
  second();
}

Considering the second is a dependency from first, personally I think it's more readable.

There's something called as Stepdown rule when it comes to writing functions, here's an example:
dzone.com/articles/the-stepdown-rule
This is also suggested by uncle Bob in the clean code handbook.

I always order them like this:

function first(){
  second()
  third()
}

function fourth(){
  // Whatever
}

function second(){
  fourth()
}

function third(){
  // Whatever
}

In other words, I order them alphabetically. Granted, it looks a little strange in this example, because these function names seem to imply a specific order. But that's not the case in "real" code.

I hate having to scroll up-then-down-then-up again as I search for a given function. So I put everything in alphabetical order. I even wrote a whole article about this a little while back:

dev.to/bytebodger/sorting-code-alp...

Honestly, I think that if you do not have too many functions grouped together, the order does not matter.

The corollary being that if you care about the order of the functions, perhaps you have too many grouped together.

Perhaps the answer is to break them up into smaller, logical groups?

Classical functions declaration all at the bottom, including locals. Of course this seems to work only in Javascript.

Eslint standard does not complain, though.

BTW, why I see no semi yet in this thread? Which defaults do you all use?

I agree with your suggestion. "top to bottom" is much easier to read.

I rarely write code this way, however. I tend to group my functions around the domain they operate on, and then alphabetically, except where that causes linters to complain. I think you've managed to show me I need to rework my linter rules ;-)

Generally, however, I think lists of any programming token (functions, imports, parameters, members of an object/dictionary) are best entered in alphabetical order, when you work in a team. It's a very easy rule to remember and follow, and prevents wasted time during code review. It also supports how git works (line by line), so you have fewer conflicts when merging branches.

Clean Code suggests an awesome analogy imho of ordering functions like they are an article in a newspaper:

Most important statement up top, then comes the subheadline, then the first paragraph that tells you everything you need to know and then the gritty details.

So essentially order by abstraction layer as others suggested, enhanced by thinking about what the most important LOC in that file are that somebody opening this file needs to read first.

Use a language which does not even allow to use a value or function before declaration (i.e. the compiler yields an error) and structure the low-level internals into nested modules.

For instance in ReasonML:

module Something = {
  let readInput = () => ();
  let writeOutput = () => ();
};

let doSomething = () => {
  Something.readInput();
  Something.writeOutput();
};

This makes it also very easy to factor out the module into a separate file later, when the file at hand becomes too big, because a file in ReasonML is also just a module.

I've gotten used to structuring my code files so that helper functions go at the top and library functions then go at the bottom. Since I mostly code Lua, I can call any library function from any other, but with helper functions I don't really mind structuring them so the most low-level ones go on top.