[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] recommended reading for organizing code / project

On Thu, Sep 1, 2011 at 4:31 PM, NBarnes <nbarnes@xxxxxxxxx> 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.