Page 1 of 1
Order of class methods?
Posted: Sun Jun 28, 2009 3:26 pm
by kaisellgren
Sup pals
Out of curiosity, how do you order the methods of your classes? Do you just leave them in the order you wrote them, or do you order them alphabetically or based on the purpose of the methods?
Re: Order of class methods?
Posted: Sun Jun 28, 2009 4:25 pm
by omniuni
I order by function, and usually in the order that I use them in my page. Functions that are used first are listed first in the class, and then related functions. If there is a function used in another function, though, I put that above the function that it's used in.

Complicated?
Re: Order of class methods?
Posted: Sun Jun 28, 2009 9:28 pm
by Christopher
I just looked through the code of a couple projects and got this general order:
1. constructor
2. initialization
3. setters and getters
4. other public methods but there are setters mixed in
5. private / utility methods.
6. sometimes I see magic methods at the very bottom
Not sure why the order matters that much, other than properties and then the constructor at the top -- which is very standard.
Re: Order of class methods?
Posted: Mon Jun 29, 2009 3:21 am
by omniuni
1. constructor
2. initialization
3. setters and getters
4. other public methods but there are setters mixed in
5. private / utility methods.
6. sometimes I see magic methods at the very bottom
Forgot about the constructor, and the technical names. Since I usually initialize first, and since the magic stuff doesn't really fit in anywhere else, I tend to put them in the same places Arborint stated. Nice to know I'm not totally crazy.

Re: Order of class methods?
Posted: Mon Jun 29, 2009 6:26 am
by kaisellgren
Interesting. I have my constructors in the top, too, but some magics like toString are at the bottom for some reason... getters and setters are at the top, too. The rest of the methods, publics are above protected/private ones, but other than that, there is no rule of how do I order them.
arborint wrote:Not sure why the order matters that much
Well, it doesn't really matter to me, but it always makes me muse, because there is no clear logic other than the basics - e.g. if you have two public methods, they would be in random order which is illogical.

Re: Order of class methods?
Posted: Mon Jun 29, 2009 10:36 am
by alex.barylski
Well, it doesn't really matter to me, but it always makes me muse, because there is no clear logic other than the basics - e.g. if you have two public methods, they would be in random order which is illogical
I would say it does matter, in the sense that convention and consistency only serve to speed up your development efforts.
Re: Order of class methods?
Posted: Mon Jun 29, 2009 11:07 am
by kaisellgren
Maybe. I tried to look at Zend's developer zone for information, but came up with nothing. They want you to use null over NULL, but they don't care if you put __toString() in the top of the class while public attributes are in the end of the class (and having this order changing randomly between files)... which I find a bit odd. Perhaps I have missed something.
Re: Order of class methods?
Posted: Mon Jun 29, 2009 11:11 am
by pickle
Constructor, loaders, savers, magic.
Thinking about it, I think my methods are ordered with the methods that are most likely the reason the user is looking at the code, to the least likely. For example, if I've got a simple __get() that just returns private object variables, I'll put that at the bottom. If I do a bunch of fancy logic, and make __get() return values for variables that aren't object variables, I'll put that higher up. Similarly, I put my load() functions higher than, say, generateRandomString().
Re: Order of class methods?
Posted: Mon Jun 29, 2009 5:49 pm
by BornForCode
1. initialisation
2. constructor
3. public methods
4. getter/setter area
5. private/protected area
Usually when i open a class i'm interested by its public methods (in code analysis, debugging etc), that's why i put private and protected at the end (since many IDE's have the beautiful "Go to declaration" navigating to them is easy).