C is a subset of C++

Hahahaha... careful, never say that aloud without looking over your shoulder first. You risk being burned at the stake by two angry mobs

But yes, I agree that this was likely the reason for several design decisions (including this one) a long, long time ago when C++ was C with classes.

Hahahaha... careful, never say that aloud without looking over your shoulder first. You risk being burned at the stake by two angry mobs

Then they would have to burn Bjarne Stroustrup at the stake too as he still says that in his recent edition of The C++ Programming Language. :P

Hahahaha... careful, never say that aloud without looking over your shoulder first. You risk being burned at the stake by two angry mobs

Then they would have to burn Bjarne Stroustrup at the stake too as he still says that in his recent edition of The C++ Programming Language.

It does say "with minor exceptions", though... which I guess is true, even if I don't personally consider them minor.

For me:

1. Using declarations
2. Private typedefs
3. Private enumerations
4. Private constants
5. Private classes
6. Public typedefs
7. Public enumerations
8. Public constants
9. Public classes
10. Private member variables
11. Public member variables
12. Private member functions (ctors, dtors, assignments, modifying functions, status functions, comparison functions)
13. Public member functions (ctors, dtors, assignments, modifying functions, status functions, comparison functions)
14. Friend declarations
15. Free function operator overloads for class and class members (outside of class)

I prefer to not have ambiguity: it keeps me from having to wonder.

As for why... I am not sure. I feel that types are first. For functions, I read documentation, but for types, I feel that gleaning the header file is more likely, since there are few parameters or other such intricacies, unlike with functions. So, using declarations and types at the top. I put member variables in the middle, before functions; chances are, you aren't supposed to pay attention to those, so having them in the center, while types and the interface are on the extremeties, makes sense to me, and because of the old C (and other languagues') paradigm of putting variables at the top of the block, before everything. I feel that private should go before public, because of the default member access of classes, and habit. I sort member functions by their purpose, as noted above. Free functions generally go last, due to reliance on types declared earlier in the translation unit.

I also sort type and variable declarations.

...What?

I generally will place private before public. For me it just makes more sense to do it that way.

Hmmm... my C# style does not fit into either category neatly.

I do:

- Fields
- Properties
- Constructors
- Methods
- Explicit interface implementations

(I don't sort any of them by access modifier)

Same kindda

- const

- fields (that have no related properties)

- properties and fields, with collections and generics first

- delegates and event handlers

- constructors

- event methods

- methods organised by #regions based on interface

- and if destructors are needed it goes together with the disposer method (not property) in a #region at the bottom

Although I doubt this is common practice, to keep statics (when necessary) separate I make use of partial keeping statics separate but in the same partial class.

As for C++ it is straight up bottom

Since I prefer coding constructor forced (defined) objects , for security production reasons, I put public stuff first as I put constructor first. Though it bothers me becouse primarily I develop private members as a developer of the class, the public members are rather frequented by others, not by me who designs the class. A header file with private stuff being first also does me good (do not know why though). But I stick to bottom, since it is common coding culture and better for users of my code (though I doubt this too)

I think my code is generally ordered/grouped by relevance to surrounding code. This means that I pretty much have to use IDE tools to locate a method/field/whatever, but once I do I can usually find helpers and nested calls right next to it, helping me to avoid jumping around alot when reading code. Public/private has no impact on my ordering.

I tend to organize my classes not so much in terms of visibility, but in terms of complexity. Fields both public and private go at the top. Then properties or any relevant getters/setters (when I use them) go next, because they generally don't do much except set or retrieve the fields. Then the constructors, destructors, and other boiler-plate like copy-constructors, move constructors, etc. THEN methods, arranged by length and importance. Important methods go first, while long methods come last. Also, if I'm adding something new to a class, the new methods go at the bottom, new fields go at the bottom of the field list, etc. Within each of these categories, I tend to put public things before protected before private, but I'm not picky on that particular front.

The reason for this is that often-times I'll spend most of my work in the longer and more complex methods, and they become easier to find when they're at the bottom - since I just have to scroll to the bottom to find the thing I'm working on. Of course, that isn't as big of a deal with IDE code navigation help, but it lets me get a sense by looking at the code file where complicated things are.

public class MagicalGirl {
    private Top boobs;
    public Top grab(){
        return boobs;
    }
    
    private Bottom datAss;
    public Bottom grep(String g){
        int count = 0;
        while (g.contains("jizz")){
            count++;
        }
        return datAss.stack().get(count);
    }

    public void setBottom(Bottom huge){
        datAss = huge;
    }
}

I have to say, it's a hard decision.