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

[Sean Wolfe <ether.joe@xxxxxxxxx>]

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 <geometrian@xxxxxxxxx> wrote:
> 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.
> 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