Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've made a few games, and am getting faster and better organized each time. I'm well out of the "just make it work" phase and working on methodology and readability. I need some tips on code organization though.

I don't mean patterns - I'm having great success with MVC - but the organization of methods inside the classes themselves. I've noticed that methods in my state models can usually be grouped into four categories: (1)constructor/destructor, (2)data access (3)actions (4)events.

My controllers usually have c/d and input methods. My views usually have c/d, view updaters, and event listeners.

I feel like I'm reinventing the wheel though; someone must have spelled out "these are the common types of methods" somewhere before, right? Storage has Create, Read, Update and Delete (CRUD), so what are the equivalents for objects?

EDIT: Found some cocoa-specific advice here:

and some generic advice here:

I'm going to use that as a foundation, modified for game-specific stuff. More info still appreciated if you have any.

share|improve this question

closed as not constructive by Josh Petrie, Tetrad Jan 22 '12 at 20:48

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

This varies widely between projects from my experience. My biggest rule is to keep your code consistent. If you choose a particular style, make sure all the code follows that style.

As for a "CRUD" equivalent, I haven't seen one, although I like the idea of trying to come up with a unified model for this.

share|improve this answer
Thanks, I found a similar system to mine in the "Penumbra" source code - Actions, properties, callbacks, triggers etc. It's not a complete list but it's a start.… – smasher Jul 25 '10 at 16:17

This isn't language agnostic but things like stylecop help a bit here. It's not very helpful contextually, but at least everything is in a known place (Things like Public Properties after constructors, protected methods after public ones, etc.).

share|improve this answer

I stick to: Private (implicit), then public.

  • Creators (constructors and static named constructors)
  • Destructor
  • Blank line
  • Non-const methods
  • Blank line
  • Const methods

I'm a minimalist when it comes to formatting. I also don't mess with vertical alignment or whatever. If I need more than one public or private block, I refactor. If my methods are too long (names or parameters), I refactor. Etc. Everything must be as small and easy to read as is practical, but no more. :)

If there are enough methods on the class that I have to group them by functionality, as in:

    // Here are the XXX methods.
    // Here are the YYY methods.

then my class is probably doing too much. I recommend reading the book Clean Code by Robert Martin.

EDIT: Accidental tab-space submit >:(

share|improve this answer

If the class is longer than roughly one page of your editor, refactor it. I don't think the order of methods or members matter much, as long as they're grouped somewhat logical together.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.