The Old Joel on Software Forum: Part 4 (of 5) - Books on structuring procedural code

Books on structuring procedural code

I've never had any major problems with OO concepts. I my first non trivial program was OO and it has always seemed quite natural to me.

From time to time I give game programming a go. Usually in plain C or BASIC. What happends is usually this:
I get to about a 1000 loc and all of a sudden my code is a mess. I think about it and realize that I need a generic event buffer in global scope and a big ass switch statment in the main loop.
I rewrite and get to about 1000 loc and now something else causes my code become spaghetti. I relize I need to make an abstraction layer for the screen rendering and rewrites again.

Now, Im pretty sure Im not the first to make these discoveries so there must be good books and online texts out there!

Can anyone recommend something on how to structure and manage procedural code?

Eric DeBois
Saturday, February 7, 2004

...With regards to games in particular... best practices and stuff like that...

Thanks

Eric DeBois
Saturday, February 7, 2004

I'd say _Code Complete_ (the original edition, I haven't read the second), and _Refactoring_ (which is about refactoring OOD but is applicable to procedural code too).

Is there any difference between OOP and procedural code? For example, consider the C library functions which take a "FILE*" parameter: they're procedures, but there's an obvious mapping from them to methods of a "File" class. So if you can do OOD, then can't you design procedural code similarly?

> generic event buffer in global scope

... singleton ...

> big ass switch statment in the main loop

... dispatching ...

> an abstraction layer for the screen rendering

... which OO analysis would have predicted.

Christopher Wells
Saturday, February 7, 2004

The key to procedural code is to recognize when to make a procedure.

If you switch statements look like this:

switch (variable)
{
case 1:
if (this || that)
{

}
else
{

}
.
.
.
case 2:
}

Then you obviously need to make logical functions for each case:

switch(variable)
{
case 1: DoGraphics(); break;
case 2: DoAI(); break;
}

It's a matter of experience to recognize these functions and the general order they should be called. It's also a matter of experience to be able to know what functions are generally required. Procedural programming requires a lot of refactoring, reworking and experience but if done right your program will be simple to follow, easy to read and extensible.

l33t h4x0r
Saturday, February 7, 2004

Command Pattern

Saturday, February 7, 2004

Eric,

Just to clarify - are you ok writing OO programs but not procedural over 1000 LOC? Or are you ok as long as its not games code? Or are having a problem with all code over 1000LOC?

Trying to ascertain if this is a question about architicting large programs or a question about architecting large game programs, and if so which sorts (3d shooter, 2d sprites...)

Dennis Atkins
Saturday, February 7, 2004

Because I am assuming when you use 'procedural' and 'oo' that you are intentionally distinguishing between the two - they are different.

I am also assuming that for some reason you have decided to use procedural and not OO technicques for your game design, and I am assuming when you say 'I am comfortable with OO', that you are expert at refactoring and design patterns and are rejecting these techniques in favor of procedural methods for some reason on this particular game project.

Dennis Atkins
Saturday, February 7, 2004

I have no problems with writing larger OO apps, though I wouldnt call my self an expert. I have no procedural programming experience to speak of (neither games nor apps).
The programming Ive done has always been data oriented and the approaches that seem logical to me fail when I try to write games. It all turns to spaghetti.

My reasons for wanting to learn how to do stuff in a purly procedural fashion are mainly that most games seem to be written that way. Tutorials and books etc assume it. And besides, Id like to know wtf Im missing here.
Problem is that the books ive read so far doesnt adress game development or procedural development from a larger scope. So thats where this thread comes in.

I've been meaning to read code complete for ages, maybe its time I got to it.

Eric DeBois
Saturday, February 7, 2004

"...most games seem to be written that way"

Hardly. I knew a guy who worked in a game company at that time (circa 1999), and they were entirely C++ shop, with heavy use of OO.

Egor Shipovalov
Saturday, February 7, 2004

Maybe there is a theory about it, but my idea
of "structuring procedural code" would come to this:

- organize data into structures,
- use pointers to functions (put them into structs to).

And do it all the time.

So when you are going into new territory and when you're
not completely sure how things would evolve, delay details
by calling functions that do net exist just jet. Then when you
know what are you doing, move repeating code into
separate procs. If there is a need for variations for specific instances of the task, supply pointers to functions
and that would be all to it.

If you can find Andre LaMothe's book Tricks of The Windows
Game Programming Gurus, look for Appendix D: C++ Primer.
On 20 pages he explains C++ to C programmers and I think
you could use that, but in reverse.

And one final idea: restrict yourself to never use any OS
API call more than once. It may sound strange, but if you
can keep to that 90% of the time (aside from SetRect() and
other things you could write yourself) it would prevent
turning your code into spaghetti and as a side effect it'll
become portable as I am discovering myself lately.

VPC
Saturday, February 7, 2004

Eric, books are written that way because the only people who write books on game programming are the ones who aren't very good.

I've designed games since 1994 using strong OO principles.

Maybe you're just not a top notch engineer?

Game programmer
Sunday, February 8, 2004

Actually, Eric seems bright to me. Game programmer, name three games you've worked on and your role in their development. Thanks.

Dennis Atkins
Monday, February 9, 2004

Eric,

Are you actually designing things before you code?

I don't mean formal UML and all that stuff, but at least some kind of box-and-arrows scribbling on paper.

OO sort of forces an amount of design on you even if you don't deliberately do it before coding, because of the way you have to name the classes and decide what goes into which class. But when it's a large procedural program, it's like one big sea of nebulous stuff unless you deliberately sit down and design it first.

T. Norman
Monday, February 9, 2004

"Maybe you're not a top-notch programmer"
is an idiotic comment. Objects suck and are
slow.

You cannot afford any part of a game to be
unnecessarily slow, though speed might not
have mattered so much for a business
application.

So much for speed. Objects also suck because
they result in very poorly engineered software,
because they multiply the dependencies throughout
the code via inheritance.

The point of software engineering is to reduce the
dependencies in your code so it becomes trivial to
prove correct and maintain. So what you want is
abstraction, modularity and encapsulation, and no
inheritance.

Plain old modular programming (e.g. Turbo Pascal,
any Basic actually in use, Ada, any functional
language) gives you these features, and there
have been standard textbooks around for decades
explaining how to program in modular fashion
e.g. through stepwise refinement.

Go look in the local library catalog for titles like
"introduction to programming in Modula 2".

A
Monday, February 9, 2004