Source Control and Refactoring

[Phlip]

Tobin Harris wrote:
This is a bit of a silly question, but I'd be interested in comments!...

Firstly, CVS is wonderful for file contents, and broken for folder contents.
If you rename a file you typically lose the revision history.

If you are in a position to beta-test another system, try Subversion.
In short, does anyone find that the CVS source-control system is a bit of
an obstacle to renaming classes, when your filenames mirror class names?

Your source controller should not inhibit your ability to rename. It stands
to reason file names should change as often as other names.

But why should file names mirror class names?

--
Phlip

[Tobin Harris]

----- Original Message -----
From: "Phlip" <phlipcpp@yahoo.com>
Newsgroups: comp.software.extreme-programming
Sent: Saturday, June 28, 2003 3:21 PM
Subject: Re: Source Control and Refactoring
But why should file names mirror class names?

Cheers for the comments Phlip! Yes, I suppose that's just the convention I'm
used to, do you have a different one? I'm using c# which is quite verbose,
in my opinion (meaning it takes quite a lot of code to say something!) When
I use Ruby, I find that it works well to put many classes in a single file -
but my approach is ad-hoc, and I've never tried it on anything big. So how
would you go about it - one file per 'package'!?

Tobes
-- Phlip

[Phlip]

> one file per 'package'!?

One file per package is the recommendation of /Large Scale C++ Software
Design/. Excellent book on physical design issues at all sizes.

The recommendation is "one file solves a problem". That means if I need to
screw in lightbulbs, I need only pull in...

#include "screw_in_lightbulbs.h"

That pulls in the vodka to make the room spin, the chanting Krishnas, the 12
union guys, everything.

So, following the rule "every .cpp file as a .h file with the same name", we
have more than one class per .cpp file.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Phlip]

> >One file per package is the recommendation of /Large Scale C++ SoftwareDesign/. Excellent book on physical design issues at all sizes. Yikes...been long enough since I've read this that I don't remember that recommendation, and I agree with most of what Lakos outlines in that book. I do agree with you...fantastic book. I'd disagree on one file per package. I strongly urge one class per file...helps a lot during maintenance. If XXX is named XXX.cpp and XXX.h, it's a lot easier to figure out what files you need. :)

He also says not to use namespaces. So if Lakos told us all to jump off a
cliff, should we do it? or should we learn from his methods?

But he uses the term "Component", which is "enough classes to work together
solving a problem on behalf of any one client .cpp file". I'd call that
smaller than a Package. And since he wouldn't have used nested classes at
all (portability), I think we could find a happy medium.

But my opprobrium is for wizards that teach newbies "one header per class".
The recommendation is "one file solves a problem". That means if I need
toscrew in lightbulbs, I need only pull in...#include "screw_in_lightbulbs.h"That pulls in the vodka to make the room spin, the chanting Krishnas, the
12union guys, everything. And when you need the vodka, the Krishnas, and the Polacks, you *still*
have to pull in the union guys. And when somebody is trying to update the
vodka, and somebody else is working on the union guys, you have merge issues with the single file.

That's why he introduces the "pimpl idiom". But at "design time" we should
prefer the Dependency Inversion Principle. He didn't have that tool, or
formal Refactoring. In his experience, reducing compile time was a chronic
emergency calling for repeated experiments to determine where his
bottlenecks were,
followed by mass refactors of individual physical design concepts into each
source file, while leaving the logical design as alone as possible: pimpl.

RefactorMercilessly also applies to reducing compile time, folks.

- make it work
- make it right
- make it compile fast
- make it fast
- make it small

Or switch to a language that trades compile time for run-time...

However Lakos also says this: The first line of screw_in_lightbulb.cpp
should be #include "screw_in_lightbulb.h".

That proves the .h file contains at least enough to compile itself and front
its features. So, following this rule, any work spent reducing .h's contents
(such as replacing a 'class Krishna{}' definition with a 'class Krishna;'
forward declaration) gets instantly tested when you compile
screw_in_lightbulb.cpp. So, on a super-large project (yes, I have flight
hours with such beasts), you only need compile one file to get a quick
check.

Then, if some other .cpp file breaks, you give it alone a new #include for
whatever it needed. This insulates everything that uses #include
"screw_in_lightbulb.h"

BTW I thought of a good answer about how broke CVS is regarding file names.
Don't rename a file. Start a new file, and incrementally refactor-in things
that belong in there.

--
Phlip

[Chris Dollin]

Phlip wrote:
But why should file names mirror class names?

Because Java is broken?

--
Chris "only one public class per file - bizarre." Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

[Ilja Preuß]

Chris Dollin wrote: Phlip wrote: But why should file names mirror class names? Because Java is broken?

Mhh, I don't typically have a problem with this convention. I still think it
is CVS which is broken...

Regards, Ilja

[Chris Dollin]

Ilja Preuß wrote:
Chris Dollin wrote: Phlip wrote: But why should file names mirror class names? Because Java is broken? Mhh, I don't typically have a problem with this convention. I still think it is CVS which is broken...

Oh, CVS is broken WRT renaming, no doubt about it. As for Java, there's
a difference between a convenient convention and a language mandate.

--
Chris "pfui" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

[Paul Sinnett]

Phlip wrote:one file per 'package'!? One file per package is the recommendation of /Large Scale C++ Software Design/. Excellent book on physical design issues at all sizes. The recommendation is "one file solves a problem". That means if I need to screw in lightbulbs, I need only pull in... #include "screw_in_lightbulbs.h"

I have this book but I don't remember this. I had a quick scan through
but I couldn't see "one file solves a problem" referenced anywhere. Can
you point me to the chapter?

[Tobin Harris]

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:EHtLa.96$ET4.82@newssvr31.news.prodigy.com...One file per package is the recommendation of /Large Scale C++ SoftwareDesign/. Excellent book on physical design issues at all sizes.
BTW I thought of a good answer about how broke CVS is regarding file
names. Don't rename a file. Start a new file, and incrementally refactor-in
things that belong in there.

That could be workable - good thinking (possibly) 8-)

Tobes
-- Phlip

[Phlip]

> > #include "screw_in_lightbulbs.h" I have this book but I don't remember this. I had a quick scan through but I couldn't see "one file solves a problem" referenced anywhere. Can you point me to the chapter?

Nope. Sorry. I lost the book years ago. But I (think I) learned a
helluva lot from it.

Maybe I should write down everything I think I remember about it, and
publish that as a book.

--
Phlip
http://c2.com/cgi/wiki?SheChangeDesignInTheDatabase
-- The first few lines of code must "hook" the
computer, and make it "care" about the program --

[Paul Sinnett]

Phlip wrote:I have this book but I don't remember this. I had a quick scan throughbut I couldn't see "one file solves a problem" referenced anywhere. Canyou point me to the chapter? Nope. Sorry. I lost the book years ago. But I (think I) learned a helluva lot from it. Maybe I should write down everything I think I remember about it, and publish that as a book.

So your argument from authority is really an argument from the memory of
authority.

[Phlip]

> > Maybe I should write down everything I think I remember about it, and publish that as a book. So your argument from authority is really an argument from the memory of authority.

Citing an author ain't an "argument from authority".

Try it like this: If you have a .cpp file, and you want to add
#include "screw_in_lightbulb.h" to it, you should not be required to
also add any other file. Syntactically, the .h file should take care
of all identifiers it needs, sometimes via sub-includes. Semantically,
adding the file should be enough to solve one problem. You should not
find yourself needed to add any other .h file just to be able to use
the core abilities of "screw_in_lightbulb.h".

<stdio.h> behaves like this: It provides the FILE abstraction, and all
its "member functions" fopen, fwrite, etc.

--
Phlip
http://www.greencheese.org/HatTrick
-- All analysis and no code makes Jack a dull boy.
All analysis and no code makes Jack a dull boy.
All analysis and no code makes Jack a dull boy. --