...too.......much.......code.......can't.....concentrate...
Author
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?
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.
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.
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
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
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.
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.
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.
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.
I might be an eccentric in this, but I like to grow my headers with my program. Start with one "globals.h" -- fine. After 5000 lines, break by modules "graphics.h", "sound.h", etc. Above 15,000 lines, I prefer if at all possible to have separate project files (producing static libraries or DLLs if it''s C/C++; producing JARs if we''re talking about Java). To me, the extra work of redoing the header files is not as bad as working with headers that are too few *or too many*. This also means your headers will expand naturally to fit your code, because unless you''re very experienced with the kind of program you intend to build, you''re not going to know beforehand how best to structure the headers even if you have diagrammed it all out.
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.
I might be an eccentric in this, but I like to grow my headers with my program. Start with one "globals.h" -- fine. After 5000 lines, break by modules "graphics.h", "sound.h", etc. Above 15,000 lines, I prefer if at all possible to have separate project files (producing static libraries or DLLs if it''s C/C++; producing JARs if we''re talking about Java). To me, the extra work of redoing the header files is not as bad as working with headers that are too few *or too many*. This also means your headers will expand naturally to fit your code, because unless you''re very experienced with the kind of program you intend to build, you''re not going to know beforehand how best to structure the headers even if you have diagrammed it all out.
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?)
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.
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.
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
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
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
