<?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/"
	xmlns:series="http://unfoldingneurons.com/"
		>
<channel>
	<title>Comments on: Where Comments Are Useful</title>
	<atom:link href="http://www.brandonsavage.net/where-comments-are-useful/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brandonsavage.net/where-comments-are-useful/</link>
	<description>The personal blog of Brandon Savage. Contains entries of a personal and professional nature focusing on PHP, Apple, LAMP, MySQL and Washington, DC.</description>
	<lastBuildDate>Thu, 18 Mar 2010 20:17:39 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Joe Leblanc</title>
		<link>http://www.brandonsavage.net/where-comments-are-useful/#comment-374</link>
		<dc:creator>Joe Leblanc</dc:creator>
		<pubDate>Fri, 26 Dec 2008 22:06:05 +0000</pubDate>
		<guid isPermaLink="false">http://dev.brandonsavage.net/?p=107#comment-374</guid>
		<description>I think that one of these days, I&#039;m going to get a bumper sticker reading &quot;not all code is poetry.&quot; Self-descriptive code can help to a point, but if you&#039;re doing client driven work, you&#039;re eventually going to have to write something that works regardless of how it reads in the code. This is where comments are vital: when you have to describe a process that is not immediately obvious.

I also agree with Eli&#039;s &quot;write out the process step-by-step&quot; advice. When you do this, you frequently find opportunities to create functions and classes to separate out your logic. Writing documentation has also helped me find bugs in functions (oh, I thought I was returning an array, etc...)</description>
		<content:encoded><![CDATA[<p>I think that one of these days, I&#8217;m going to get a bumper sticker reading &#8220;not all code is poetry.&#8221; Self-descriptive code can help to a point, but if you&#8217;re doing client driven work, you&#8217;re eventually going to have to write something that works regardless of how it reads in the code. This is where comments are vital: when you have to describe a process that is not immediately obvious.</p>
<p>I also agree with Eli&#8217;s &#8220;write out the process step-by-step&#8221; advice. When you do this, you frequently find opportunities to create functions and classes to separate out your logic. Writing documentation has also helped me find bugs in functions (oh, I thought I was returning an array, etc&#8230;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
