I appreciate the advice guys. OOP is definitely something I'm trying to leverage. I was thinking along the lines of OOP type patterns, best practices, etc... or even just general game programming. Especially if anybody has any favorite books! I heart good books.
Thanks for the responses so far! On Thu, Sep 1, 2011 at 9:13 PM, Ian Mallett <[email protected]> wrote: > On Thu, Sep 1, 2011 at 4:31 PM, NBarnes <[email protected]> wrote: >> >> The issue of code organization is one of the core challenges facing >> the modern programmer. Object Oriented Programming is a paradigm more >> or less explicitly dedicated to managing the level of complexity that >> a programmer has to understand to accomplish a discrete task. It does >> this by providing useful abstractions that allow large sections of the >> entire codebase to be understood at a level sufficient to work outside >> of them at a minimal cost to the programmer's brain. Modern >> applications (game and otherwise) are far too complex to hold in one's >> head all at once, no matter how able a programmer and designer one is. > > Yes, I remember being taught this. I also found it to be only party true. > My code is efficient, so no matter how big I need to make it, it literally > tends to take me about 1/4 the code of others. Also, I can hold a lot of > code in my head at once. I don't think that's unusual for a fairly > proficient programmer. Finally, even if I can't remember what and how > something works, a moment's thought tells me exactly how I did it--because > for a given design, there's the clean, good way to do it. >> >> So I would answer that the first step in fixing your problem is >> working on your grasp of object-oriented design principles. > > Personally, I think that "good coding" is an acquired skill. I can throw > terms at you, like "encapsulation" or "least privilege", but you really > don't know why those are good until you want code reuse/modularity, and a > clean, robust API, respectively. For me, anyway, I learned how to use these > even before I knew that they were official design patterns--if you know your > language, good code naturally follows from thinking about efficiency. > The good news is that these terms are easily available on the web. The bad > news is that you need to use all of them at some point before you get them. > Frankly, most universities ignore this fact. This is why dumb design > patterns get used in practice. My recommendation: do nothing different, > except, before starting something, think: "Hmmm, what could I do that would > make this more efficient? Is there any clever way I can use classes to make > this simpler? Inheritance? Insert _____ language feature?" Once you step > back from the problem like this, what to do becomes obvious, whether or not > you know just what it's called. It takes until upper division CS to even > touch on this--and even then they never say that as directly. > Ian -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
