Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


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.

  • You cannot reply to this topic
42 replies to this topic

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

Implementation:

  1. Top (31 votes [40.26%])

    Percentage of vote: 40.26%

  2. Bottom (46 votes [59.74%])

    Percentage of vote: 59.74%

Vote Guests cannot vote

#21 Kimiko   Members   -  Reputation: 123

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!


Sponsor:

#22 alnite   Crossbones+   -  Reputation: 2133

Posted 07 March 2014 - 11:24 AM

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



#23 Alessio1989   Members   -  Reputation: 2133

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 smile.png

 

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.

 

p14 http://www.stroustrup.com/hopl2.pdf


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

"Software does not run in a magical fairy aether powered by the fevered dreams of CS PhDs"


#24 BHXSpecter   Members   -  Reputation: 1675

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.


"Through vengence I was born.Through war I was trained.Through love I was found. Through death I was released. Through release I was given a purpose."


#25 Squared'D   Members   -  Reputation: 2258

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

 


#26 BHXSpecter   Members   -  Reputation: 1675

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

      void add_year(int n);                  // add n years
      void add_month(int n);                 // add n months
      void add_day(int n);                   // add n days
};

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.

"Through vengence I was born.Through war I was trained.Through love I was found. Through death I was released. Through release I was given a purpose."


#27 samoth   Crossbones+   -  Reputation: 5037

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 smile.png

 

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.


#28 Bacterius   Crossbones+   -  Reputation: 9289

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.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#29 samoth   Crossbones+   -  Reputation: 5037

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.



#30 BHXSpecter   Members   -  Reputation: 1675

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.


"Through vengence I was born.Through war I was trained.Through love I was found. Through death I was released. Through release I was given a purpose."


#31 samoth   Crossbones+   -  Reputation: 5037

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  biggrin.png

 

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.



#32 BHXSpecter   Members   -  Reputation: 1675

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. :P


"Through vengence I was born.Through war I was trained.Through love I was found. Through death I was released. Through release I was given a purpose."


#33 Bacterius   Crossbones+   -  Reputation: 9289

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. tongue.png

 

 

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


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#34 Ectara   Crossbones+   -  Reputation: 3061

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.


#35 Gandri25   Members   -  Reputation: 145

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.



#36 Memories are Better   Prime Members   -  Reputation: 769

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.


#37 JohnnyCode   Members   -  Reputation: 311

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)



#38 DvDmanDT   GDNet+   -  Reputation: 996

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.



#39 Oberon_Command   Crossbones+   -  Reputation: 1973

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.


#40 tom_mai78101   Members   -  Reputation: 577

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.



PARTNERS