views:

820

answers:

11

I'm not talking about how to indent here. I'm looking for suggestions about the best way of organizing the chunks of code in a source file.

Do you arrange methods alphabetically? In the order you wrote them? Thematically? In some kind of 'didactic' order?

What organizing principles do you follow? Why?

+3  A: 

i normally order by the following

  1. constructors
  2. destructors
  3. getters
  4. setters
  5. any 'magic' methods
  6. methods for changing the persisted state of reciever (save() etc)
  7. behaviors
  8. public helper methods
  9. private/protected helper methods
  10. anything else (although if there is anything else its normally a sign that some refactoring is necessary)
Marc Gear
Personally, I would have thought that none private getters and setters would be a sign that something was up. What do you mean by 'helper methods'?
pdcawley
I mean anything that helps another part of the API do its job, perhaps a method like getFullPath() which glued together properties of the object, but which isn't a vanilla getter.
Marc Gear
So... where do you put behaviours? The list of methods you give seem to be relevant to a value object, but not to anything that isn't going to be treated as a datastructure.
pdcawley
Well its a fairly generic structure that really just lists the order I put things. It certainly is more relevant to a value object - as I tend to use many more value objects than entities. Added behaviors to my list to clarify where I'd put them
Marc Gear
what are magic methods?
brian
'magic' methods are methods that have special behavior, that doesn't represent part of the objects API, but adds functionality - they are notoriously difficult to document and can make code disobey the rule that you should not 'do the unexpected'...
Marc Gear
An example is that in PHP there is a magic method __call() which if implements, will be called whenever a method which is not implemented in the class of the receiver or its parent classes is called.
Marc Gear
A: 

I group them based on what there doing, and then in the order I wrote them (alphabetically would probs be better though)

eg in texture.cpp I have:

//====(DE)CONSTRUCTOR====
...
//====LOAD FUNCTIONS====
...
//====SAVE FUNCTIONS====
...
//====RESOURCE MANGEMENT FUNCTIONS====
//(preventing multiple copies being loaded etc)
...
//====UTILL FUNCTIONS====
//getting texture details, etc
...
//====OVERLOADED OPERTORS====
....
Fire Lancer
A: 

Pretty much use this approach for anything I am coding in. Good structure and well commented code makes good reading

  • Global Variables
  • Functions
  • Main Body/Method
betelgeuce
A: 

public, protected and then private and within each section alphabetically although I often list constructor first and deconstructor last.

/Allan

Allan Wind
A: 

I tend to group things thematically for lack of a better word.

For example, if I had a public method that used two private methods in the course of doing its work then I would group all three together in the implementation file since odds are good that if you're going to be looking at one of them then you'll need to look at one of the others.

I also always group get/set methods for a particular class member.

It's really personal preference, especially with modern IDEs since there are a lot of features that allow you to automatically jump to locations in the code.

17 of 26
+1  A: 

I tend to group methods that relate to each other. Use of a good IDE removes much of this concern. Alphabetizing methods seems like a waste of effort to me.

David Smart
A: 

I like to keep things simple, so I don't stuff a bunch of methods in a class. Within a class, I usually have the most commonly used (or modified-by-me ;-)) methods listed first. As far as specific code organization goes, each set of methods belongs to a class, so it organizes by itself.

I make use of my editor's search feature, and code folding to navigate through large source files. Similarly, I make use of search features to find things in other contexts too. A grand organization scheme never suited me, so I rely on the power of search in all things, not just code.

jtimberman
A: 

Interesting point. I hadn't really thought about this.

I tend to put frequently-accessed functions at the top (utility functions, and such), as they're most likely need tweaking.

I don't think organization is particularly important, as I can find any function quickly. I don't scroll through my file to find a function; I search for it.

In C++, I do expect that the functions in the .cpp file are in the same order in which they're declared in the .h file. Which is usually constructors, followed by destructors, followed by primary/central functionality functions, followed by utility functions.

+2  A: 

I tend to use following pattern:

  • public static final variables
  • static functions, static blocks
  • variables
  • constructors
  • functions that do something related to logic
  • getters and setters (are uninteresing mostly so there is no need to read them)

I'm have no pattern of including local classes, and mostly I put them on top of first method that uses them.

I don't like separating methods depending on access level. If some public method uses some private method they will be close to one another.

jb
A: 

I mostly write C code and I tend to order by dependency. If possible I try to match my source code file with me header files, but generally it's if void a() uses int b(char *foo), than int b(char *foo) comes first.

Saves me from adding entries to the header file for local functions.

For the rest it's mainly alphabetic actually, makes searching easier.

Kristian
A: 

I have all the private fields, then the public, then the constructors, then the main, then the methods that main calls, in the order they are called.