Project Source Files - Maximum Number of Lines 
Author Message
 Project Source Files - Maximum Number of Lines

Hi Folks,

Over the last year I have been employed as a programmer, ehhancing some existing
applications written in C. One of the applications consisted of a set of Source
Code Files for Borland C++.

I have never used any C Compilers outside of the Windows/DOS environment, but I
assume the Project method of Application Development is available in other
environments as well.

Anyway, my questions is-

What is the Maximum recommended size for a source file in a project? The
programmers who originally wrote the projects I have been enhancing seem to draw
the line at about 1500 - 1800 lines.

The only recommendation on the subject that I can find comes from a very old
book by Steve Schustak. It recommends 200 lines. This seems a little short to
me.

Bernard Doyle



Mon, 05 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines

This is going to be something that is very 'opinion driven' and hard to
resolve perfectly.  My own choice, for myself, is to make the files as
small as possible.  Instead of grouping a cluster of related functions in a
file, I group them in a common directory.  That way, you have the files
that interact in one location, but not all inside of a single translation
unit.  For a function, I prefer 100 lines or less (though this is sometimes
not achieved in practice).  With tools like Lint that can look through all
the files in a project, we no longer have additional benefit from compilers
catching problems by grouping the code together.  YMMV.



Quote:
> Hi Folks,

> Over the last year I have been employed as a programmer, ehhancing some
existing
> applications written in C. One of the applications consisted of a set of
Source
> Code Files for Borland C++.

> I have never used any C Compilers outside of the Windows/DOS environment,
but I
> assume the Project method of Application Development is available in
other
> environments as well.

> Anyway, my questions is-

> What is the Maximum recommended size for a source file in a project? The
> programmers who originally wrote the projects I have been enhancing seem
to draw
> the line at about 1500 - 1800 lines.

> The only recommendation on the subject that I can find comes from a very
old
> book by Steve Schustak. It recommends 200 lines. This seems a little
short to
> me.



Thu, 08 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines

[snip]

Quote:
> Anyway, my questions is-

> What is the Maximum recommended size for a source file in a project?
> The programmers who originally wrote the projects I have been
> enhancing seem to draw the line at about 1500 - 1800 lines.

How much state can you keep in your head at once?  I find that I start
getting confused beyond about 2000 lines in a source file.  If a file
gets longer than that, there's usually some sort of logical division
for the subject of the file.

On the other hand, sometimes source files are very hard to divide up
on any basis; in that case I would continue to let them grow but also
continue to consider breaking them up should a good method of division
occur to me.

I have seen, in well-written programs, source files of well over
10,000 lines.  For instance, gcc 2.5.8 (to name the version closest at
hand) contains a single file `cp_decl.c' with 12,215 lines of code.

I guess this is really a matter of personal taste.  I don't doubt that
in very short time we could all be flaming each other over it just as
vigorously as over indenting issues ;-)

Quote:
> The only recommendation on the subject that I can find comes from a
> very old book by Steve Schustak. It recommends 200 lines. This seems
> a little short to me.

Way too short, I think.  I regularly write single _functions_ longer
than 200 lines.
--

PGP public key and home page at http://www.msu.edu/user/pfaffben


Thu, 08 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines


Quote:

>Hi Folks,
>[Preamble snipped for brevity]

>Anyway, my questions is-

>What is the Maximum recommended size for a source file in a project? The
>programmers who originally wrote the projects I have been enhancing seem to draw
>the line at about 1500 - 1800 lines.

>The only recommendation on the subject that I can find comes from a very old
>book by Steve Schustak. It recommends 200 lines. This seems a little short to
>me.

Depends how much of a purist you want to be.  I've seen recommendations
that each *function* have it's own source module.  I don't think that's
a very good idea; the thought of dealing with several hundred source
files making up a single program is scary.

I'd recommend not having a particular hard limit.  I aim to keep a
module below 1000 lines, but I'm more worried that the modules are
coherent than I am about size.  Think cohesion and coupling, not just
size.

I'd rather have a 2000-line module which contains the entire interface
and static support functions for a section of the code, then two
smaller ones which are forced to have a lot of functions which should
be static declared globally.  It helps a lot in keeping the interfaces
to your modules clean.  If a given function takes a lot of code, then
there'll probably be a sub-section of it which can be moved into
another module without forcing you to make a lot of static functions
global.

My rule on this is the same as in many other situations.  The rules
are really guidelines which help you do a better job.  If following
the rules makes life harder in a given situation, then ignore them.
Saying "no modules should ever be bigger than 1800 lines" is counter-
productive; a module should be as big as it needs to be, and no
bigger.

I'm sure other people have a different slant on this, but that's
mine, for what it's worth.
--
M a l c . . .            |  "A wrong parameters may be caused the mainboard



Fri, 09 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines


Quote:
> Hi Folks,

> Over the last year I have been employed as a programmer, ehhancing some existing
> applications written in C. One of the applications consisted of a set of Source
> Code Files for Borland C++.

> I have never used any C Compilers outside of the Windows/DOS environment, but I
> assume the Project method of Application Development is available in other
> environments as well.

> Anyway, my questions is-

> What is the Maximum recommended size for a source file in a project? The
> programmers who originally wrote the projects I have been enhancing seem to draw
> the line at about 1500 - 1800 lines.

> The only recommendation on the subject that I can find comes from a very old
> book by Steve Schustak. It recommends 200 lines. This seems a little short to
> me.

I agree; 200 is too short.  I honestly don't think this is a quantifiable
thing.  I think the best way to organize things is to collect common
subroutines in a source file, and no more.  The idea is that a file
should have one and only one purpose, and I should be able to understand
that purpose with a minimum of cross-knowledge.

I will say definitively what I do *not* like, and that is putting one
subroutine per source file.  This practice IMNSHO is evil and should
not even be considered.  Besides being very difficult to follow what's
going on, it slows down compilations of source modules something awful.

[apologies to those who may utilize the above technique.  No offense
intended. :-) ]

--
==========================================================================

| "Judge all, and be prepared to be judged by all."                      |
==========================================================================



Fri, 09 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines

<snip>

Quote:
>> The only recommendation on the subject that I can find comes from a very old
>> book by Steve Schustak. It recommends 200 lines. This seems a little short to

>> me.

>I agree; 200 is too short.  I honestly don't think this is a quantifiable
>thing.  I think the best way to organize things is to collect common
>subroutines in a source file, and no more.  The idea is that a file
>should have one and only one purpose, and I should be able to understand
>that purpose with a minimum of cross-knowledge.

>I will say definitively what I do *not* like, and that is putting one
>subroutine per source file.  This practice IMNSHO is evil and should
>not even be considered.  Besides being very difficult to follow what's
>going on, it slows down compilations of source modules something awful.

Well, I've had some my past work practices referred to by many names, but
"evil" is a new one! :-)

I have used this practice on some projects in the past and feel it does have
some benefits but like all approaches, it does have its drawbacks as well.  
I'll stick my neck out here and try to do a short defense of the practice.

All the projects I have used the "one function per source file" approach on
have been small (< 20K lines of code), realtime, embedded software projects.  
Related source files were always grouped into modules contained within their
own directory with their own make file producing a library file for the
module.  This really isn't much different than having related functions
contained in a single file producing an object file for the module.  A master
makefile ran all the module make files and linked (and located, since it was
embedded) the modules together.

I feel that most of the drawbacks were minor.  The builds did take longer but
since the projects were all small, it was no big deal if a complete build
(including linting) took two minutes instead of one.  Of course, most builds
weren't full and only took a few seconds driven mostly by the link and locate
anyway.  Finding the right file to edit for a particular function was a tiny
bit harder but also no big deal.  Most of the time when working on a module I
would simply change to the module's directory and run my editor on "*.c"
loading all the funtions (files).

What were the advantages?  Nothing huge, but I believe I was able to better
document the code (especially the interfaces) for others to understand and
maintain.  This was very important for most of these projects as they had
significant outside review and had (have) long maintenance periods (10 to 15
years).  Since each function had to explicitly declare as external any global
variables accessed the interfaces to global memory were easily seen at the
function level.  I also got fine grained revision history down to the function
level which was occasionally handy.

In terms of understanding what was going on in the code, I believe that this
approach made the code very much like an onion.  It made it very easy for
someone (even non-software people) to understand what the code did at a
particular level of the onion and if they wanted to see more they just peeled
back another layer.  Of course a calling tree with a cross-reference came in
very handy.  It did make it more difficult for someone who wanted or needed to
see a particular area in all its detail (a cross section of the onion).  On
the last project that I used this approach on I seem to remember I got mixed
feedback from outside reviewers of the code.  Some thought the code was
extremely easy to follow and liked the approach while at least one other
thought it was difficult to follow.  This may have been due to the difference
between onion "peelers" and "slicers".

Quote:

>[apologies to those who may utilize the above technique.  No offense
>intended. :-) ]

No offense taken.  Although I've used this approach, I can also understand
your "distaste" for it.  If another similar project came up in the future, I
might not use this method again.  I certainly have worked on plenty of
projects where I did not (and would not want to) use this approach.  I just
believe it does have some advantages that may justify its use for certain
projects.  

OK everyone, my neck's out there, chop away!


All opinions expressed are my own and not my employer's.



Mon, 12 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines

Quote:

>Hi Folks,
>Over the last year I have been employed as a programmer, ehhancing some existing
>applications written in C. One of the applications consisted of a set of Source
>Code Files for Borland C++.
>I have never used any C Compilers outside of the Windows/DOS environment, but I
>assume the Project method of Application Development is available in other
>environments as well.
>Anyway, my questions is-
>What is the Maximum recommended size for a source file in a project? The
>programmers who originally wrote the projects I have been enhancing seem to draw
>the line at about 1500 - 1800 lines.
>The only recommendation on the subject that I can find comes from a very old
>book by Steve Schustak. It recommends 200 lines. This seems a little short to
>me.

     Are you sure that you're reading that right?  It sounds as if the
author is referring to individual subroutines.  In that case, 200 is
about right for most cases.

     This is very much a religious issue.  My religion is the simpler
the structure of the code, the longer it can be.  It isn't the length
of the code that gets you: it's the complexity.  Lots of loops and
conditionals with a lot of variables: ten lines might be too long in
some cases.

     Advanced Religion: As for modules, I figure a module is a piece.
It should be able to stand on its own.  I might put a number of short
modules together in one source code file.  I would not generally break
up a module.  It's easier to say that "x" is the client table support
module and if you have to go into it, then you worry about whether
it's 500 lines or 5,000.

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Mon, 12 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines


Quote:
> Hi Folks,

> Over the last year I have been employed as a programmer, ehhancing some existing
> applications written in C. One of the applications consisted of a set of Source
> Code Files for Borland C++.

> I have never used any C Compilers outside of the Windows/DOS environment, but I
> assume the Project method of Application Development is available in other
> environments as well.

> Anyway, my questions is-

> What is the Maximum recommended size for a source file in a project? The
> programmers who originally wrote the projects I have been enhancing seem to draw
> the line at about 1500 - 1800 lines.

> The only recommendation on the subject that I can find comes from a very old
> book by Steve Schustak. It recommends 200 lines. This seems a little short to
> me.

I agree; 200 is too short.  I honestly don't think this is a quantifiable
thing.  I think the best way to organize things is to collect common
subroutines in a source file, and no more.  The idea is that a file
should have one and only one purpose, and I should be able to understand
that purpose with a minimum of cross-knowledge.

I will say definitively what I do *not* like, and that is putting one
subroutine per source file.  This practice IMNSHO is evil and should
not even be considered.  Besides being very difficult to follow what's
going on, it slows down compilations of source modules something awful.

[apologies to those who may utilize the above technique.  No offense
intended. :-) ]

--
==========================================================================

| "Judge all, and be prepared to be judged by all."                      |
==========================================================================



Mon, 12 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines


Quote:
> I have used this practice on some projects in the past and feel it
> does have some benefits but like all approaches, it does have its
> drawbacks as well.  I'll stick my neck out here and try to do a
> short defense of the practice.

> All the projects I have used the "one function per source file"
> approach on have been small (< 20K lines of code), realtime,
> embedded software projects.  Related source files were always
> grouped into modules contained within their own directory with their
> own make file producing a library file for the module.

Hm. Well, I can actually see that this approach might not be so bad,
if the entire source tree is that small. Certainly one thing I miss
when programming in C is wider control over name visibility. This
approach would compensate for that. I might try it myself the next
time I work on a small program.

Hey, another thing that would help is if every external *variable*
went into its own .h file!



Tue, 13 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines



Quote:

> >I will say definitively what I do *not* like, and that is putting one
> >subroutine per source file.  This practice IMNSHO is evil and should
> >not even be considered.  Besides being very difficult to follow what's
> >going on, it slows down compilations of source modules something awful.

> Well, I've had some my past work practices referred to by many names, but
> "evil" is a new one! :-)

A bit of hyperbole for your Usenet pleasure. :-)

Quote:
> I have used this practice on some projects in the past and feel it does have
> some benefits but like all approaches, it does have its drawbacks as well.  
> I'll stick my neck out here and try to do a short defense of the practice.

> All the projects I have used the "one function per source file" approach on
> have been small (< 20K lines of code), realtime, embedded software projects.  
> Related source files were always grouped into modules contained within their
> own directory with their own make file producing a library file for the
> module.  This really isn't much different than having related functions
> contained in a single file producing an object file for the module.  A master
> makefile ran all the module make files and linked (and located, since it was
> embedded) the modules together.

The difference is:

1) The files are tossed together in a directory, and there is no logical
   organization.  Within a source file, you can have comments at the top
   of the file explaining the organization and how the subroutines fit
   together, and the subroutines can be ordered in a logical "top down"
   sequence.

2) I find it easier and much faster to page up/down among subroutines
   to see what's going on.  I personally dislike have lots of windows
   open everywhere.

3) Recompilation of source files is much slower.

Quote:
> I feel that most of the drawbacks were minor.  The builds did take longer but
> since the projects were all small, it was no big deal if a complete build
> (including linting) took two minutes instead of one.  Of course, most builds
> weren't full and only took a few seconds driven mostly by the link and locate
> anyway.  Finding the right file to edit for a particular function was a tiny
> bit harder but also no big deal.  Most of the time when working on a module I
> would simply change to the module's directory and run my editor on "*.c"
> loading all the funtions (files).

For small projects, I agree the problems are minor, but then for small
projects *most* problems are minor. :-)

Quote:
> What were the advantages?  Nothing huge, but I believe I was able to better
> document the code (especially the interfaces) for others to understand and
> maintain.  This was very important for most of these projects as they had
> significant outside review and had (have) long maintenance periods (10 to 15
> years).  Since each function had to explicitly declare as external any global
> variables accessed the interfaces to global memory were easily seen at the
> function level.  I also got fine grained revision history down to the function
> level which was occasionally handy.

Perhaps, but nothing precludes this level of documentation when common
subroutines are grouped in files.

I think it's safe to say that more organization is better than less
organization, and I think the *order* of subroutines within a modular
unit is a valuable thing, since it conveys more of the thinking of the
original programmer.

Quote:
> In terms of understanding what was going on in the code, I believe that this
> approach made the code very much like an onion.  It made it very easy for
> someone (even non-software people) to understand what the code did at a
> particular level of the onion and if they wanted to see more they just peeled
> back another layer.  Of course a calling tree with a cross-reference came in
> very handy.  It did make it more difficult for someone who wanted or needed to
> see a particular area in all its detail (a cross section of the onion).  On
> the last project that I used this approach on I seem to remember I got mixed
> feedback from outside reviewers of the code.  Some thought the code was
> extremely easy to follow and liked the approach while at least one other
> thought it was difficult to follow.  This may have been due to the difference
> between onion "peelers" and "slicers".

There could be people out there who find it better, I suppose, but
I just hate having subroutines "floating around" without being tied
to specific functionality.  In my mind, the unit of functionality is
a file, since that is my "last chance" to impose order and comments
on the chaos of individual subroutines.  Above that, they're just
files in a directory, and I can't "comment the directory", if you
know what I mean.

Now, certainly you can have external documentation to the source
code that gives global information, but that's a lot less convenient
than having the comments at your fingertips.  Not to mention a lot
easier to change the documentation when the code is changed.

I simply can't see how *less* organization is a benefit.

Quote:
> OK everyone, my neck's out there, chop away!

Whoosh-thunk!  splat!

============\===/=
            /|||\
           |_____|

            \/\/\
           / O O \
           |  ^  |
           |  O  |
         ===\---/===
        //#########\\
       // ######### \\
      /|\ ######### /|\
          #########

--
==========================================================================

| "Judge all, and be prepared to be judged by all."                      |
==========================================================================



Tue, 13 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines



Quote:
>I agree; 200 is too short.

Heck, for some people that wouldn't be enough to comment a function,
let alone code it! :-)

--
-----------------------------------------


-----------------------------------------



Tue, 13 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines

Quote:

> What is the Maximum recommended size for a source file in a project? The
> programmers who originally wrote the projects I have been enhancing seem to draw
> the line at about 1500 - 1800 lines.

I don't have any fixed rule, but I find that I seem to draw the line at about
1000 lines.  This works well for me.


Thu, 15 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines



[snippage]

Quote:
> There could be people out there who find it better, I suppose, but
> I just hate having subroutines "floating around" without being tied
> to specific functionality.  In my mind, the unit of functionality is
> a file, since that is my "last chance" to impose order and comments
> on the chaos of individual subroutines.  Above that, they're just
> files in a directory, and I can't "comment the directory", if you
> know what I mean.

I prefer to group functions with a subdirectory hierarchy.  Examine, for
instance, how DJGPP or similar products are distributed in source form.
Actually, either technique works.  The cry here is for "organization".  One
way to achieve organization is by grouping.  Grouping can be by task
performed, by major functional area, or many other possibilities.  This
grouping can be created by using subdirectorys or by grouping in files.
The one advantage of using subdirectories is that the recompilation and
linking can be restricted to the single function affected.  The biggest
disadvantage to using subdirectories instead of files is that the make
files are more complex.

I "comment the directory" with a readme.txt file.

I don't always stick to the one function per file rule.  If files 'demand'
to be grouped together because of coupling or some similar reason, then I
put them together in one file.



Fri, 16 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines

I would say the good length is the the one you don't hesitate to print.
Too short is difficult to manage, too long and you you refrain printing
and so never think to your structure on paper, which i think is not good...

Old fashioned, is'nt it?

        pierre



Sun, 18 Jul 1999 03:00:00 GMT  
 Project Source Files - Maximum Number of Lines


wrote in comp.lang.c.moderated:

=> I would say the good length is the the one you don't hesitate to print.
=> Too short is difficult to manage, too long and you you refrain printing
=> and so never think to your structure on paper, which i think is not good...

=> Old fashioned, is'nt it?

Definitely. I haven't seen my code on paper in over ten years. And I hope I
never do.
My guideline for source file length - do I get irritated waiting for a search
to complete. [I have no patience, so that usually translates to about 1000
lines.]

<><><><><><><><><><><><><><><><><><><><>

Wizard's First Rule:
    People are stupid.
Wizard's Second Rule:
    Never depend on the first rule.

<><><><><><><><><><><><><><><><><><><><>



Mon, 19 Jul 1999 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Source File Name and Line Number

2. Maximum number of open files (DOS/C)

3. Maximum Number of open Files?

4. Number of lines in a project

5. How to get the C# source line number into the program

6. Preprocessor directive to replace with source line number

7. how do I find the filename and line number within the source code

8. Number of source line of codes in a function

9. Printing source with line numbers

10. Getting source line numbers at runtime?

11. line number and file name in release built

12. determining the number of lines in a text file

 

 
Powered by phpBB® Forum Software