<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Life is grand - Latest Comments in Return *</title><link>http://lifeisgrand.disqus.com/</link><description></description><language>en</language><lastBuildDate>Sun, 20 Aug 2006 12:14:22 -0000</lastBuildDate><item><title>Re: Return *</title><link>http://paulmwatson.com/journal/2006/08/18/return/#comment-1280867</link><description>If you're talking to idiots, use small words. If you're writing for idiots, use simple constructs.&lt;br&gt;And that's enough about &lt;i&gt;that&lt;/i&gt;.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Shog9</dc:creator><pubDate>Sun, 20 Aug 2006 12:14:22 -0000</pubDate></item><item><title>Re: Return *</title><link>http://paulmwatson.com/journal/2006/08/18/return/#comment-1280866</link><description>Absolutely right Andrew. That is why I said "in moderation." Got to know when to break your own rules.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Paul Watson</dc:creator><pubDate>Sat, 19 Aug 2006 06:50:59 -0000</pubDate></item><item><title>Re: Return *</title><link>http://paulmwatson.com/journal/2006/08/18/return/#comment-1280865</link><description>I think this is correct to some extent, but as with most rules, the best coders, IMO, know when to break them.  I'd probably re-define this to say "only have well-known and obvious return points".&lt;br&gt;&lt;br&gt;When tidying up some code that had seriously evolved beyond its original purpose recently, one of the most useful and important things I did was consolidate and audit the return and exit paths, and make them sane and obvious.  This really helped the clarity of the code.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Andrew Peace</dc:creator><pubDate>Fri, 18 Aug 2006 17:50:30 -0000</pubDate></item></channel></rss>