Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I always hear things about that each method should only do one job. But lets say I got Update() method in my game that updates entities state, path finding, player position, etc. Should I refactor that method into separate methods like UpdateAI(); UpdatePlayer(); UpdateWorld(), etc.? I know that mostly it depends on me, but I want to know the best practice.

share|improve this question
3  
Yeah that rule is more or less something taught to beginner programmers. While it sounds smart in terms of writing scripts the fact is in real programs there is a lot to do. I find it's better to interpret "One job per method" as "keep it short and make calls to other methods when appropriate". –  Benjamin Danger Johnson May 9 '13 at 23:15
    
A key concept is how concisely you can describe everything a particular method does in its name. When the name runs to more than 5 or 6 syllables, consider making it two methods. –  Pieter Geerkens May 10 '13 at 2:33

1 Answer 1

up vote 7 down vote accepted

No. Regardless of whether or not that rule is sound you have to remember that "one job" can have different scopes. "Update" is one job - updating the (whole) logic of your application each frame. But this task consists of several smaller tasks, like the ones you mentioned - "updating AI", "updating player" and so on. They can, of course, consist of further subtasks. That's why you usually call some functions that do smaller tasks in another function that is responsible for a bigger task. (Of course, you can also have some additional code (not function calls) in that function, too.)

share|improve this answer
    
Thanks. Now I understand. –  Tom May 9 '13 at 23:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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