Rob Myers | 1 Feb 2003 12:05

RE: Seeking Crufty Code

Alex,

Joshua may have a perfect example for you.  We used it in his Testing &
Refactoring Workshop, and it has every single code smell from Fowler's book.
It was written entirely test-first, so it has complete test coverage.

And you wouldn't believe how hard it was to write bad code using TDD!  Why
is it so easy without tests?  Who would ever write another line of
production code without a failing test?  (Why do I get so chatty at 2AM?)

I'm not sure whether or not the snippet meets your third requirement, but it
never hurts to ask, yes?

Sincerely,

Rob

> -----Original Message-----
> From: Alex Chaffee / Purple Technology [mailto:alex <at> jguru.com]
> Sent: Wednesday, January 22, 2003 3:24 PM
> To: refactoring list
> Subject: [refactoring] Seeking Crufty Code
>
>
> I'm running an open refactoring workshop next week, and I'm looking
> for source code for us to refactor.  It should be
>
> * messy, but probably not a complete disaster
>
> * fairly well unit tested (so we can tell if we broke it)
(Continue reading)

Sebastian.Dietrich | 1 Feb 2003 11:48
Picon

Sebastian DIETRICH/RAIBAU/AT ist nicht mehr in der Raibau beschäftigt

Ich werde ab  01.02.2003 nicht im Büro sein. Ich kehre zurück am
31.12.2003.

Bitte kontaktieren Sie mich über Sebastian.Dietrich <at> anecon.com

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Sebastian.Dietrich | 1 Feb 2003 11:59
Picon

Sebastian DIETRICH/RAIBAU/AT ist nicht mehr in der Raibau beschäftigt

Ich werde ab  01.02.2003 nicht im Büro sein. Ich kehre zurück am
31.12.2003.

Bitte kontaktieren Sie mich über Sebastian.Dietrich <at> anecon.com

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Sebastian.Dietrich | 1 Feb 2003 12:02
Picon

Sebastian DIETRICH/RAIBAU/AT ist nicht mehr in der Raibau beschäftigt

Ich werde ab  01.02.2003 nicht im Büro sein. Ich kehre zurück am
31.12.2003.

Bitte kontaktieren Sie mich über Sebastian.Dietrich <at> anecon.com

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Sebastian.Dietrich | 1 Feb 2003 12:04
Picon

Sebastian DIETRICH/RAIBAU/AT ist nicht mehr in der Raibau beschäftigt

Ich werde ab  01.02.2003 nicht im Büro sein. Ich kehre zurück am
31.12.2003.

Bitte kontaktieren Sie mich über Sebastian.Dietrich <at> anecon.com

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Martin Lippert | 2 Feb 2003 13:17
Picon
Favicon
Gravatar

Large Refactorings Workshop

Hi!

I discussed the topic of larger refactorings with some of you a few 
months ago and the idea of a workshop came up. So here we are: Stefan 
Roock and I are organizing a workshop on "Large Refactorings" at OT 2003 
and we just thought some of you might be interested. The goal of the 
150minutes workshop is to share experiences, create a common 
understanding of the term "Large Refactoring" and discuss common 
problems and solutions for Large Refactorings. A more detailed 
description can be found at:

http://www.ot2003.org/scripts/wiki/ot2003/?KkbadcfcaghgpdjfbfhjadiptdialinnetKk

Our session is one of many at the OT2003 conference. To attend you will 
need to register for the full conference. Pricing details and the full 
programme of sessions can be found at www.ot2003.org

Thanks again and hope to see some of you at the workshop.

- Martin

---
Martin Lippert
email: lippert <at> acm.org

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

(Continue reading)

Peter Breton | 2 Feb 2003 14:39
Picon
Favicon

Re: Digest Number 372


> Ich werde ab  01.02.2003 nicht im Büro sein. Ich 
> kehre zurück am 31.12.2003.

If I'm reading this correctly, that's one heck of a
vacation! (from Feb 1st to Dec 31st).

Peter

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Shimon Rura | 2 Feb 2003 18:41
Gravatar

Brevity Driven Development?

Has anyone considered adopting length limits as a coding convention?  This
exceedingly strange idea occured to me yesterday: if you are forced to keep
your units of abstraction (classes, methods, etc.) small, you will be
pressured to break down their complexity into other units of abstraction.
In order to keep track of the many units of abstraction at work in your own
code, you'll probably want to give them good names, and you'll probably want
to express their relative structure in other ways, such as thoughtful
packaging.  The basic rules could be:

1. No class may require more than 200 lines of code.
2. No method may require more than 40 lines of code.

A little bit of good faith is required to not abuse inheritance and such,
but this incredibly easy-to-calculate metric might help good developers
prioritize good factoring of their code.

What do you think: excessive and heavyhanded, or potentially useful?

shimon.

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

RE: Brevity Driven Development?

How do you calculate lines?  Do you include white space and comments?

I find that writing EJBs (at least according to the EJB 1.1 spec.) would be
difficult given the numbers that you have suggested.  An Entity Bean for a
table with a large number of columns could easily exceed 200 lines.
However, I find that 40 lines per method is too large most of the time;
exception handling, though, can sometimes cause a method to be that large.

All that said, I do tend to use line count as a guide for whether
refactoring is needed.  If I know the abstraction is simple, yet the line
count is very high, it's an indicator for me to take a look at the code.

Craig

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Re: Brevity Driven Development?

> Has anyone considered adopting length limits as a coding convention?

You might want to look at the Chidamber and  Kemerer (C-K) set of O-O
metrics which list these and other "measures of goodness" of code.

Dave P

"I love deadlines, I especially like the whooshing noise they make as they
go hurtling by" :Douglas Adams

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 


Gmane