coding convention for length of method / class

Hi,

Since the project I'm working on is the largest project I have ever done (it is for my dissertation), I have often revisited sections of code or analyses where I ask myself "what the hell was I doing here?" after months at at time.

So, to help alleviate this stress, I decided to finally write some code which gives me useful statistics on my own coding habits, like average function length, file size, and so on.

I have heard conventions on this before, but never bothered to follow them when I was knee deep in code because I wanted to flush the ideas out. Any advice on the topic?

---

For the record, there are 25848 lines of code as of today (I've been working on this project for four years), and that is from 58 source files. Not including the matlab I've done on the side... and it's giving me a headache.

It turns out the function lengths, in terms of lines, follow a long-tail distribution, just like a lot of other stuff in language like word frequency... at least from my sample, and the sample in the java code in my "program files" directory.

As a guide, I go with 50 lines and a max of 3 levels of indentation for any code doing anything remotely complicated. More than this, and it gets messy in a hurry to debug, test, maintain etc etc.

Sure there are exceptions.
Message decoders as big switch statements can be hundreds of lines long, but each individual case should either call a function or be dead simple to implement as inline code (no more than a handful of lines).

Yeah I'm starting to feel flustered... I never gave it much though, but I think I should adopt a "function per screen" rule of thumb... and I like the 3 scope rule.

But here's a related question... In my view, the purpose of exporting code to another function is that you call it twice, or you call it in several other circumstances within the scope of a class. However, if you only call it once, then the only purpose of writing seperate functions is to chunk a larger function into smaller functions. This does limit scope, so that in the seperate subsections, they don't accidentally share variable names and such, which is an advantage.

I'm having trouble because the way I see it, my code has two types of code on it:

(1) classes which are instantiated with data, upon which operations are done
(2) classes which have static methods, and which are never instantiated becuase they are, at root, procedural and only contain static procedures...

How can I reorganize things so that they are clearer? It seems creating a class just to have procedures sort of violates some sort of OOP principle, in that we were supposed to create objects with it?

Btw, for the record, this is all in java... thanks Salem, I started in CProg at 16, and now I'm 26... you've always been a great help!

Quote:

---

Originally Posted by doubleanti

It seems creating a class just to have procedures sort of violates some sort of OOP principle, in that we were supposed to create objects with it?

---

Not really. It is basically just using a class as a namespace.

So then, how would you organize youir source code's directories? According to classes which are instantiated, and the procedural classes?

Alphabetically.

What I have done so far is to place a character in front of related source files in terms of function.

So for example, for data processing classes which mostly contain procedures to be called, I put a 'p' in front of it, and for data classes which are instantiated, I put a 'd' in front of it. That way my editor organizes the 'process' sources and the 'data' sources when alphabetizing.

But it quickly becomes unwieldy when you're looking at 50+ source code files....

Quote:

---

Originally Posted by doubleanti

What I have done so far is to place a character in front of related source files in terms of function.

So for example, for data processing classes which mostly contain procedures to be called, I put a 'p' in front of it, and for data classes which are instantiated, I put a 'd' in front of it. That way my editor organizes the 'process' sources and the 'data' sources when alphabetizing.

But it quickly becomes unwieldy when you're looking at 50+ source code files....

---

Your "process" and "data" sources sound like a classic case of a model and a controller.

In my case, I have my model in one project and my controller in another project. It also happens to be that I have another project which is just interfaces for the model, and the controller can only see the interfaces, not the actual classes themselves...but I won't get into the whole reasons of why I'm doing it this way...that's how I'm doing it, and it's working very well.