   Game Programming Practices
  I am wondering how many people use unit testing during their game development? Also, to what extent do you document and comment? (I consider documentation to be a description of a class or function/method and I like to think of a comment as something within the function describing any interesting/complex implementation details)Finally, do you create any type of design document that describes the architecture of your system and how the larger pieces fit together?I guess these questions are targeted more at larger team projects and not the single programmer working on a small project for a short period of time.   
  I am using unit testing relatively extensively. I've already caught a couple of regression bugs with typoes in complex matrix operations.I comment class definitions extensively and sprinkle other comments liberally in complex blocks of code. I try to keep functions very small so it's more obvious, but massive AI switch statements must be commented heavily.I generally do not create an overall design document, but after about 10 games all of my games are structured the same and so I just use the paradigms and tricks I've developed so far, though more design of new game pieces would probably serve me better.One thing you didn't mention, but should know: You should use source control. Subversion is excellent, CVS less so. Avoid Visual Sourcesafe!   ;  Yes - I've used both CVS and Subversion. I just started using Subversion recently and I definitely prefer it.What framework do you use for your unit tests?   ;  Tut.   ;  We're starting to use more and more unit testing, but only for new code - since a large part of our code is already stabilized (usually by hand and brute force) it isn't cost-effective to go back and rebuild everything to permit unit testing effectively. Anything new that goes into the source tree is unit tested if it is nontrivial or involves verifiable computations.Comments are used primarily to explain things that are not obvious from the code itself - we have a semi-unwritten rule not to express things in comments which would duplicate code information. This works fairly well in general, but we also use Doxygen to generate code documentation, so occasionally we have to violate the rule a tiny bit to keep Doxygen happy (hence the semi-unwritten nature of the rule [wink]).Aside from autogenerated docs from Doxygen, we have a project wiki (using the Confluence package, which I really, really like and can't rave about often enough). We use the wiki to store all architectural decisions, structural designs, data flow diagrams, etc. for various code systems. Again we have an informal rule against duplicating information that is best found in the code itself; only very high level stuff is put into the wiki. There's a lot of Visio diagram type stuff in there.Any major new piece of code is planned out and fully specified on paper. That spec is then uploaded into the wiki for reference, and to act as the "bible" if multiple programmers are working on the code in question.   ;Quote:Original post by RavuyaI try to keep functions very small so it's more obvious, but massive AI switch statements must be commented heavily.Although it's off on a tangent, why does your AI have massive switch statements?