• Create Account

## Top Or Bottom?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

42 replies to this topic

### Poll: Top Or Bottom? (77 member(s) have cast votes)

#### Implementation:

Percentage of vote: 40.26%

Percentage of vote: 59.74%

Vote Guests cannot vote

### #21Kimiko  Members

Posted 05 March 2014 - 04:39 PM

This could've been a very scary topic.. Or maybe it is already???

Check out Tabletop Simulator. No goats, but we have table flipping!

### #22alnite  Members

Posted 07 March 2014 - 11:24 AM

You mean if you prefer your privates on the top or bottom?

### #23Alessio1989  Members

Posted 09 March 2014 - 10:00 AM

Bottom for classes (first divided in public, protected and private, each of one in "bottom style" ie ctors, functions, inner classes/datastructures, consts, variables... static things before non static things)

Top for data structures (yes, sometimes I add some little functions to structures)

I like placing the private stuff first in classes, since that is the one thing that makes sense. Putting the public interface (or anything public) first is nonsensical.

A class is a struct where the members default to being private rather than public (in layman's wording, the standard's wording is slightly more elegant).

Therefore, if you write class and immediately follow with public: you are being nonsensical. You're the madman who puts salt on his bananas and throws them away because he doesn't like salted banana. I try not to write nonsensical code, if I can help it.

If one wants the public members first, one should write struct and declare the non-public members private. Of course nobody does that... so it's private stuff first

In C++ private as default class access modifier was a style choice with a solid reason, and not salt on banana:

Before starting work on C with Classes, I worked with operating systems. The notions of protection from the Cambridge CAP computer and similar systems – rather than any work in programming languages – inspired the C++ protection mechanisms. The class is the unit of protection and the fundamental rule is that you cannot grant yourself access to a class; only the declarations placed in the class declaration (supposedly by its owner) can grant access. By default, all information is private.

Edited by Alessio1989, 09 March 2014 - 10:13 AM.

"Recursion is the first step towards madness." - "Skeggǫld, Skálmǫld, Skildir ro Klofnir!"
Direct3D 12 quick reference: https://github.com/alessiot89/D3D12QuickRef/

### #24BHXSpecter  GDNet+

Posted 09 March 2014 - 10:25 PM

I do top because of the class being private by default. My method is to do private members on top, protected if I have any, public methods, followed by any operator overloading I'm doing and the constructors/destructors.

### #25Squared'D  Members

Posted 09 March 2014 - 11:36 PM

I generally put the interface at the top and private members and classes at the bottom because users of the class(including myself) shouldn't be bothered by the implementation so why make them wade through it before they get to what they need? Even when it comes to the interface, I put methods that will be used the most at the top.

That the default access in classes is private has never been a concern to me. I've always thought of it more as a reminder that member variables in classes should be private.

My head doesn't explode when others do the opposite way though.

Learn all about my current projects and watch some of the game development videos that I've made.

Squared Programming Home

New Personal Journal

### #26BHXSpecter  GDNet+

Posted 10 March 2014 - 08:12 AM

Reading his most recent version of his The C++ Programming Language book makes it look like Bjarne does top too. His first code from 16.2.3 Access Control:

class Date{
int d, m, y;
public:
void init(int dd, int mm, int yy);     // initialize

};


I don't know his reasoning behind it, but I do know mine. My reasoning is, since the default is private why change it to public just to turn around and make it private again.

Edited by BHXSpecter, 10 March 2014 - 08:12 AM.

### #27samoth  Members

Posted 10 March 2014 - 11:21 AM

In C++ private as default class access modifier was a style choice with a solid reason, and not salt on banana:

Well yes, exactly. that is what I'm saying. Hence the pittoresque example

When you write class foo, you are implicitly requesting from the compiler:

class foo
{
private:

The private: is implied, since that is what class is about (in contrast to struct).

If, on the other hand,  you put the private members first, you are requesting from the compiler:

class foo
{
private:
public:


It's legal, but absurd. Nonsensical, like putting salt on a banana and throwing it away. Or, like producing a 24k gold zippo and painting it black because you don't like gold (no kidding, one well-known designer actually did that in the 1980s...). You ask for private and immediately throw it away.

The logically correct thing (leaving protected out of consideration for simplicity) would be to either:

struct foo
{
// here be public stuff
private:
// blah
};

or

class foo
{
// here be private stuff
public:
// blah
};


Of course, "struct" does not sound nearly as cool as "class", so nobody uses struct (other than to bundle together 2-3 PODs without methods, maybe). But actually it would be the correct thing to do, if that is the behavior you want.

Edited by samoth, 10 March 2014 - 11:21 AM.

### #28Bacterius  Members

Posted 10 March 2014 - 01:54 PM

I don't know Samoth, I see your point but I would imagine most people don't use class or struct based on implicit accessibility (and go for the more traditional class = complex container with logic, struct = POD approach), so from that point of view it's not nonsensical at all, as the default accessibility doesn't factor into the decision either way, i.e. the programmer did not "ask for private/public", but for a struct or for a class. The fact that the language has some rules about what the default accessibility is is just irrelevant from that perspective.

To me this appears like a style decision, depending on how you interpret the more subtle parts of the language. In your case (the pedantic view, if you will) you prefer to honor the default accessibility settings. In the other case, the programmer prefers not to rely on them (or even know they exist at all) and to explicitly define his own accessibility fields, rearranging them to his liking. The final code is the same, and each style is equally correct "philosophically" from the corresponding perspective.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

### #29samoth  Members

Posted 10 March 2014 - 03:40 PM

Well, it sure isn't wrong to do one or the other.

Clearly, this is pretty much an opinion-based (or preference-based) decision. And yes, I certainly agree that the common understanding is that a class is rather the complex thing with built-in logic, and a struct is a few PODs tied together in one lump. Which is likely the reason (apart from the fact that "class" sounds more classy) why everybody writes class for classes (regardless of layout or accessibility).

Still, for some reason, Mr. Stroustrup decided that struct is public by default, and class is private by default. I wouldn't know his personal reasons for that decision, but it's apparently something that made sense in some context. Maybe he wanted to make everything private by default, but finally decided to leave struct as it was because C++ was just C with classes then. Or, something else, who knows.

Either way, as it stands, there's the way that I personally find "the correct way" due to these defaults, and there's the way that I personally find "nonsensical", since it does the exact opposite. That doesn't have to mean that my opinion is the only correct one, but it's how I feel about it.

In the end, like all languages, programming languages, too, are for expressing an intent, and as long as the compiler (and the people around you) understands what you want, it's fine.

### #30BHXSpecter  GDNet+

Posted 10 March 2014 - 04:26 PM

structs are public by default because that was most likely how they were in C and he just kept it in C++ since C is a subset of C++. He made classes private by default  because they were designed with data hiding in mind.That is what I was told in my programming class years ago.

### #31samoth  Members

Posted 10 March 2014 - 05:21 PM

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.

### #32BHXSpecter  GDNet+

Posted 10 March 2014 - 06:45 PM

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.

### #33Bacterius  Members

Posted 10 March 2014 - 06:47 PM

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.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

### #34Ectara  Members

Posted 10 March 2014 - 07:16 PM

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?

Edited by Ectara, 10 March 2014 - 08:24 PM.

### #35Gandri25  Members

Posted 03 April 2014 - 10:52 AM

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

### #36Memories are Better  Prime Members

Posted 04 April 2014 - 06:56 AM

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

Edited by Strix_Overflow, 04 April 2014 - 06:57 AM.

### #37JohnnyCode  Members

Posted 08 April 2014 - 09:34 AM

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)

### #38DvDmanDT  GDNet+

Posted 17 April 2014 - 05:54 AM

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.

### #39Oberon_Command  Members

Posted 18 April 2014 - 10:41 AM

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.

Edited by Oberon_Command, 18 April 2014 - 10:46 AM.

### #40asperatology  Members

Posted 19 April 2014 - 08:05 AM

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.

Edited by tom_mai78101, 19 April 2014 - 08:07 AM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.