Orientation in code

well it may depend on what you're using. for example, if you're using a plain editor, there's probably not a lot you can do.

a lot of IDE's have some things built-in. For example, Visual Studio with C# (maybe others?) allows you to organize collapsible blocks of code with special comments. This makes it really easy to organize variables (a section for public declarations, private declarations, etc) and methods (sections for private methods, public methods, protected methods. overridden methods, etc).

a lot of IDE's will also generate an API from your code, and give you a sortable list of symbols in a separate window. So when you're looking for a specific method, you can just filter for it in the symbols list.

are you currently using an IDE? if so, which one?

I believe people generally refer to this as the "architecture" of their program (Not to be confused with the computer hardware architecture the program is run on).

I actually prefer just using an editor (VIM in my case) and no IDE. In any case, you'll definitely want to put some thought and effort into your program's architecture at this point.

I found myself in a similar situation a while back. I had a big mess of source files. I started to try to organize them, but learned the hard way that this can be a difficult process if the code wasn't designed with any program architecture in mind. So I ended up just starting over. I don't consider the time wasted as I learned a lot and was able to make something twice as good in half the time.

Anyway, how I go about organizing the code (and I'm still improving at this) goes something like this:

1) I try to divide my code into components. Each component gets a different directory. For example: /Display/ /Sound/ /Input/ /Engine/ etc...

This way you know that if you want to add some graphics functionality, you'll do it in /Display/. These component directories may have subdirectories as well, such as /Headers/ /Implementations/ /Data_Structures/ or however you'd like: Designing a program architecture can be fun!

2) As you add more and more code, you may gradually find your architecture isn't working as well... Things may again get complicated. At this point I usually spend quite a bit of time tweaking the architecture, moving things around, adding/changing directories. Basically finding a way to make it once again easy and intuitive to orient myself within the code. Note this type of process works well on a solo project, but if you work on massive software for a giant company this may not be possible.

3) Repeat 2 whenever necessary until your project is done!

Another thing that can help is to create documentation for your source. Look into a documentation generator (I like Natural Docs).

Having documentation for your code can help you find your way around it (and is probably essential on a team). Also, I find that by documenting my code, I can more easily spot the flaws in it's architecture and invent solutions to them.

Kind of an eyeful here, but hope it helped!

Quote:

Original post by Enjoy I am working on a project and it is getting big. For now I have around 5000 lines of code and 20 source files. It is getting really hard for me to orientate in my code - to add a new feachure or just to update something. Really hard to find what I need in that huge classes. I want to know if there is some software, that could help me or an article. Something that could help me.

What programming language should we be concerned with here? What development environment?

If you write well-designed code, with make proper use of encapsulation and other OO principles, then you should find that it's barely any harder to maintain 5 million lines vs 500 lines. If you didn't, then you should probably consider starting over.
Right now you have on average 250 lines of code per file. Those numbers sound very manageable to me.

BeauMN, thank you, I will consider your advices and review my architecture. Also thank you for a link. I will try it.

I am using c++, working under XCode in MAC OS X.

What you want to do is plan this sort of thing before you start -- but given that you're here post-facto you can probably solve a few issues by refactoring a bit and being smart about where you are putting things. Typically when I work on big things (I mean really big, 5k lines of code sounds nicely manageable to me) I tend to very clearly delineate functionality.

All that means is that I try and organise things according to their function. If I do a decent enough job, I can roll related bits and pieces into a library (you'll want to make up projects for this stuff). Making things modular is always a great help -- because if you are strict about the interfaces you provide to other folks (client programmers...), you can screw around with the internals of the library as much as you want and hopefully everyone else's code will work afterwards (it won't, naturally, but that just gives the testers something to do). This method of organisation just means that at any one time you only care about one particular subsystem of the entire system in general.

When using your libraries, you end up being exposed to looooots of interfaces, so it can get confusing -- so make sure to name things logically; c++ namespaces exist for a reason :)

In closing; always try and write a proper spec. I don't mean buy a book about how to write specs (though that might actually be a good idea), just that you ought to think long and hard about how you want things to work. Then write/type things out so that you have to follow the plan to the letter. Never deviate from the spec unless whatever you put there was totally unrealistic :)

hth!

~Shiny