<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Refactoring Day 30 : Return ASAP</title>
	<atom:link href="http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/feed/" rel="self" type="application/rss+xml" />
	<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/</link>
	<description>Just another LosTechies site</description>
	<lastBuildDate>Thu, 13 Sep 2012 07:11:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
	<item>
		<title>By: Cameron Scott</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-571</link>
		<dc:creator>Cameron Scott</dc:creator>
		<pubDate>Tue, 25 Oct 2011 10:41:00 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-571</guid>
		<description>Great work dude!!! How do you write such article son complex problem so easily.
&lt;a href=&quot;http://healthconditions.edublogs.org/&quot; rel=&quot;nofollow&quot;&gt; Hair loss&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>Great work dude!!! How do you write such article son complex problem so easily.<br />
<a href="http://healthconditions.edublogs.org/" rel="nofollow"> Hair loss</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: George</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-463</link>
		<dc:creator>George</dc:creator>
		<pubDate>Fri, 24 Dec 2010 00:54:08 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-463</guid>
		<description>I&#039;ve been coding for about 20 years, and I disagree with this one, although I may be in the minority these days. I &quot;bend over backward&quot; to code so that every method&#039;s expected code path (aside from exceptions) has exactly one point-of-return - at the end. I usually manage to keep the code arrowheads to a minimum as well. My opinion and inclinations are aligned with Jake Tummond&#039;s FWIW statement. I deplore that advice is being given out to impressionable beginners and junior developers to code like this.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been coding for about 20 years, and I disagree with this one, although I may be in the minority these days. I &#8220;bend over backward&#8221; to code so that every method&#8217;s expected code path (aside from exceptions) has exactly one point-of-return &#8211; at the end. I usually manage to keep the code arrowheads to a minimum as well. My opinion and inclinations are aligned with Jake Tummond&#8217;s FWIW statement. I deplore that advice is being given out to impressionable beginners and junior developers to code like this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake Tummond</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-462</link>
		<dc:creator>Jake Tummond</dc:creator>
		<pubDate>Mon, 21 Sep 2009 03:04:25 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-462</guid>
		<description>Also, FWIW, I hate reading code with early returns.  I worked with a fellow who made it his mission to refactor deeply nested code this way.  I found it impossible to read and since he left, I&#039;ve been slowly doing it the right way.  If your code is deeply nested, I don&#039;t think early returns are the way to fix it.  It is better to study the problem an fix it by modularizing.</description>
		<content:encoded><![CDATA[<p>Also, FWIW, I hate reading code with early returns.  I worked with a fellow who made it his mission to refactor deeply nested code this way.  I found it impossible to read and since he left, I&#8217;ve been slowly doing it the right way.  If your code is deeply nested, I don&#8217;t think early returns are the way to fix it.  It is better to study the problem an fix it by modularizing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake Tummond</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-461</link>
		<dc:creator>Jake Tummond</dc:creator>
		<pubDate>Mon, 21 Sep 2009 03:01:15 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-461</guid>
		<description>Enjoying the series, although I seem to be reading from end to beginning.

Why make this function impure by passing a Customer object?  I would extract everything but the assignment into a pure static function.

Second, it seems some corner cases are uncovered?  What happens if discount &gt; orderTotal?  Do you send customer some money?  Maybe it&#039;s an exception?

Finally, I think Sum will return zero for an empty list.

I would probably rewrite as:
{
  decimal orderTotal = products.Sum(p =&gt; p.Price);
  return Math.Max(0, orderTotal - discount);
}</description>
		<content:encoded><![CDATA[<p>Enjoying the series, although I seem to be reading from end to beginning.</p>
<p>Why make this function impure by passing a Customer object?  I would extract everything but the assignment into a pure static function.</p>
<p>Second, it seems some corner cases are uncovered?  What happens if discount > orderTotal?  Do you send customer some money?  Maybe it&#8217;s an exception?</p>
<p>Finally, I think Sum will return zero for an empty list.</p>
<p>I would probably rewrite as:<br />
{<br />
  decimal orderTotal = products.Sum(p => p.Price);<br />
  return Math.Max(0, orderTotal &#8211; discount);<br />
}</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: colinjack</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-460</link>
		<dc:creator>colinjack</dc:creator>
		<pubDate>Wed, 02 Sep 2009 07:31:55 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-460</guid>
		<description>To me thats introducing a guard.</description>
		<content:encoded><![CDATA[<p>To me thats introducing a guard.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mbrown77@gmail.com</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-459</link>
		<dc:creator>mbrown77@gmail.com</dc:creator>
		<pubDate>Tue, 01 Sep 2009 15:04:03 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-459</guid>
		<description>@Udit: A Try Finally works great if you&#039;re doing Pre/Post Processing.</description>
		<content:encoded><![CDATA[<p>@Udit: A Try Finally works great if you&#8217;re doing Pre/Post Processing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Dingwall</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-458</link>
		<dc:creator>Richard Dingwall</dc:creator>
		<pubDate>Tue, 01 Sep 2009 09:10:44 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-458</guid>
		<description>Arrowheads are one of the most common smells I see in legacy code. Replacing huge nested IFs with guard clauses and early bail-outs is always one of the first things I do, and it works wonders to simplify long functions down so they are ready for extract method etc.

Udit: I would do begin and end of function logging as in the caller or with a using() block.</description>
		<content:encoded><![CDATA[<p>Arrowheads are one of the most common smells I see in legacy code. Replacing huge nested IFs with guard clauses and early bail-outs is always one of the first things I do, and it works wonders to simplify long functions down so they are ready for extract method etc.</p>
<p>Udit: I would do begin and end of function logging as in the caller or with a using() block.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Udit Handa</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-457</link>
		<dc:creator>Udit Handa</dc:creator>
		<pubDate>Mon, 31 Aug 2009 09:04:13 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-457</guid>
		<description>Even I disagree on this. What if we are doing begin and end of function logging. We have to write the same code everywhere we return. </description>
		<content:encoded><![CDATA[<p>Even I disagree on this. What if we are doing begin and end of function logging. We have to write the same code everywhere we return. </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pavan Kulkarni</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-456</link>
		<dc:creator>Pavan Kulkarni</dc:creator>
		<pubDate>Mon, 31 Aug 2009 05:20:59 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-456</guid>
		<description>Sean,
Great job here! I&#039;ve been following your refactoring series all along. However, I don&#039;t agree to this particular refactoring method. Pre-mature returns, I&#039;ve been told, should never be encouraged.</description>
		<content:encoded><![CDATA[<p>Sean,<br />
Great job here! I&#8217;ve been following your refactoring series all along. However, I don&#8217;t agree to this particular refactoring method. Pre-mature returns, I&#8217;ve been told, should never be encouraged.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jordi</title>
		<link>http://lostechies.com/seanchambers/2009/08/28/refactoring-day-30-return-asap/#comment-455</link>
		<dc:creator>Jordi</dc:creator>
		<pubDate>Sun, 30 Aug 2009 15:23:02 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/08/28/refactoring-day-30-return-asap.aspx#comment-455</guid>
		<description>Why?

(and again the bahavior in the two examples is different, because the Customer field may not be updated in the second example)

Why not do this?:
Customer = customer; // assuming the first example was the correct one
return products.Sum(p =&gt; p.Price) - discounts;</description>
		<content:encoded><![CDATA[<p>Why?</p>
<p>(and again the bahavior in the two examples is different, because the Customer field may not be updated in the second example)</p>
<p>Why not do this?:<br />
Customer = customer; // assuming the first example was the correct one<br />
return products.Sum(p => p.Price) &#8211; discounts;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
