Refactoring

Michael Feathers | 1 Dec 2004 15:37

Re: C# Refactoring -- Replace Type Code with Class


<grin> That's a little severe.  The dependency isn't eliminated when you 
use reflection, it's hidden.  You end up with a use of a concrete class 
that may not be as easy to find with a search. 

There are tradeoffs and there is no one right answer, however if 
dependency is problem, you can put up a recompilation firewall around 
this class.  Make the static factory method non-static and use 
dependency inversion to keep clients of BloodGroup from recompiling.  
BloodGroup wouldn't have to use reflection but it also wouldn't force 
clients to recompile.  If BloodGroup does much more than house the 
factory method, it would make sense to extract the factory method to 
another class.  When responsibilities are separated the dependency 
situation often improves.

Michael Feathers
www.objectmentor.com
http://butunclebob.com/ArticleS.MichaelFeathers.TheNewGuy

> *My comment is to all readers using C#. It is SO evil to have a switch 
> statement in your factory method!*
> ** 
> *Why? Because you create a UML dependency from the Base class BACK to 
> each child and to add a new child you need a recompile. Here is the 
> correct way in C#  to to a factory (and  it is fine if the Static 
> factory in the abstractclass - You eliminate an unneeded class..):*
> ** 
>
> *public 
> static AbstractWHATEVER  CreateChildr( String StringAssembly, String

(Continue reading)

headers

Jay Bazuzi | 1 Dec 2004 19:15

RE: Re: Size of a Method

I hate horizontal scrolling.  I try to keep to 80-character lines.  I
try to make identifier names as clear & succinct as possible.

In case you haven't noticed, I'm trying to do the simplest thing that
could possibly work...

	-Jay
	http://blogs.msdn.com/jaybaz_MS
	Ask me about jobs in C#.

-----Original Message-----
From: Marian Olteanu [mailto:marianolteanu <at> yahoo.com] 
Sent: Saturday, November 27, 2004 10:38 PM
To: refactoring <at> yahoogroups.com
Subject: [refactoring] Re: Size of a Method

--- In refactoring <at> yahoogroups.com, "Jay Bazuzi" <jaybaz <at> m...> wrote:
> I strive to make my methods one line long.  If they need to be any
> longer, I need a strong justification.
> 

How long are your lines? How long are your identifiers? Can you write 
these kind of methods without being required to do horizontal 
scrolling (which is much worst than vertical scrolling)?

--------------
Marian Olteanu
http://www.utdallas.edu/~mgo031000/

(Continue reading)

headers

John Carter | 1 Dec 2004 23:44

Pouring factoids into the thread bound wound of time....Re: Size of a Method

On Mon, 22 Nov 2004, raitulsi wrote:

>  Is there any limit as far as the number of lines of codes that
> would make a method ideal is concerned? thanks.

I would have thought this very long thread would have at some stage fallen 
across this stream of factoids... (Plenty of stuff for discussion on 
this web page...)

Extracted from...

   http://www.softwarelogics.co.uk/sl_facts.html

The optimal length for the name of a routine is 9-15 characters. 
McConnell (1993), p.81

Up to 90% of code can be dedicated to error and exception handling, 
housekeeping, etc., with as little as 10% for cases for which the system 
was nominally built. 	Shaw in Bentley (1982) 	McConnell (1993), p.40

Extremely modularised code (eg, 10 lines per routine) is no easier to read 
than completely unstructured code. Breaking code into routines of about 25 
lines increases comprehension by up to two thirds. 	Conte, Dunsmore & 
Shen (1986) 	McConnell (1993), p.93

Larger routines (more than 65 lines of code) are cheaper to develop (per 
line of code). 	McConnell (1993), p.93

A routines size is inversely correlated to the number of errors in it: the

(Continue reading)

headers

Jim Cheesman | 2 Dec 2004 09:24

RE: Pouring factoids into the thread bound wound of time....Re: Size of a Method

Are there no similar data post 1993? If I'm not mistaken the data are taken
from Code Complete, an excellent book that does however predate OOP - I'm
sure many of the points are still relevant, but I do wonder what influence
modern IDEs and programming practices have on these results.

Regards,
Jim

> -----Mensaje original-----
> De: John Carter [mailto:john.carter <at> tait.co.nz]
> Enviado el: miercoles, 01 de diciembre de 2004 23:45
> Para: refactoring <at> yahoogroups.com
> Asunto: Pouring factoids into the thread bound wound of time....Re:
> [refactoring] Size of a Method
>
>
>
> On Mon, 22 Nov 2004, raitulsi wrote:
>
> >  Is there any limit as far as the number of lines of codes that
> > would make a method ideal is concerned? thanks.
>
> I would have thought this very long thread would have at some
> stage fallen
> across this stream of factoids... (Plenty of stuff for discussion on
> this web page...)
>
>
> Extracted from...

(Continue reading)

headers

tim dugan | 2 Dec 2004 16:01

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method

This is interesting, although some of the dates (e.g., "Shaw in Bentley (1982)") lead me to believe some of these statistics are pre-OOP/OOD. And some of them are contradictory to one another.

This one in particular seems dubious:

"A routines size is inversely correlated to the number of errors in it: the bigger the better. Basili & Perricone (1984) McConnell (1993), p.93"

Consider this case:

public class XYZ

{

int _length = 0;

...

public int getLength() {return _length;}
}

Doesn't get much shorter...so this method would have the most errors?

I'm reminded of this old statistic: "Most accidents occur within X miles/kilometres of home", which makes "home" sound like a dangerous place to be. But it ignores the factor of what percentage driving takes place near home. (see http://www.philiphunt.com/id278.htm)

But good statistics are helpful to clarify this matter. And I don't have any. :(

My own point of view...methods too long are tough to unit test, read, maintain and debug. But length is definitely not the only factor. In "application level" code, most developers seem to have a harder time writing good, modular code with succinct methods. But at lower-levels in more reusable components, it seems easier.

-td

John Carter <john.carter <at> tait.co.nz> wrote:

On Mon, 22 Nov 2004, raitulsi wrote:

> Is there any limit as far as the number of lines of codes that
> would make a method ideal is concerned? thanks.

I would have thought this very long thread would have at some stage fallen
across this stream of factoids... (Plenty of stuff for discussion on
this web page...)

Extracted from...

   http://www.softwarelogics.co.uk/sl_facts.html

The optimal length for the name of a routine is 9-15 characters.
McConnell (1993), p.81

Up to 90% of code can be dedicated to error and exception handling,
housekeeping, etc., with as little as 10% for cases for which the system
was nominally built.   & nbsp;   Shaw in Bentley (1982)       McConnell (1993), p.40

Extremely modularised code (eg, 10 lines per routine) is no easier to read
than completely unstructured code. Breaking code into routines of about 25
lines increases comprehension by up to two thirds.       Conte, Dunsmore &
Shen (1986)       McConnell (1993), p.93

Larger routines (more than 65 lines of code) are cheaper to develop (per
line of code).       McConnell (1993), p.93

A routines size is inversely correlated to the number of errors in it: the
bigger the better.       Basili & Perricone (1984)       McConnell (1993),
p.93

Small routines (32 lines or less) are neither less expensive nor less
faulty.       Card, Church & Agresti (186); Card & Glass (1990)
McConnell (1993), p.93

A study of 450 routines showed that small routines (up to 143 lines of
code) had 23% more errors than large ones.       Selby and Basili (1991)
McConnell (1993), p.93

The number of errors in a routine does not correlate with its size, though
it does reflect its structural complexity and the amount of data.
Shen et al. (1985)       McConnell (1993), p.93

The code that needs least changes averages 100-150 lines per routine.
Lind & Vairavan (1989)       McConnell (1993), p.93

IBM found that the most buggy routines were over 500 lines in length. The
code that needs least changes averages 100-150 lines per routine.
Thereafter, the error rate is proportional to routine size.       Jones
(1986a)       McConnell (1993), p.94

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter <at> tait.co.nz
New Zealand

The universe is absolutely plastered with the dashed lines exactly one
space long.

Tim Dugan

Do you Yahoo!?
Meet the all-new My Yahoo!

headers

Michael New | 2 Dec 2004 18:41

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method


tim dugan wrote:

>  
> I'm reminded of this old statistic:  "Most accidents occur within X 
> miles/kilometres of home", which makes "home" sound like a dangerous 
> place to be.  But it ignores the factor of what percentage driving takes 
> place near home.  (see http://www.philiphunt.com/id278.htm)
>  
>  
> But good statistics are helpful to clarify this matter.  And I don't 
> have any. :(

A recently heard quote:

"Statistics are like bikinis -
     what they reveal is interesting but what they hide is critical."

Mike
----------------------------- _/ /\/\ /\/ --------------------------
J. Michael New                                mailto:mike <at> noozoo.com
1-613-796-0652                                http://www.noozoo.com/

          - Michael New is absolutely right and
             Bill Clinton is absolutely wrong.
                                            - Pat Buchanan
--------------------------------------------------------------------

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/umvwlB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

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

headers

Randy MacDonald | 2 Dec 2004 21:50

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method


----- Original Message ----- 
From: "Michael New" <mike <at> noozoo.com>
To: <refactoring <at> yahoogroups.com>
Sent: Thursday, December 02, 2004 12:41 PM
Subject: Re: Pouring factoids into the thread bound wound of time....Re:
[refactoring] Size of a Method

>
> tim dugan wrote:
>
> >
> > I'm reminded of this old statistic:  "Most accidents occur within X
> > miles/kilometres of home", which makes "home" sound like a dangerous
> > place to be.  But it ignores the factor of what percentage driving takes
> > place near home.  (see http://www.philiphunt.com/id278.htm)
> >
> >
> > But good statistics are helpful to clarify this matter.  And I don't
> > have any. :(
>
>
> A recently heard quote:
>
> "Statistics are like bikinis -
>      what they reveal is interesting but what they hide is critical."
>
>
> Mike
> ----------------------------- _/ /\/\ /\/ --------------------------
> J. Michael New                                mailto:mike <at> noozoo.com
> 1-613-796-0652                                http://www.noozoo.com/
>
>           - Michael New is absolutely right and
>              Bill Clinton is absolutely wrong.
>                                             - Pat Buchanan
> --------------------------------------------------------------------

My experience is that her mouth tends to be the critical part.

Later...
-----------------------------------------------------------------------
|\/| Randy A MacDonald             | you can't pay for it,
|\\| randymacdo <at> rogers.com         |       even if you want to.
     BSc(Math) UNBF'83 Sapere Aude | APL: If you can say it, it's done..
     Natural Born APL'er           | demo website: http://24.43.158.135/
------------------------------------------------------------{ gnat }-

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/umvwlB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

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

headers

Brandon Hunt | 2 Dec 2004 18:21

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method


There probably is some more updated data in the second version of Code
Complete, but I haven't had a chance to read that one yet.  Too many
things on the "to-be-read" list, currently

I had noticed that while a large portion of Code Complete was helpful,
the statistics didn't really seem to be true (that was a couple of
years ago).

Brandon

On Thu, 2 Dec 2004 09:24:56 +0100, Jim Cheesman <mogrim <at> arrakis.es> wrote:
> 
> Are there no similar data post 1993? If I'm not mistaken the data are taken
> from Code Complete, an excellent book that does however predate OOP - I'm
> sure many of the points are still relevant, but I do wonder what influence
> modern IDEs and programming practices have on these results.
> 
> Regards,
> Jim
> 
> > -----Mensaje original-----
> > De: John Carter [mailto:john.carter <at> tait.co.nz]
> > Enviado el: miercoles, 01 de diciembre de 2004 23:45
> > Para: refactoring <at> yahoogroups.com
> > Asunto: Pouring factoids into the thread bound wound of time....Re:
> > [refactoring] Size of a Method
> 
> 
> >
> >
> >
> > On Mon, 22 Nov 2004, raitulsi wrote:
> >
> > >  Is there any limit as far as the number of lines of codes that
> > > would make a method ideal is concerned? thanks.
> >
> > I would have thought this very long thread would have at some
> > stage fallen
> > across this stream of factoids... (Plenty of stuff for discussion on
> > this web page...)
> >
> >
> > Extracted from...
> >
> >    http://www.softwarelogics.co.uk/sl_facts.html
> >
> > The optimal length for the name of a routine is 9-15 characters.
> > McConnell (1993), p.81
> >
> > Up to 90% of code can be dedicated to error and exception handling,
> > housekeeping, etc., with as little as 10% for cases for which the system
> > was nominally built.  Shaw in Bentley (1982)  McConnell (1993), p.40
> >
> > Extremely modularised code (eg, 10 lines per routine) is no
> > easier to read
> > than completely unstructured code. Breaking code into routines of
> > about 25
> > lines increases comprehension by up to two thirds.    Conte, Dunsmore &
> > Shen (1986)   McConnell (1993), p.93
> >
> > Larger routines (more than 65 lines of code) are cheaper to develop (per
> > line of code).        McConnell (1993), p.93
> >
> > A routines size is inversely correlated to the number of errors
> > in it: the
> > bigger the better.    Basili & Perricone (1984)       McConnell (1993),
> > p.93
> >
> > Small routines (32 lines or less) are neither less expensive nor less
> > faulty.       Card, Church & Agresti (186); Card & Glass (1990)
> > McConnell (1993), p.93
> >
> > A study of 450 routines showed that small routines (up to 143 lines of
> > code) had 23% more errors than large ones.    Selby and Basili (1991)
> > McConnell (1993), p.93
> >
> > The number of errors in a routine does not correlate with its
> > size, though
> > it does reflect its structural complexity and the amount of data.
> > Shen et al. (1985)    McConnell (1993), p.93
> >
> > The code that needs least changes averages 100-150 lines per routine.
> > Lind & Vairavan (1989)        McConnell (1993), p.93
> >
> > IBM found that the most buggy routines were over 500 lines in length. The
> > code that needs least changes averages 100-150 lines per routine.
> > Thereafter, the error rate is proportional to routine size.   Jones
> > (1986a)       McConnell (1993), p.94
> >
> >
> >
> > John Carter                             Phone : (64)(3) 358 6639
> > Tait Electronics                        Fax   : (64)(3) 359 4632
> > PO Box 1645 Christchurch                Email : john.carter <at> tait.co.nz
> > New Zealand
> >
> > The universe is absolutely plastered with the dashed lines exactly one
> > space long.
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/umvwlB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

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

headers

alphaeus_java | 2 Dec 2004 18:13

Off Topic: Managing Consultants IT (Financial Domain). Bangalore


Our client, a leading Global IT consulting firm is seeking Managing
Consultants (Project Managers) from IITs / RECs /IT-BHU/BITS Pilani &
other Premier institutes for their operations in Bangalore, 

The company operates in the financial/banking domain and has an
enviable client list, which includes 7 out of the top 10 Wall Street
giants. 

This company has a majority of their employees from premier institutes
and has a culture that nurtures high performance. 

Key Requirements:
1)	Experts in Java, UML
2)	Working on Investment/ Finance Domain
3)	Worked with clients like Bank of America, Merlin Lynch, Goldman
Sachs etc

If interested, please send in your resume to malathi  <at>  alphaeus.com,
If you need further information pl don't hesitate to call me on the
numbers below. Thanks. 

PS: If you have friends/colleagues who might be interested in this
opportunity please forward this mail to them. Appreciate it!

Regards,
Malathi
Alphaeus HR

malathi  <at>  alphaeus.com
Ph: 080 51216415/16

------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/umvwlB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

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

headers

alphaeus_java | 2 Dec 2004 18:05

Off Topic: Seeking Engineers from India Top 10 Universities. Bangalore


Our client, a leading Global IT consulting firm is seeking TOP NOTCH
software professionals from IITs / RECs /IT-BHU/BITS Pilani & other
Premier institutes for their operations in Bangalore, 

The company operates in the financial/banking domain and has an
enviable client list, which includes 7 out of the top 10 Wall Street
giants. 

This company has a majority of their employees from premier institutes
and has a culture that nurtures high performance. 

If you are working on any of the below mentioned skills we would like
to talk to you

1)	Java, UML
2)	C++ & MFC, COM
3)	.Net & C# Professionals
4)	C, Unix

Experience Required: 2+ years to 7 years (Consultants, Sr
Consultants/Leads)

Please send in your resume to malathi  <at>  alphaeus.com

If you have a friend or colleague who might be interested in this
opportunity please forward this mail to them Thanks. Appreciate it!

Regards,

Malathi
Alphaeus HR
malathi  <at>  alphaeus.com
Ph: 080 51216415/16

------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/umvwlB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

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

2	April 2013
4	December 2012
4	November 2012
21	October 2012
1	July 2012
1	June 2012
3	May 2012
2	April 2012
2	February 2012
17	December 2011
3	October 2011
35	September 2011
1	August 2011
4	July 2011
10	June 2011
1	May 2011
1	April 2011
2	March 2011
4	February 2011
11	January 2011
4	December 2010
14	November 2010
6	October 2010
23	September 2010
19	August 2010
9	June 2010
56	May 2010
1	April 2010
9	March 2010
40	February 2010
9	January 2010
19	December 2009
68	November 2009
25	October 2009
100	September 2009
13	August 2009
77	July 2009
5	June 2009
4	May 2009
24	April 2009
181	March 2009
82	February 2009
1	January 2009
12	December 2008
17	November 2008
20	September 2008
179	August 2008
177	July 2008
59	June 2008
41	May 2008
148	April 2008
149	March 2008
10	February 2008
39	January 2008
91	December 2007
10	November 2007
39	October 2007
63	September 2007
37	August 2007
18	July 2007
127	June 2007
20	May 2007
63	April 2007
40	March 2007
26	February 2007
65	January 2007
66	December 2006
55	November 2006
74	October 2006
119	September 2006
32	August 2006
11	June 2006
14	May 2006
47	April 2006
92	March 2006
17	February 2006
43	January 2006
55	December 2005
43	November 2005
69	October 2005
79	September 2005
141	August 2005
133	July 2005
113	June 2005
137	May 2005
107	April 2005
117	March 2005
51	February 2005
102	January 2005
147	December 2004
158	November 2004
107	October 2004
507	September 2004
334	August 2004
158	July 2004
76	June 2004
82	May 2004
63	April 2004
94	March 2004
62	February 2004
45	January 2004
94	December 2003
36	November 2003
163	October 2003
170	September 2003
262	August 2003
230	July 2003
206	June 2003
322	May 2003
194	April 2003
297	March 2003
329	February 2003
173	January 2003
159	December 2002
285	November 2002
161	October 2002
57	September 2002
117	August 2002
71	July 2002
118	June 2002
85	May 2002
210	April 2002
98	March 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Re: C# Refactoring -- Replace Type Code with Class

RE: Re: Size of a Method

Pouring factoids into the thread bound wound of time....Re: Size of a Method

RE: Pouring factoids into the thread bound wound of time....Re: Size of a Method

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method

Re: Pouring factoids into the thread bound wound of time....Re: Size of a Method

Off Topic: Managing Consultants  IT (Financial Domain). Bangalore

Off Topic: Seeking Engineers from India Top 10 Universities. Bangalore

Off Topic: Managing Consultants IT (Financial Domain). Bangalore