Fn Defn Style

[Tom St Denis]

I knew this would be your base reason. And its ridiculous. A function
name is more than enough partitioning. How you think of functions is
silly. I suspect it comes from some antiquated notion of how RCS should
work.

What next? C++ member functions in separate files in subdirs
representing their class.

Depends on the length and complexity. You seem to be of the school
where longer compilation times == greater success. That sort of
thinking leads to people bragging about "2 million lines of code" and
"8 hour build times" ...

I consider it a design flaw if changing a single line of code results
in a turn around time [after an initial build] of longer than 5
seconds [+/- a few for network traffic].

I also don't code in C++ because I've never found a use for it. But
that's another topic for another usenet group for another day.

Tom

 

[Tom St Denis]

A little like your views on Macros your views seem based on nothing
more than your own gut feeling which in turn are based on your own
limited experiences.

I have worked on huge projects where certain key files might be
branched 4 or 5 times.

Branching is another topic all together. People can commit changes to
different branches without fear of collisions, that's what branches
are for. But I'd like to hear how if people commit changes to the
same file on the same branch in the same lines of code, how there are
NOT collisions.

Tom

 

[Tom St Denis]

Most modern version control systems don't lock files; they allow
two different people to work on the same file at the same time.
But typically the last person to check in the file has to merge
the changes.  If the changes are isolated from each other, this is
straightforward; if not, you'd have the same merging problem with
one function per file.

Yeah, what I'm commenting on is if I ask someone to review a subsystem
of a library, we usually are fairly tight knit on who's working on
what. So if they say "I'm working on point addition" then I avoid
that file altogether, etc, whatever. Whereas if I put all my ECC code
in "ecc.c" he might be making changes outside the function in question
[say he notices a typo or bug elsewhere].

Some text editors (Emacs in particular) have a mode in which you
can temporarily narrow the visible portion of a file, working on
a subset as if it were an entire file.  (And I just learned
that there's a vim plugin that does the same thing.)

Cool. You can also do that by not putting all of your code in one
file.

Unless you've got thousands of them.

Start early. Trying to take a bad project and make it good is more
work than if you just started properly in the first place. Get the
build infrastructure in from the ground up, etc...

Tom

 

[Tom St Denis]

Exactly. Noe that I am not suggesting all files should be larger than
500 lines ... that is yet another straw man from Tom to defend his
rather antiquated stance.

My reaction to your reply wasn't that I thought you thought all files
should be larger than 500 lines, instead I took from your initial
reply that you thought I didn't think compilers could handle files
larger than 500 lines (because I use antiquated tools...).

As I've said a half dozen times already it's just a rule of thumb. If
you're writing a function and it's starting to get long, chances are
there are ways to factor it. Not always, but it's something to look
for.

Tom

 

[Ian Collins]

Does it really take that much longer to compile 5000 lines instead of
500? (My files are typically 5000 lines and take a fraction of a second
to compile.)

If you have a set of smaller files, a decent build system will compile
them in parallel on appropriate hardware. I tend to favour more smaller
files over fewer, bigger files for that reason.

And how does it affect building other than making it take longer because
of having to deal with hundreds of files instead of dozens?

Improved parallelism.

(I don't know how these things work in teams; maybe only one member has
build/run privileges? Or can anyone build and test a project that
includes half-finished modules from other team members? Or does each
person just test, independently, a small portion of the project in a
test setup. That still doesn't explain this arbitrary file line-limit.)

In a well run team, people only check in tested code to a shared stream.

 

[Keith Thompson]

Provided they don't touch overlapping sections of code. Yeah I agree
there won't be problems. But if people are doing a code review and
touching up things here and there it's easy to collide. That's why
locking a file is easier, it prevents this problem. Now if you lock a
file with huge segments of your project your boned.

[...]

My point (I won't speculate on what Richard's point might have been)
is that, with a decent source control system, putting each function
in its own file isn't very helpful in avoiding collisions. If two
people work on the same file at the same time, and they modify
disjoint portions of the file, then merging the changes after the
fact is usually quite straightforward. If they modify the same
portion of the same file, then they would have run into the same
problem even if each function were in its own source file.

This isn't an argument *against* putting each function in its own
source file; I'm just saying that doing so doesn't buy as much as
you seem to be saying it does.

Again, my experience is that modern source control systems don't
lock files, so any concerns about problems caused by file locking
are largely irrelevant. (This wasn't always so; I've used shared
RCS systems in the past.)

 

[Tom St Denis]

My point (I won't speculate on what Richard's point might have been)
is that, with a decent source control system, putting each function
in its own file isn't very helpful in avoiding collisions.  If two
people work on the same file at the same time, and they modify
disjoint portions of the file, then merging the changes after the
fact is usually quite straightforward.  If they modify the same
portion of the same file, then they would have run into the same
problem even if each function were in its own source file.

I fully agree with this. I guess my point here though is it's easy to
stay focused on your own segment of code if you have your own file to
work on. While the people in my group interact often we're still
individuals and we don't always wait for the word before moving on to
the next piece of code to review.

So far we haven't had any collision problems yet.

This isn't an argument *against* putting each function in its own
source file; I'm just saying that doing so doesn't buy as much as
you seem to be saying it does.

I guess it's a question of discipline. But there are more reasons
than just this to keep files specialized.

Again, my experience is that modern source control systems don't
lock files, so any concerns about problems caused by file locking
are largely irrelevant.  (This wasn't always so; I've used shared
RCS systems in the past.)

You can lock files via CVS. We tend not to here because of the non-
overlap of work, but it is possible.

Tom

 

[Flash Gordon]

I've worked with git, svn, cvs, and even clearcase. Collisions happen
all the time and they're nasty. That's why file locks exist. The
fewer resources you lock the better.

I agree with Richard nosurname. I've worked on a number of projects with
a number of sizes of team. Even ones where everyone was logged in to the
same account on the Vax editing files, so you actually could edit the
copy someone else was working on if you wanted! Collisions in all
instances happened rarely because members of the team talk to each other
so they know what each other is doing, and the project/product manager
also knows what everyone is doing. Yes, using CVS and Subversion we've
had the occasional conflict, but they've not been hard to resolve.

I group a set of logically related functions in to a file, and if that
makes the file big then it is big. It means I can use static file scope
variables when that makes sense, have shared static helper functions,
and in general keep the interface as tight as possible.

Yes, but its another one of your straw men. My point is that your
arbitrary 500 line limit is bullshit.

First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
REPLY!!!!"

Then, I never said it was a hard written in stone limit. I have hand
written files that span into 6-7-8 hundred lines long. As a general
rule though if you're writing something [by hand] that gets over 500
lines, there is very likely [but not always] a chance to re-factor the
code to make it easier to work with [and/or a chance for code re-
use].

I don't find the larger files cause a problem with code reuse, since the
larger file has a load of logically related functions so when you are
reusing one you generally want most of the others anyway, and if not it
is still not large enough for a few extra functions to be a big deal.

That's the difference between people like me [with experience] and
people like you [think they know everything].

I disagree with you and I have a fair bit of experience, and have used
everything from manual version control (physically passing files between
people on floppy disk), through having a configuration control system
which was a *person*, through rcs (I was very rare to find a file
locked, since we actually talked to each other in the team), through
CVS, Subversion, MS VCC and maybe a few others I've forgotten.

We can say things like
"most files shouldn't be longer than 500 lines" and understand that it
means "most files shouldn't be super long because you'll probably be
able to factor the code better and achieve code reuse." Whereas you,
with little experience didn't know about that sort of development
strategy and just assumed that I meant "all files must be less than
500 lines because compilers can't handle 501 lines."

I disagree. I don't find a file of over a thousand lines takes long to
control, developers should know what each other are working on so they
know where to expect changes (and so what they might find breaks),
commits should be frequent, all of which means rare conflicts which are
easily dealt with.

tl;dr, sometimes you just have to know when to shut up.

Sometimes you should admit that other peoples experience is also valid.

 

[Flash Gordon]

I've worked with git, svn, cvs, and even clearcase. Collisions happen
all the time and they're nasty. That's why file locks exist. The
fewer resources you lock the better.

I agree with Richard nosurname. I've worked on a number of projects with
a number of sizes of team. Even ones where everyone was logged in to the
same account on the Vax editing files, so you actually could edit the
copy someone else was working on if you wanted! Collisions in all
instances happened rarely because members of the team talk to each other
so they know what each other is doing, and the project/product manager
also knows what everyone is doing. Yes, using CVS and Subversion we've
had the occasional conflict, but they've not been hard to resolve.

I group a set of logically related functions in to a file, and if that
makes the file big then it is big. It means I can use static file scope
variables when that makes sense, have shared static helper functions,
and in general keep the interface as tight as possible.

Yes, but its another one of your straw men. My point is that your
arbitrary 500 line limit is bullshit.

First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
REPLY!!!!"

Then, I never said it was a hard written in stone limit. I have hand
written files that span into 6-7-8 hundred lines long. As a general
rule though if you're writing something [by hand] that gets over 500
lines, there is very likely [but not always] a chance to re-factor the
code to make it easier to work with [and/or a chance for code re-
use].

I don't find the larger files cause a problem with code reuse, since the
larger file has a load of logically related functions so when you are
reusing one you generally want most of the others anyway, and if not it
is still not large enough for a few extra functions to be a big deal.

That's the difference between people like me [with experience] and
people like you [think they know everything].

I disagree with you and I have a fair bit of experience, and have used
everything from manual version control (physically passing files between
people on floppy disk), through having a configuration control system
which was a *person*, through rcs (I was very rare to find a file
locked, since we actually talked to each other in the team), through
CVS, Subversion, MS VCC and maybe a few others I've forgotten.

We can say things like
"most files shouldn't be longer than 500 lines" and understand that it
means "most files shouldn't be super long because you'll probably be
able to factor the code better and achieve code reuse." Whereas you,
with little experience didn't know about that sort of development
strategy and just assumed that I meant "all files must be less than
500 lines because compilers can't handle 501 lines."

I disagree. I don't find a file of over a thousand lines takes long to
control, developers should know what each other are working on so they
know where to expect changes (and so what they might find breaks),
commits should be frequent, all of which means rare conflicts which are
easily dealt with.

tl;dr, sometimes you just have to know when to shut up.

Sometimes you should admit that other peoples experience is also valid.

 

[bartc]

If you have a set of smaller files, a decent build system will compile
them in parallel on appropriate hardware. I tend to favour more smaller
files over fewer, bigger files for that reason.


Improved parallelism.

Well, OK. I'd never really thought of a development cycle as being
time-consuming enough to warrant parallel processing, (perhaps because in my
case, even working with microprocessors and floppy disks in the 1980s, I
made sure my development cycles hardly ever took more than a second or so,
no matter how complex the project).

Anyway unless everything really is in just one giant file, surely a typical
project will have enough files in it to keep any multi-processor system
happy, even with thousands of line per file?

 

[Richard Tobin]

Even ones where everyone was logged in to the
same account on the Vax editing files, so you actually could edit the
copy someone else was working on if you wanted!

You can run a single instance of Emacs with windows displayed on
different computers, so it's possible for two people to edit the same
file at the same time and see each others' changes as they are typed.

-- Richard

 

[Flash Gordon]

I fully agree with this. I guess my point here though is it's easy to
stay focused on your own segment of code if you have your own file to
work on. While the people in my group interact often we're still
individuals and we don't always wait for the word before moving on to
the next piece of code to review.

In my book, a code review involves having the author of the code and a
number of other people sitting down together to discus it before *any*
changes are made, so the author can learn from anything which is pointed
out, or can correct the corrections if the reviewers are wrong. The
reviewers will *read* the code in advance, just not change it.

So far we haven't had any collision problems yet.

I've had collisions, but never real problems.

I guess it's a question of discipline. But there are more reasons
than just this to keep files specialized.

There are also reasons for keeping several related functions all of
which are externally visible in the same file. It's not back-and-white.

You can lock files via CVS. We tend not to here because of the non-
overlap of work, but it is possible.

I which case the code being in larger files would not cause any problems
either.

 

[Flash Gordon]

I fully agree with this. I guess my point here though is it's easy to
stay focused on your own segment of code if you have your own file to
work on. While the people in my group interact often we're still
individuals and we don't always wait for the word before moving on to
the next piece of code to review.

In my book, a code review involves having the author of the code and a
number of other people sitting down together to discus it before *any*
changes are made, so the author can learn from anything which is pointed
out, or can correct the corrections if the reviewers are wrong. The
reviewers will *read* the code in advance, just not change it.

So far we haven't had any collision problems yet.

I've had collisions, but never real problems.

I guess it's a question of discipline. But there are more reasons
than just this to keep files specialized.

There are also reasons for keeping several related functions all of
which are externally visible in the same file. It's not back-and-white.

You can lock files via CVS. We tend not to here because of the non-
overlap of work, but it is possible.

I which case the code being in larger files would not cause any problems
either.

 

[Flash Gordon]

Branching is another topic all together. People can commit changes to
different branches without fear of collisions, that's what branches
are for. But I'd like to hear how if people commit changes to the
same file on the same branch in the same lines of code, how there are
NOT collisions.

If you change the same line of code there is a collision, the person
trying to do the commit gets notified, knows that someone else has
modified it (can check who and why from the log), and can then work out
the appropriate corrective action. This is not a problem any more than
the file being locked preventing such modification is a problem. In
either case people have to look at the different changes which are
either being done, or which they want to do, and work out the correct
way to incorporate both changes. The key is that we are dealing with
people, and people are able to talk to each other.

 

[Ian Collins]

Well, OK. I'd never really thought of a development cycle as being
time-consuming enough to warrant parallel processing, (perhaps because
in my case, even working with microprocessors and floppy disks in the
1980s, I made sure my development cycles hardly ever took more than a
second or so, no matter how complex the project).

Really? Maybe you should give the Linux or OpenSolaris kernel folks
some advice!

I tend to compile and run tests very frequently, so build times are an
issue.

Anyway unless everything really is in just one giant file, surely a
typical project will have enough files in it to keep any multi-processor
system happy, even with thousands of line per file?

It probably will. There might be issues with individual compiles of
very large files hogging a disproportionate amount of memory, but these
tend to come out in the wash as well.

 

[Nick Keighley]

handy if you quoted him though...

I've worked with git, svn, cvs, and even clearcase.  

Ah ClearCase. I feel your pain.

Collisions happen all the time and they're nasty.

Why doesn't ClearCase handle these collisions? If people are working
in different parts of the file (eg. different functions) then there is
no collision problem. If they are working on the same function then
they collide no matter how many micro file you have.

 That's why file locks exist.  The
fewer resources you lock the better.

so don't lock files

First, let me do my impression of you.  

Then, I never said it was a hard written in stone limit.  I have hand
written files that span into 6-7-8 hundred lines long.  As a general
rule though if you're writing something [by hand] that gets over 500
lines, there is very likely [but not always] a chance to re-factor the
code to make it easier to work with [and/or a chance for code re-
use].

Why does large file size indicate a need to refactor? Why does file
size affect code reuse?

That's the difference between people like me [with experience]
and people like you

I'd do some googling if I were you

[think they know everything].

He's annoying isn't he? He's also right more often then we'd sometimes
like.

 We can say things like
"most files shouldn't be longer than 500 lines" and understand that it
means "most files shouldn't be super long because you'll probably be
able to factor the code better and achieve code reuse."  Whereas you,
with little experience didn't know about that sort of development
strategy and just assumed that I meant "all files must be less than
500 lines because compilers can't handle 501 lines."

tl;dr, sometimes you just have to know when to shut up.

oh yes

 

[Nick Keighley]

It's a rule of thumb.  Stop being so obtuse.  I said that chances are
if you're writing a SINGLE function that approaches 500 lines that
chances are good you can factor functionality out of it.  

no you didn't. If you'd said *that* I wouldn't be arguing (much). This
is an exact quote "most source files should be less than 500 lines at
most anyways". The sentence was rather longer but I haven't distorted
what you said by taking you out of context.

 

[Michael Foukarakis]

Ever since I moved back over to *nix, I've noticed a difference in the way
people are defining functions in a lot of the source code I'm downloading..
Instead of...

  int funcname (int arg1, ...)
  {
      ...
  }

This is often used...

  int
  funcname (int arg1, ...)
  {
      ...
  }

Haven't seen this on the DOS/Windows side of things.  I'm guessing it's for
search purposes, perhaps in vi... ??

  /^funcname

... or is there another reason?

That's the reason, although with ctags it's kind of a moot point.

 

[Flash Gordon]

You can run a single instance of Emacs with windows displayed on
different computers, so it's possible for two people to edit the same
file at the same time and see each others' changes as they are typed.

We did not have tools that sophisticated, my point was that it is easy
to manage even with large files and no fancy technology as long as you
follow sensible development practice.