4
\$\begingroup\$

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: http://www.mactech.com/articles/mactech/Vol.21/21.07/StyleForCocoa/

and some generic advice here: https://stackoverflow.com/questions/73045/whats-the-best-way-to-organize-code/73081#73081

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

\$\endgroup\$

4 Answers 4

Reset to default
3
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ 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. github.com/FrictionalGames/PenumbraOverture/blob/master/… \$\endgroup\$ Commented Jul 25, 2010 at 16:17
2
\$\begingroup\$

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.).

\$\endgroup\$
1
\$\begingroup\$

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:

... 
public:
    // 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 >:(

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.