Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Ever since entering the world of programming, I've been bombed with tips like "file should be only x lines", which is fair since new programmers tend to stuff everything into one file. But, having done programming professionally for more than a year now, I've mostly found myself getting hindered by the small size of the files, rather than than the large size of them. One of the biggest hindrances I have, is having to shuffle between 10-20 different files when investigating how something works, when some of those files contain only a couple of lines.

So I guess my question is: how do I know I've split my program into too small pieces?

share|improve this question
    
Is this specific to a language? –  Deco Aug 12 '12 at 8:39
    
Hm, I happen to have my IDE open to a 1.5K lines file right now... –  Yannis Rizos Aug 12 '12 at 8:40
    
@Deco I'm not really thinking of any specific language, though I've mostly programmed in Java and Javascript –  tsiki Aug 12 '12 at 8:43
    
@YannisRizos, the problem isn't that it is a 1.5K lines file, it's that there is only one function in it. ;) –  AProgrammer Aug 12 '12 at 9:31
    
For some reference to what others are using there is Figure 3. Median and average size of implementation files ("*.c") in st.cs.uni-saarland.de/edu/empirical-se/2006/PDFs/godfrey00.pdf for the Linux kernel. –  hlovdal Aug 12 '12 at 13:24
show 2 more comments

3 Answers

File size doesn't seem to be your problem - in real world development you'll eventually encounter projects that would have hundreds of files, even if every one of them contained serveral thousand lines of code.

If working with many files is a problem, you need better organization and tooling. Modern IDEs have many features that help with that (e.g. when programming Java in eclipse, "Open Call Graph" will bring tears of joy to your eyes if you haven't seen it before), so learn to use one of those well. As for organization, well-designed code should have low coupling and high cohesion, which means that code that does related things is close together (high cohesion) and to understand a given piece of code you don't need to look at many others (low coupling).

All that being said, the average size of a file in well-designed code should be perhaps 300 lines of code, give or take (depends on the language too). There is no minimum: sometimes the design calls for an empty class.

share|improve this answer
add comment

Instead of having to shuffle with 20 files, you'd have to shuffle with 20 locations in the same file. In my experience, editors make it easier to shuffle with 20 files and keeping some context -- such as the cursor position -- for each than to shuffle with 20 locations in the same file and trying to keep some context for each. You'll have trouble to even jump easily from one to the other.

share|improve this answer
    
how does that answer the question - "how do I know I've split my program into too small pieces?" –  gnat Aug 12 '12 at 10:17
    
It answers it by saying "There's no such thing as too small, so your concern is unfounded." –  Avner Shahar-Kashtan Aug 12 '12 at 10:56
    
@gnat: the context given in the first paragraph of the question makes it pretty clear that the verbatim question is the result of jumping to an incorrect conclusion –  Michael Borgwardt Aug 12 '12 at 11:20
    
@MichaelBorgwardt thanks! your reasoning makes pretty good sense –  gnat Aug 12 '12 at 18:18
add comment

I would suggest that file size isnt really that important, to me object complexity and function / method size is a lot more important. Assuming you are using an object oriented language, just be sure to make objects that have a clear function and be sure that they only have code for those specific functions.

As a general rule dont have any method / function that is longer than 25 lines (Excluding comment lines), if it is longer than that break it up.

As for the files themselves, they become irrelevant if you follow the tips above because you can always break them up later, but try to separate the files logically, or do what a lot of languages do as a guidline and put one class to a file, if its a procedural language, try to break up functionality using the files, ie. IO in one file, UI in another file and so on.

Just my 2c.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.