7 Answers
7

Near "StrapIn" because it's related. That way if you refactor later, all related code is nearby.

Most code editors allow you to browse method names alphabetically in another pane, so organizing your code functionally makes sense within the actual code itself. Group functional methods together, makes life easier when navigating through the class.

Agreed, +1 to balance equation (IMHO it's worse than useless to down-vote without comment) and what you say does makes sense.
–
si618Jun 18 '09 at 6:14

(FYI previously I had more of an answer like "members at the top, then constructors, then public static, then private static, then private static final, then private public static final const, etc." ... but then the entire question changed.)
–
razzedJun 18 '09 at 6:19

Like razzed I use the "related to" criteria to group the methods or properties of a class, adding regions to do the code more accessible. Visual studio and many other IDE environments let you view the functions and methods alphabetically sorted in additional panels, so there is no need to alphabetically sort the code of your class, while grouping the code in related regions give you a more clear view of what a class do and where to find what you are looking for.
–
DoliverasJun 18 '09 at 7:05

Member variables at the top
To see what member variables exist and if they are initialised.

Constructors
To see if the member variables are setup/initialised as well as what are all the construction options for the class.

Destructor
To see the how the class is cleaned up and verify it with the constructors and member variables.

Public methods
To see what are the available contracts callers of the object can use.

Protected methods
To see what inherited classes would be using.

Private methods
As it's information about the internals of the class if you needed to know about the internals you can just scroll straight to the end quickly. But to know the interface for the class it's all at the start.

UPDATE - Based on OP's update
Logically a good way would be to organise the methods by categories of what they do.
This way you get the readabilty of categorising your methods as well as the alphabetical search from you IDE (provided this is in your IDE).

However in a practical sense I think placing the methods at the end of that section is the best way. It would be quite hard to continually police where each method goes, as it's subjective, for every method if the code is shared by more than yourself.

If you were to make this a standard it'd be quite hard to provide the boundaries for where to put each method.

Generally, it depends on the existing grouping; if there's an existing grouping that the new method fits into, I'll put it there. For example, if there's a grouping of operators, I'll put the new method with the operators if it's an operator.

Of course, if there is no good grouping, adding a method may suggest a new grouping; I treat that as an opportunity for refactoring, and try to regroup the existing operators where reasonable.

IMHO:
If you organize your methods alphabetically, put a new one depends on its name. Otherwise put it at the bottom of related group. This helps to know, what method is newer. The bigger problem is how to organize methods in groups, e.g. depend on what properties, but this is more individual for everyone and depends on a specific class.

Why would you ever need to know which method is newer. Don't you have source control for that? In two years, when someone is looking at the code, does it matter which method is two days younger than another?
–
NascarEdJun 19 '09 at 18:01