gmane.comp.programming.refactoring

Mockator CDT Eclipse plugin

Richard — 2013-04-16T20:02:22

Has anyone tried this?

<http://mockator.com/>

[announcement] Refactoring Dojo Workshop in London this June

Danijel Arsenovski — 2013-04-07T20:55:45

I am organizing a 3-day Refactoring Dojo Workshop in London in June in
collaboration with Skills Matter and thought that it might be of interest
to this group, so I am taking a liberty to share a few details regarding
the event.

You can find more information at:
http://bit.ly/RefDojoLondon

For a few years now Ive been teaching refactoring using the Dojo format
since I believe it emphasizes collaborative learning through problem
solving, is a form of deliberate practice applied to software
craftsmanship, teaches pair programming and swarming in addition  to
refactoring and is actually enjoyable and fun experience.

There is also a Bring Your Own Code part of the Dojo where participants
are invited to bring their own real life code to the Dojo where this code
is analyzed and refactored by the group.

You can check out the summary of the second day of the Dojo held this
January in Vancouver in the form of a video affinity map narrated by one of
the participants: http://www.youtube.com/watch?v=LH

Re: single return from function

Alfredo Chavez — 2012-12-11T16:10:33

 From chapter 9 "Simplifying conditional expressions":

    "I often find I use Replace Nested Conditional with Guard Clauses
    when I'm working with a programmer who has been taught to have only
    one entry point and one exit point from a method. One entry point is
    enforced by modern languages, and one exit point is really not a
    useful rule. Clarity is the key principle: if the method is clearer
    with one exit point, use one exit point; otherwise don't."

Does that clarify the issue?

El 11/12/2012 03:14 a.m., Willem Bogaerts escribió:



[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest< at >yahoogroups.com 
    r

Re: single return from function

Willem Bogaerts — 2012-12-11T09:14:04

I don't know the book by heart, but it makes a lot of sense. A return
statement is effectively a "goto end" statement. And I hope we all know
why gotos are bad.

That said, it is a pain to extract code with more than one return
statement into its own method, as it still means "goto end", but the
endpoint has changed.

But...

Off course there are some things that may be bad, but only
theoretically. As others have already remarked, a guard clause as a
first statement is OK. Why? Simple: you can only extract the code with
or without that first statement, and in both cases the behaviour is
preserved. The other case is putting the return statement as the last
statement in the function, as it makes the "goto" part of the meaning
irrelevant. And that is where the single point of exit comes from.

Best regards,

Willem Bogaerts.


------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individ

Re: single return from function

Alfredo Chávez — 2012-12-11T02:58:27

It's not true. Actually, the use of guard clauses goes explicitly against such thing. Single point of result is a valuable rule of thumb, but it becomes less so as your methods become shorter.


Enviado desde Samsung Mobile

alex_us01 <alex_us01< at >yahoo.com> escribió:

On the internet, I found somewhere* that the Refactoring book advocates for a single return from a function (thus, promoting assigning values to a variable, such as result, and then say return result; at the end).

Is that true?

I couldn't find it anywhere in the online catalog.

Thanks!

* see item 8 (might change)
http://www.javalobby.org/forums/thread.jspa?forumID=61&threadID=16937




[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (

RE: single return from function

Amir Kolsky — 2012-12-11T01:51:16

Supposedly makes compiler optimizations easier - you may ignore this at this
point in life.

From: refactoring< at >yahoogroups.com [mailto:refactoring< at >yahoogroups.com] On
Behalf Of alex_us01
Sent: Thursday, November 15, 2012 6:09 PM
To: refactoring< at >yahoogroups.com
Subject: [refactoring] single return from function

On the internet, I found somewhere* that the Refactoring book advocates for
a single return from a function (thus, promoting assigning values to a
variable, such as result, and then say return result; at the end).

Is that true?

I couldn't find it anywhere in the online catalog.

Thanks!

* see item 8 (might change)
http://www.javalobby.org/forums/thread.jspa?forumID=61
<http://www.javalobby.org/forums/thread.jspa?forumID=61&threadID=16937>
&threadID=16937

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:

Re: single return from function

Jeff Langr — 2012-11-16T05:21:10


Keith is spot on.

I have a slightly amusing story about hearing that "rule" a couple times at
the same place in the space of a few days:
http://langrsoft.com/jeff/2011/10/dont-stop-reading/

Jeff

Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com - Agile in a Flash: A top 20 agile book! (
http://www.noop.nl/2010/08/top-100-agile-books.html)


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest< at >yahoogroups.com 
    refactoring-fullfeatured< at >yahoogroups.com

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

<*> Your use of Yahoo! Groups is subject to:
    http

RE: single return from function

Mark Miller — 2012-11-16T04:07:53

I prefer guard clauses at the top of method blocks (see also programming by
contract) as they keep the remaining code unindented and easier to read.
Methods should be small, and multiple returns at the top are totally fine. 

Large methods with returns scattered throughout are harder to read, harder
to reuse, and often serve multiple purposes (e.g., they should be broken
into two or more smaller methods).

- Mark Miller

-----Original Message-----
From: refactoring< at >yahoogroups.com [mailto:refactoring< at >yahoogroups.com] On
Behalf Of Keith Ray
Sent: Thursday, November 15, 2012 7:40 PM
To: refactoring< at >yahoogroups.com
Subject: Re: [refactoring] single return from function

I don't think the Refactoring book makes that recommendation. That advice
dates back to "structured programming" (google it).

In a long function, multiple returns are hard to see, and may require
duplicated code. In less smelly code, after refactoring, a function is
typically less than 10 lines long, and could have a few early returns (see
"gua

Re: single return from function

Keith Ray — 2012-11-16T03:39:38

I don't think the Refactoring book makes that recommendation. That advice dates back to "structured programming" (google it).

In a long function, multiple returns are hard to see, and may require duplicated code. In less smelly code, after refactoring, a function is typically less than 10 lines long, and could have a few early returns (see "guard clause") in addition to the final return statement.

On 2012 Nov 15, at 6:09 PM, alex_us01 wrote:




[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest< at >yahoogroups.com 
    refactoring-fullfeatured< at >yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    refactoring

single return from function

alex_us01 — 2012-11-16T02:09:24

On the internet, I found somewhere* that the Refactoring book advocates for a single return from a function (thus, promoting assigning values to a variable, such as result, and then say return result; at the end).

Is that true?

I couldn't find it anywhere in the online catalog.

Thanks!

* see item 8 (might change)
http://www.javalobby.org/forums/thread.jspa?forumID=61&threadID=16937




------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest< at >yahoogroups.com 
    refactoring-fullfeatured< at >yahoogroups.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/

RE: Refactoring process model,

Aisha Fernandes — 2012-10-29T14:10:09

Hi
It was great to see a prompt reply from you. Thanks for your suggestions too.
What i actually intend doing is to take a business process model (diagram) and try to figure out the dead paths/processes if any and also to find clone processes.
This is just a thought...really do not know how i am going to go about doing it.if you do have some ideas, please share them with me.
thanking you in anticipationaisha

--- On Sun, 28/10/12, Amir Kolsky <kolsky< at >actcom.net.il> wrote:

From: Amir Kolsky <kolsky< at >actcom.net.il>
Subject: RE: [refactoring] Refactoring process model,
To: refactoring< at >yahoogroups.com
Date: Sunday, 28 October, 2012, 12:21 AM

      Well... Refactoring a system means changing its internal structure without

changing its behavior. I would guess that for a process with a specified

input and output, you can change the internal steps without changing the

outcome. 

The problem with the definition of refactoring is that what is construed to

be the 'beh

Re: Refactoring process model,

rd.naik — 2012-10-29T05:12:29

The stated objective implies that the current (existing) process has subtantial duplicated steps/tasks, the current process is unclear (meaning that it is not clear to the developer from the process description or the process implementation what the process does and how the process does whatever it is expected to do), and also that the process has possible dead tasks or steps.
Given the above scenarios, a few questions that come to mind are:
1) Do you intend to "detect" or "identify" the locations of the above problems in the process model, or do you already know the locations?
2) In what form is the process given to you? Is it in the form of process desciption (text), or process models (some formal representation), or an implementation of the process (source code)?
3) After re-factoring the process, what do you expect to deliver? A document of the re-factored process? A re-factored process model? A re-facctored implementation of the process?

Am asking the above questions only to understand more details of

Re: Refactoring process model,

rd.naik — 2012-10-29T08:37:06

The stated objective implies that the current (existing) process has subtantial duplicated steps/tasks, the current process is unclear (meaning that it is not clear to the developer from the process description or the process implementation what the process does, and how the process does whatever it is expected to do), and also that the process has possible dead / unreachable tasks or steps.

Given the above scenarios, a few questions that come to mind are:
1) Do you intend to "detect" or "identify" the locations of the above problems in the process model, or do you already know the locations?
2) In what form is the process given to you? Is it in the form of process desciption (text), or process models (some formal representation), or an implementation of the process (source code)?
3) After re-factoring the process, what do you expect to deliver? A document of the re-factored process? A re-factored process model? A re-factored implementation of the process?

Am asking the above questions only to understand

Re: Refactoring process model,

Adrian Howard — 2012-10-28T21:56:16

Maybe even both!

Adrian


------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest< at >yahoogroups.com 
    refactoring-fullfeatured< at >yahoogroups.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/

Re: Refactoring process model,

Adam Sroka — 2012-10-28T21:31:05

I think that refactoring, like testing, can be done to benefit the
programmer or the customer. I think that programmer refactoring, like
programmer testing, is about safety. And, I think that corporations have
proven time and again that profit can trump safety. So, it is our job as
professionals to tell them to go shove it. We aren't going to do things as
programmers that make us less safe.

I also think that the *technique* of refactoring can be used to achieve
some non-functional customer goal written on a storycard (or elsewhere.) It
is important to me to keep these two things separate for the same reason
that it is important to keep customer and programmer testing separate (and
acknowledge that neither is truly optional.)

On Sun, Oct 28, 2012 at 12:54 PM, Amir Kolsky <kolsky< at >actcom.net.il> wrote:



[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

RE: Refactoring process model,

Amir Kolsky — 2012-10-28T19:54:39

Sorry if I was not clear - what I was saying is that you never just refactor
to improve design. Improving the design is a means to an end -- even simply
cleaning up the code after you worked with it to create clarity or eliminate
redundancy is done to improve maintainability. 

There is always a business motivation.

-----Original Message-----
From: refactoring< at >yahoogroups.com [mailto:refactoring< at >yahoogroups.com] On
Behalf Of Adam Sroka
Sent: Sunday, October 28, 2012 12:51 PM
To: refactoring< at >yahoogroups.com
Subject: Re: [refactoring] Refactoring process model,

Sure, but if you simply say that you can use refactoring to improve any of
these aspects you lose an important distinction. In XP we refactor all of
the time, and that refactoring is explicitly for the purpose of making the
code easy to understand and work with (i.e. "good design.") We might also
refactor to improve performance or some other customer-facing quality, but
to do that we first need to work with the customer to get a realistic
threshold, w

Re: Refactoring process model,

Adam Sroka — 2012-10-28T19:51:28

Sure, but if you simply say that you can use refactoring to improve any of
these aspects you lose an important distinction. In XP we refactor all of
the time, and that refactoring is explicitly for the purpose of making the
code easy to understand and work with (i.e. "good design.") We might also
refactor to improve performance or some other customer-facing quality, but
to do that we first need to work with the customer to get a realistic
threshold, write tests for it, determine if the current performance is
acceptable, use a profiler to find out where to optimize, etc. That's a
different activity from mere refactoring.

On Sun, Oct 28, 2012 at 12:42 PM, Amir Kolsky <kolsky< at >actcom.net.il> wrote:



[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http:/

RE: Refactoring process model,

Amir Kolsky — 2012-10-28T19:42:26

Performance, extensibility, scalability....

-----Original Message-----
From: refactoring< at >yahoogroups.com [mailto:refactoring< at >yahoogroups.com] On
Behalf Of Adam Sroka
Sent: Sunday, October 28, 2012 12:39 PM
To: refactoring< at >yahoogroups.com
Subject: Re: [refactoring] Refactoring process model,

I get what you are saying. I suppose there are a number of non-functional
aspects that can be improved through refactoring: comprehensibility,
modularity, maintainability, etc. The simple design model still works best
for me.

On Sun, Oct 28, 2012 at 12:30 PM, Amir Kolsky <kolsky< at >actcom.net.il> wrote:

maintain.

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring

Re: Refactoring process model,

Adam Sroka — 2012-10-28T19:38:49

I get what you are saying. I suppose there are a number of non-functional
aspects that can be improved through refactoring: comprehensibility,
modularity, maintainability, etc. The simple design model still works best
for me.

On Sun, Oct 28, 2012 at 12:30 PM, Amir Kolsky <kolsky< at >actcom.net.il> wrote:



[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest< at >yahoogroups.com 
    refactoring-fullfeatured< at >yahoogroups.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/

RE: Refactoring process model,

Amir Kolsky — 2012-10-28T19:30:28

The point is that you don't refactor to improve the design. You refactor to
improve the maintainability of your product. This is a behavioral aspect of
the product -- an ility, not functional.

-----Original Message-----
From: refactoring< at >yahoogroups.com [mailto:refactoring< at >yahoogroups.com] On
Behalf Of Adam Sroka
Sent: Saturday, October 27, 2012 10:03 PM
To: refactoring< at >yahoogroups.com
Subject: Re: [refactoring] Refactoring process model,

The only one that matters.

On Sat, Oct 27, 2012 at 3:07 PM, Amir Kolsky <kolsky< at >actcom.net.il> wrote:

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via

RE: Re: Refactoring process model,

Stephen Allen — 2012-10-28T10:05:10

This was good and straight forward. It works because the vast majority of
spreadsheet use treats it like a simplified database.

One of the arguments I continue to have with Patrick is over the
best/appropriate usage of spreadsheets. It runs along the lines of "Do we
have to restrict the the methods and constructs that we employ within
spreadsheets just so that we can impose styles which encourage high accuracy
(low error rates) - or even be susceptible to automatic refactoring?"

Patrick is inclined towards a convention of restrictive usage. I am not. I
good example of my rather anarchic approach is available at

http://acba.co.uk/SuDoku.htm

A question you might ask yourself is whether Sandro's proposals for
automated refactoring would operate effectively on this kind of spreadsheet?


Regards, Stephen Allen

-----Original Message-----
From: refactoring< at >yahoogroups.com [mailto:refactoring< at >yahoogroups.com] On
Behalf Of Danny Dig
Sent: 28 October 2012 03:45
To: refactoring< at >yahoogroups.com
Subject: Re: [refa