#### Archived

This topic is now archived and is closed to further replies.

# ...too.......much.......code.......can't.....concentrate...

This topic is 6011 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''ve come upon an unanticipated problem as my largest program written nears completion. What''s depressing is that my largest program written is about a thousandth the size of your average Useful or Fun program. My general question is... without referring to c++ classes or general OOP - How on Earth does one write a 60,000 line program?

##### Share on other sites
One line at a time

The trick is to separate it into different parts that need completing, and doing each part separately. How you do that is entirely up to you - it can range from simple structured programming, to OO, to full-fledged component-based programming.

The project I''m currently working on professionally has reached about 200.000 lines of code, of which the part that I''m doing takes up a significant amount (20-30.000 lines I think). Its perfectly possible to manage this, as long as you stay organised and focused.

##### Share on other sites
I make notes. If I know that there''s something I''m not going to remember in 2 months when I have to tweak this code again, I make comments as to why I did what I did in the code (especially if it''s something kind of odd). Listen well, fledgling coders... comments will save your life when you have 4 hours to get a patch out on something you haven''t even looked at in 3 months.

I also keep diagrams of my hierarchies and how they interact and what files correspond to what areas, for quick reference. For instance, currently on my bulletin board is a copy of my current project''s hierarchical setup, which basically has 5 data hierarchies with some overlap and 4 or 5 layers per hierarchy, which spawn 4 subhierarchies for graphical use (speed reasons). I have the class name for each layer listed, the type enum (they all derive from the same base class to allow me to cast back up after generic message processing using just the pointer) for each layer, and the file for each hierarchy listed. This helps a lot, because though I can hold the concept of what I''m doing, there''s no way I''m going to remember all those class names, files, and enums, and rather than searching I just have to glance to the right and I have it.

-fel

##### Share on other sites
For me the biggest problem is the "reflection" effect.. when you change something it affects to other parts, and they in turn can affect.. etc.. it''s annoying to write code again and again.

##### Share on other sites
Try to keep functions to less than 100 lines. If it grows beyond that, you need to split it up into separate functions.

Comment, comment, comment.

Like the others said, organize your code into a hierarchy. I find it most useful to have a good awareness of the way different parts of your code communicate, what are the different interfaces.

Only put in the header files what other modules need to operate on the given module. Do not put every function and all constants in the header. Keep everything as hidden (file-local scope) as possible so that each interface has only what it needs to operate.

##### Share on other sites
Do you mean that you''ve only written 60 lines of code? (= 60,000 / 1000)

In my experience (around 10-20k lines for personal projects, around 50k for work projects), it really makes no difference if you''re using objects or not. The question is whether files are tightly or loosely coupled; the more two files interact with each other, the more work you''ll have to do with file B each time you work on file A. So hierarchies are good, but the crucial thing is that your file hierarchy doesn''t represent "inheritence" or whatever, but groups of related functionality.

##### Share on other sites
Also, what''s the accepted way of measuring lines? My own method is to measure only NON-COMMENT lines. I''ve seen some people be stricter (they don''t count lines that are just "}", for example), and others who count comments or even blank lines! It makes a big difference, especially when you read statistics such as that Europeans produce more lines per hour than Americans (could it be because Europeans more fond of putting the opening brace on the following line, whereas most Americans seem to prefer putting the open brace at the end of lines?)

##### Share on other sites
Comment well. Because you will forget what each function does when you have thousands of them.

Plan ahead on paper.

Use meaningful and memorable naming conventions.

Split your code into separate files, also with meaningful names.

Use as few global functions and variables as possible. This means you have less to remember.

##### Share on other sites
It is all about the design and not about the coding so much when you get to that point.

First you will need to decide which methodology you are going to use to design your application. Is it going to be structured (C) or object-oriented (C++). There really is no correct general-purpose organizational scheme. You have to put things where they fit.

If it is structured you probably want flowcharts and entity-relationship diagrams, data dictionaries, etc...

If it is object-oriented you probably want to use a class hierarchy diagram (yes you want it to be organized in order of inheritance with notation for containment), object-property/interaction diagrams and class dictionaries.

If it is really complex and you have alot of tricky algorithms you might want to think about writing Psuedo-Code with standard mathematical formulas as well.

Just make sure anytime you make a significant change to your code that you update your documentation nso nothing gets lost between the cracks. This is assuming that you don''t beat out the design 100% before starting the project (unless you have a team of designers on a large project that is probably not a realistic option).

But you don''t necessarily have to stick with one set of tools. Use whatever is to your advantage and whatever seems to fit properly. You can mix object-oriented and structured design to an extent as long as you understand and define where the line is drawn.

Seeya
Krippy

##### Share on other sites
I love VC++ for that... I like the way it structures the files and when you add a new class, it automatically makes a new .cpp and .h file.. (I sometimes stick 2 classes in one .cpp/.h pair though..). I don''t do strictly OO nor do I do Structed programming.. I just mix it.. I''ve got global function just as well... It really depends on what you need.. somethimes global functions just seem to fit better to the design. My current (and first) project is something like 25k lines (46 .cpp / 48 .h). I guess it''ll end up somewhere at like 50k maybe 60k, that''s just a guess... could end at a 100 k too, who knows :o)
I count all of the lines, wheter they''re just "}" or even empty.. I go down to the botteom of each file and look what line it is.. I don''t need and I don''t have the time to count them soo precisley :O)

cya,
Phil

Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states

##### Share on other sites
That leads to another thing I was wondering about - being that global variables and function were mentioned. With DX (especially games), is it generally accepted that you can use lots of globals? I heard it was, but geese, what a mess!

I think general planning and tighter function/file interaction is what I really need to work on. Previously, I''d just sit down and start writing a new program as it came. For example, in my game, I have a lot of objects flying around - spaceships, asteroids, bullets, etc. What I would''ve seen had I planned was that they all have a lot in common - position, velocity, physical properties, size, etc. So now I have about 10 different classes, each of which is about 50% identical to the other classes. There''s obvious room for improvement there!

Thanks for all the advice - will be much heeded!

##### Share on other sites
Get yerself some teammates.

Funny anecdote about how never to comment, from one of Ultima Underworld''s developers:
http://www.dfan.org/writing/comment.html
And another anecdote on a similar topic:
http://www.dfan.org/writing/coding.html

##### Share on other sites
quote:
Original post by Verso
That leads to another thing I was wondering about - being that global variables and function were mentioned. With DX (especially games), is it generally accepted that you can use lots of globals? I heard it was, but geese, what a mess!

No, it''s not generally accepted Sometimes examples use globals just to show more easily how something works. But you never need globals really. My current game has just 1 global: and that is ''int main()''.

The fewer globals you have, the cleaner your code gets. The extra effort you spend in putting things in neat little modules and sections is repaid several times over when your code is so much easier to read.

quote:

I think general planning and tighter function/file interaction is what I really need to work on. Previously, I''d just sit down and start writing a new program as it came.

I''ll be honest with you: that''s how I go along too. At least to begin with. I start with 1 file, often with the main() function doing everything... initialising the graphics, drawing the map, and shutting it all down. Then, I clean it up as I go along, before it has a chance to get unwieldy. If I find myself doing something twice, I make it into a function. If I find 2 things having similar properties, I invent a class to contain those properties. If I find 2 classes being similar, but not exactly, I move information into a single base class. If a function operates mainly on a class, I make it into a class member function. If I find myself using a number more than once in the same context, I make it into a constant. And so on.

The benefit of my approach is that I start off with something working, and keep refining it as I go along. This is a nice compromise between the "Everything is a global variable and the code is a repetitive mess" and the "I have 100 classes in my hierarchy, but I''ll never finish implementing them" camps. Of course, my method doesn''t escape the need to learn good design habits: I have to be able to recognise what makes a good class, what features are good candidates to go into the base classes, and so on. And this recognition has to happen early, or you lose the benefits.

For example, if I was doing your game, I might have started off with a Spaceship class, and tweaked that until I got it working, moving across the screen, and so on. Then when it came to adding an Asteroid class, I would think "hmm, lots of stuff shared here with Spaceships. Maybe I can factor it out into a base class." So I''d make a SpaceObject class or something, and move the position, velocity, size etc from SpaceShip and into SpaceObject. Then I just make sure that SpaceShip and Asteroid both derive from SpaceObject. This way, I''ve implemented 90% of Asteroid using existing working code, SpaceShip still works just as before, and I''ve drastically cut down the time it will take for me to develop a Bullet or Projectile class in the future. Rather than a ''top-down'' or ''bottom-up'' approach, this is more of an ''outside-in'' design! I start with bottom-up, then shift to top-down whenever possible. For me personally, it provides a good compromise between quick prototyping of technology and effective design considerations and frameworks.

Good luck with the game, anyway!

##### Share on other sites
quote:
Original post by GayleSaver
Funny anecdote about how never to comment, from one of Ultima Underworld''s developers:
http://www.dfan.org/writing/comment.html
And another anecdote on a similar topic:
http://www.dfan.org/writing/coding.html

LOL!!! Oh, those were great, especially the second one. I can never get enough funny coding stories.

My favorite piece of code (that I didn''t write) in a multi-threaded windows MFC app, the "OnClose" message handler:

  // exit gracefullyexit (1);

##### Share on other sites
I think just having lots of "modules" in files like graphics.c, input.c keeps it managable. Currently I''m on about 10,000 lines.

What I''ve found though is that most of making a game seems to be just loads of list managment, like textures, entities, sounds, bla bla... and it''s all pretty much the same for each.

Am I missing out here or is this what it really is?

##### Share on other sites
Yea, coding stories are the best^^
I need to make my engine less boring. I always use error messages like "Function() failed". Here''s one (sorta) funny clip I wrote a long time ago though:
switch(dxType)
{
case ''d'':
MessageBox(hwnd, "Direct Draw init screwed up.", TITLE, MB_OK);
case ''i'':
MessageBox(hwnd, "Direct Input init went to hell.", TITLE, MB_OK);

And another (even less funny) one (both of there are from when I was first learning DirectX from the MSDNtutorials):

char szFrontMsg[] = "Front buffer: I''m better than you. (F12 to exit)";
char szBackMsg[] = "Back buffer: I ''da bak buffa'' (F12 to exit)";

And on the original topic, I just checked and my current project is at 5094 lines (including blank ones), and now it seems insignificant. Especially cause about 1000 of those are ASM, which, if I didn''t have multiple copies of functions to do slightly different things, would probably be more like 200, which written in C++ would probably fit into 100. Oh well. Basically the way I keep it under control is to make a bunch of files, and group related classes into them (like, tiles, layers, and maps all have to have eachother to work, so they go together). Then give each class a bunch of functions (usually an Init, UpdateFrame, Cleanup and whatever else is needed), only use globals for things like setting up the program, the main UpdateFrame function, the active map (it''s easier than passing a pointer all the time), and the video/input/sound control objects.
I don''t think it''s really that great of a style though, especially since I rarely comment, and do things the fastest way I can, not the easiest to read.

Anyway, good luck on getting your project in order. If it gets too confusing, try to reorganize everything into seperate files, but don''t actually do anything until you''ve though about it first or you''ll end up going around in circles trying to decide where to put something^_^

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

##### Share on other sites
Just to quickly fill in to DekuTree64''s reply, I played Dune 2000 with my brother over DCC. Then suddenly the thing bombed out showing "xxxxxxx.cpp" at the title and the error message states "Error ### - Unit doesn''t know it''s a unit". Man I cracked myself for 10 minutes. Well you''ve got to admit, it was funny.

Actually that hierarchy stuff, when you draw it on paper (or write, whatever), does it look like a tree (You know, the main node with the branch nodes, etc.) or do you just write the code descriptions?

I''m just a bit interrested in what you guys said about all those lines of code and all that confusement. Well will some one please explain it to me some time (just for the interresting fact of hierarchies. Who knows if I''ll be living on it to use it.)

------------------------------
-Last Attacker
ICQ: 120585863
E-mail: laextr@icqmail.com

##### Share on other sites
Well you want to draw your heirarchy as a tree, and probably have class descriptions seperate. Just use the name of the class in your heirarchy and show which are your base classes and which classes are derived from them. If it provides no other benefit to you, atleast you have all of your classes listed in one place so you don''t have to knock your head to remember what you named that class that you haven''t used in a couple of weeks, they are all in one document.

Then you can create the individual class documents. Here you list the public data and methods and show which classes interact with which other classes and which methods they use.

If you have groups of classes which are designed primarily to interact with each other, then you can draw them all on the same document and use line-arrows from class to class to show the relationship. You can break this down to multiple levels.

If you want to get really into it, you can then create a class dictionary for each class. This will describe everything about the class. You will have a seperate page for each member variable and method. You will describe it''s purpose in life, what it does exactly (if it''s a method), the data type, min-max values, how often you expect to use the member, etc...

In my experience this is mostly only done religiously on large mission-critical applications. Just mix and match whatever works best for you Despite Booch and everything else, OOD is still in it''s infancy and nobody can say what is the ''best method''.

But any design documents are better than no design documents

Seeya
Krippy

##### Share on other sites
I actually wrote a console application that allowed me to enter in all my project source files and it counted the number of lines and gave the option to exclude comments and space. It also gave line percentages of comments used, function calls, etc. Don''t know why I made it, just got bored one night. Pretty cool to see the exact size of my projects though.

• ### Forum Statistics

• Total Topics
628707
• Total Posts
2984310

• 23
• 10
• 9
• 13
• 13