[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: renames under CVS

From: Noel Yap
Subject: RE: renames under CVS
Date: Tue, 26 Feb 2002 19:50:23 -0800 (PST)

--- "Greg A. Woods" <address@hidden> wrote:
>[ On Monday, February 25, 2002 at 16:27:09 (-0800),
>Glew, Andy wrote: ]
>> Subject: RE: renames under CVS
>> I can go through my own CVS repository, and count
>> (a) the number of times I have done file renames in
>the ad-hoc
>> klugey ways CVS now supports.
>> and 
>> (b) the number of files that are presently
>> whose names I have not changed, but whose names
>> be changed to match up to a coding standard like
>> (whose names I have not changed because CVS makes
>> painful).
>> I suppose that these would be normalized by the
>> of files, number of lines, number of developers,
>> Would these be acceptable metrics.

Oh, I forgot to add that moves are renames in general,
so please don't forget to count these, too, in your
(a) and (b) categories.

> That would be a very good start.  However it doesn't
> tell us how the
> picture would change if you'd done ideal, or even
> just better, planning
> of your modules and file structure before you first
> checked them into
> CVS.  I don't know how we could independently
> measure that part.

One of the side topics of this thread is XP.  You
wouldn't be doing XP if you do "ideal, or even just
better, planning of your modules".

Maybe if you did perfect planning and requirements
were static could you absolutely avoid renames, but we
all know this will never happen.

Also, moves are renames in the general sense, so they
should also be counted.

> We would also need a graph showing how many of those
> files could be
> harmlessly renamed in the repository (i.e. which
> have tags and branches,
> and which do not).

Why would files with tags and branches be any
worse/better off than those without?

> Finally of course we'd need to find some way to
> assess the difference
> between an ideal filename, and one that's suitable
> and sufficient for
> the purpose.  While we might all like to rename many
> of the files and
> directories in our projects, there's no fundamental
> necessity requiring
> us to rename files that are not "grossly" mis-named.

This measure would be extremely subjective.

> Eg. if you check in a C source module with a name of
> 'foo.txt' and only
> after it's been used somehow in a release you
> discover it and find you
> have to rename it to 'foo.c' because that's the only
> way it'll continue
> to work with your build system, well that's a really
> _necessary_
> rename.

Not really, you could build a rule into your build
system that created foo.c from foo.txt.

> You will have to do it regardless of the
> implications to your
> version and release management processes.  However
> if all you want to do
> is rename it to "bar.txt" because for you at this
> moment you now
> believe "bar" has more meaning to you, well then
> you're just giving
> emotional meaning to something that's irrelevant to
> the success of
> what's contained in the files and any kind of
> impediment to renaming
> should prevent you from doing any rename.

Meaningful names are important for long-term projects
therefore, there should be no impediment to renames
and moves in general.  If this weren't true, why not
just name our files 1.c, 2.c, ...

> I know of at least one very successfull programmer
> who names all his C
> source and header files with very plain and
> meaningless names
> (letterNUMBER.c).  

How do you define "successfull"?  (Is it the same as
"successful" :-)

>He doesn't use CVS -- in fact I'm
> not sure he uses
> any formal version tracking tool.  At least one of
> his programs is quite
> large -- over 40 files and over 50,000 lines of
> source.  He never has to
> worry about renaming files because he attaches no
> significance to their
> names.  (I don't know that he uses any kind of IDE
> that helps him
> navigate his programs, but regardless of the file
> names some kind of
> identifier search tool becomes invaluable on larger
> projects anyway, and
> on really large programs you'll eventually need to
> do deeper analysis on
> your source and draw call graphs and such too).

I'm guessing you don't include "being able to work
with others" as part of your criteria in assessing

Also, search tools will be useless if this programmer
were programming in Java since the class names would
be as meaningless as the filenames.  I suppose he then
could start relying heavily on comments.


Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]