Source Control and Refactoring

Source Control and Refactoring

Post by Tobin Harri » Sun, 29 Jun 2003 14:33:08



Hi there,

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

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? For my
team, this is a real pain becuase we like to revist our naming of classes
often, but then there's the whole drag of having to remove/re-add the
correcsponding file to CVS!!! Ideally some CVS tool would detect our
renaming antics and update the repository accordingly.  Or are we just lazy?
8-)

Cheers,

Tobes

 
 
 

Source Control and Refactoring

Post by Phli » Sun, 29 Jun 2003 23:21:22



> 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.

Quote:> 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

 
 
 

Source Control and Refactoring

Post by Tobin Harri » Mon, 30 Jun 2003 04:07:00


----- Original Message -----

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

 
 
 

Source Control and Refactoring

Post by Phli » Mon, 30 Jun 2003 05:56:04


Quote:> 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
*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.veryComputer.com/

 
 
 

Source Control and Refactoring

Post by Phli » Mon, 30 Jun 2003 13:13:24


Quote:> >One file per package is the recommendation of /Large Scale C++ Software
> >Design/. 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".

Quote:> >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.

> 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

 
 
 

Source Control and Refactoring

Post by Chris Dolli » Tue, 01 Jul 2003 16:42:45



> 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

 
 
 

Source Control and Refactoring

Post by Ilja Preu » Tue, 01 Jul 2003 22:58:52



> 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?

Yes.

Quote:> For my team, this is a real pain becuase we like to
> revist our naming of classes often, but then there's the whole drag
> of having to remove/re-add the correcsponding file to CVS!!! Ideally
> some CVS tool would detect our renaming antics and update the
> repository accordingly.  Or are we just lazy? 8-)

Eclipse does most of this automagically. It works great for Java. There is
also an official plugin for C++ and some open source ones for other
languages.

CVS still constitutes a problem when it comes down to merging conflicts
(like: someone changed something in a file while someone else renamed it).
Integrating more often reduces the pain, though.

Hope this helps, Ilja

 
 
 

Source Control and Refactoring

Post by Ilja Preu » Tue, 01 Jul 2003 22:59:48




>> 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

 
 
 

Source Control and Refactoring

Post by Chris Dolli » Tue, 01 Jul 2003 23:49:00





>>> 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

 
 
 

Source Control and Refactoring

Post by Paul Sinnet » Tue, 01 Jul 2003 23:54:29



>>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
>*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?
 
 
 

Source Control and Refactoring

Post by Tobin Harri » Wed, 02 Jul 2003 00:38:13



Quote:> > >One file per package is the recommendation of /Large Scale C++ Software
> > >Design/. 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

Quote:> --
>   Phlip

 
 
 

Source Control and Refactoring

Post by Phli » Wed, 02 Jul 2003 02:14:34


Quote:> > #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  --

 
 
 

Source Control and Refactoring

Post by Robert C. Mart » Wed, 02 Jul 2003 13:04:40



might not) have written this on (or about)  Sat, 28 Jun 2003 06:33:08
+0100, :

Quote:>Hi there,

>This is a bit of a silly question, but I'd be interested in comments!...

>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? For my
>team, this is a real pain becuase we like to revist our naming of classes
>often, but then there's the whole drag of having to remove/re-add the
>correcsponding file to CVS!!! Ideally some CVS tool would detect our
>renaming antics and update the repository accordingly.  Or are we just lazy?

No you aren't lazy.  It's important to remove any impediment to
improving your design.

Get a tool like IntelliJ.  It automatically changes file names in CVS
when you change class names.  It's also a kick-ass IDE!

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

1. To refactor or not to refactor

Right now I'm using cyclometric complexity as a guide in determining
when to refactor. IE if I have two methods each with a complexity of 2
(total complexity of 4 :-), and refactoring will yeald three methods,
one with a complexity of 2 and the other two with a complexity of 1
each, then I won't do the refactoring.

Of course, if I have 6 methods each with a complexity of 2 and I can
refactor so that I instead have 6 methods of complexity 1 and 1 method
with a complexity of 3. I'll do it because it reduces the complexity of
the system as a whole.

The basic idea is, if I can reduce the complexity of the system as a
whole by refactoring, I do it. If given two designs who's sums of all
the functions complexities are equal, I'll go with the design that
distributes the functionality more evenly.

I would like to hear pros/cons regarding this philosophy. TIA

(For those who don't know what cyclometric complexity is, think of it as
the number of decisions that must be made in the function + 1.

2. API function to get complete filename?

3. Can any open source compiler convert C++ source to C source?

4. Anyone seen a voice-responsive X10 controller?

5. New Source Control tools, every SourceSafe users should have a try with SourceCompanion.

6. GDI+ graphics being clipped when saved to file

7. WAV File and Joystick Controls, DLL, OCX or MFC C++ Source...

8. Last Ninja 4?!?

9. Looking for Control-3D sources

10. Microsoft Common Source Code Control Interface

11. Looking for source code to a multifont edit control.

12. Wanted: sample source for custom edit box control