I define prototypes prior to calling the functions.
Does the order of the prototypes have to match the order of the functions in the code?
I'd like to sort the prototypes alphabetically, while I wouldn't care in which order they appear in the code.
I am after common or best practice.
There is no specific best practice in this regard.
The rest of this answer is primarily opinion based, and hence off topic for this site.
If you have classes it's common, but in no way required, universal or "bad" not to do, to group the public, private and protected methods together.
Really, group them in a way which makes sense for your program - related functions together. If you have so many methods / functions that they need a lot of organizing, split them into groups of related functionality - using classes or whatever.
Does the order of the prototypes have to match the order of the functions in the code?
No.
I'd like to sort the prototypes alphabetically, while I wouldn't care in which order they appear in the code.
You can do that. It would make the prototype easier to find, I suppose, however most editors these days have search functions.
I am after common or best practice.
Because the Arduino IDE automatically generates function prototypes the common practice is not to use them at all.
If you want to know best practice in general I suggest you ask on Stack Overflow.
Years ago I programmed Burroughs Medium Systems in BPL (Burroughs Programming Language), a language similar to Algol (which Pascal looks a bit like).
In BPL you could not use a function or variable which had not been previously defined. Thus, the "main" function would always appear at the end of the source file. Major functions (called by the main function) would therefore precede it, and minor functions would appear earlier again. Thus you could tell the hierarchy of function calls, roughly, by the order in which the functions appeared.
In C (and C++) you don't need function prototypes if you have all your code in a single file, and if you follow that convention. Put the main code at the end and the things it calls before them. You only need function prototypes then in unusual cases where A might call B but B might call A.
