Archived

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

Coding to Ease Large Project Maintainence

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Looking for tips and suggestions to ease maintainence of large projects.(Besides adding billions of comments!) I am working on a personal project which is currently reasonably small (< 10 files, ~650 loc) but is expected to grow to pretty large eventually. I am using C++ and coding for the Win32(using VC 6 SP4), Linux( GCC 2.9/3) and unfortunately MSDOS(don''t ask). So the idea is to ensure portability and ease of maintainence.(piece of cake!) Now, for this project, I need the entire gamut of data sizes i.e. 8,16,32 and 64 bit unsigned data types. This is provided for in VC by the char,short,int and __int64 datatypes. But the data sizes vary among platforms(1b/32 bit) and the 64 bit data type is compiler specific.So, to ensure code portability, I created my own datatypes(UI16,...,UI64) and typedef''ed them to the relevant compiler datatypes, in platform specific headerfiles. eg. \win32\datatype.h , \linux\datatype.h etc. So Here''s Q1 : Got any better ideas on above? How do you guys handle this problem? Onto the second part.Since the project is to eventually span multiple file and a few thousand lines of code , I am using a modified version of the Hungarian notation, encoding the data type into the variable name(which is why i needed standard data type names) so I wont have to search all over during debugging. However while looking through MSDN, I came over the following recommendations from Microsoft : from the .NET Framework Developer Specifications "Do not use Hungarian notation for parameter/field/property names. Good names describe semantics, not type." The VB articles at various points also warn against using the Hungarian notation. So Q2 :What do you guys do to ease maintainence?Any and all tips are welcome. All help appreciated!Thanx So Long, and Thanks for All the Fish !

Share this post


Link to post
Share on other sites
1) Hungarian Notation:

Many people will say it's a waste of time, but I would disagree. I love using it, because it makes my code highly readable (and not only for myself). Use it. Define a list of guidelines that MUST be adhered to by your group. Commonalities include m_, g_, lp, dw, l, i, n, sz, c, b, and so on.

2) Project Design

What I learned in college is that there are 4 main "sections" to a program's development. They are:

1 - Specification: the project is defined in terms of what an upper-management or 3-year-old child would understand. Explain the purpose of the program. Explain its interface. Explain what is required of the project in entirety.

2 - Design: This is where the bulk of your "coding" will go... but in the infamous language called Pseudocode! Write out what each area of your program will have to do. If you take the time in this section to develop the application well, then you will save yourself time later on.

3 - Coding: This is where you translate pseudocode from #3 into machine-usable code. Take the time to clean up sloppy mistakes, define high-level classes for reuse, and so on.

4 - Testing: The section that demands the most work; placing your code in a test environment for mass consumption. You will often return to #3 here if #2 is not well-adhered to.

3) Assign tasks

Modularity is your friend. Make sure that you design your application in such a way that each of its components fit into the "black box" methodology. This simply means that if you were to define each part in its own separate DLL file, you would later be able to use each DLL without worrying what the code does internally, only what it's SUPPOSED to do.

This way, you can delegate "modules" to each of your team. "The sound system", "the graphics system", "the GUI", "the world management", and so on. If each team has a set of specifications that must be adhered to, then each team member has a chance to not worry about what the others should be doing.

Example: There is an event in your game, termed EVENT_MONSTER_DIE. To Bill the AI coder, it will signify statistical loss. Tara the animation coder will know to launch the death animation sequence. And Victor the sound coder will know to launch the wav file that goes "unghhhh..."

So if your event-manager coder designs an event system that is strong, balanced, dynamic, and powerful, then each team member can code accordingly.



Good luck!



MatrixCubed
http://MatrixCubed.cjb.net








Edited by - MatrixCubed on February 16, 2002 7:23:42 PM

Share this post


Link to post
Share on other sites
Thanks MatrixCubed!
Your insights are much appreciated. BTW whats the Hungarian notation for unsigned short? I found ''word'' in an article but doesnt word size vary with the platfoem(while a short is 16 bits)?

______________________________________

So Long, and Thanks for All the Fish !

Share this post


Link to post
Share on other sites
First of all... I think Hungarian notation is pretty gimp and you just end up having to deal with more keystrokes and more typos having to type things like gfnptrWhatever which just leads to more mistakes and less readability...

To maintain a large project I recommend a lot of planning, diagrams (flowcharts), and as much modularity as you can possibly squeeze out of it (*lub C++*)... I like the idea of using CVS too.. it''s not really necessary if you''re doing the project by yourself, but if it ever gets big enough, or you want to find more people to work on it with you, you''ll love CVS (or some other version control software, but if you already have a Linux machine, might as well use CVS -- its free and there''s clients for Win32 too)

As for the types... I do that too.. F32, F64, UI16, I32, I64... much nicer than saying "long long" and having to think "now how the hell many bits are in a long long again"... and yeah, it helps portability a bit too, though I prefer it for the readability more than portability

Regarding Matrix''s 4 steps of Programming... I''d have to say they''re all a good idea... if you''re getting paid for this or have an iron will... specification is a necessity, but since this is a personal project you dont need to have an 800 page design document... a few pages describing each sub-system''s functionality and how they interact with one another, and a few good diagrams (one or more overview diagrams, and one or two for each subsystem) should be more than enough... Just make sure you know what you want to do for yourself and stick to it... if you put in your design doc you''re going to use BSP for interiors but later think portals would be cool... use BSP just out of principle...

Step two and step three I would merge for personal projects..
writing psuedocode completely before writing any actual code is boring to tell the truth, and personal projects aren''t really supposed to be boring.. I don''t know about you, but I would either stop writing the psuedocode or give up on the project if I decided to write the entire thing in psuedocode before C++ code... For large commercial projects, yeah its a good idea and it leads to better code... but you said it''s just a commercial project and as long as you realize for professional projects, psuedocode == good, you can cut a few corners on your own project.

What I do is I build classes... then stick functions in those classes to fit a need I have for that class and fill in the function with comments saying what the function needs to do and/or return, then write the code around those comments. It''s a compromise between the two.

As for step 4... testing''s another one of those things that commercial games do formally that that personal projects halfass. You want to make sure there''s no earth shattering bugs as far as you can tell before you release the game for other people to play, but you dont have a dedicated team of testers to play your game or 25 different hardware configurations to test it on so your best bet is to just let people download it and break it so long as you let them know there''s a high chance that there will be some bugs but you appreciate any feedback you can get to try to fix them...

Anyway, the main thing is to make sure you have fun with the project... you''re not going to make the next multimillion dollar game without a team of talented people working with you, so don''t sweat the small stuff and just make sure you do what needs to be done to finish.

Share this post


Link to post
Share on other sites
I always write out a design spec for every module I code.

In this document, I include the following
- Overview of the Module
- What classes it will contain
- How each class interact internally with each other
- How the exposed classes interact with the client code
- Variables of each class

I think that designing the high level code is more important than the pseudocode. Like nohbdy, I write out the classes first. If everything works the way it should, I just fill up the functions I left blank or incomplete.

Also, the exposed classes should be done last because what the client programmers can do very much depends on the internal workings of the other classes.

Take for example a 2D Tile-based system. I need a library of tiles that is loaded once. Thus the classes I would need would be:
- Tile Type (Flyweight)
- Tile Library (Exposed Class)
- Tile (Runtime Tile)
- Map (Tile Manager, Exposed)

After identifying the classes I need, I can then easily assign tasks to the classes.

Share this post


Link to post
Share on other sites