<?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:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"	>
<channel>
	<title>Comments on: If You Can&#8217;t Say Anthing Useful&#8230;</title>
	<atom:link href="http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/feed/" rel="self" type="application/rss+xml" />
	<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/</link>
	<description>Johannes Brodwall&#039;s Musings on Software Architecture and Programming</description>
	<lastBuildDate>Fri, 27 Jan 2012 09:40:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Marius Mårnes Mathiesen</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-19</link>
		<dc:creator>Marius Mårnes Mathiesen</dc:creator>
		<pubDate>Wed, 15 Mar 2006 17:24:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-19</guid>
		<description>I just stumbled across another piece of fantastic code comments that I&#039;d love to share. It&#039;s from the PHPUnit2 documentation, have a laugh:

    protected function setUp() 
    {
        // Create the Array fixture.
        $this-&gt;fixture = Array();
    }
 
    public function testNewArrayIsEmpty() {
        // Assert that the size of the Array fixture is 0.
        $this-&gt;assertEquals(0, sizeof($this-&gt;fixture));
    }
 
    public function testArrayContainsAnElement() {
        // Add an element to the Array fixture.
        $this-&gt;fixture[] = &#039;Element&#039;;
 
        // Assert that the size of the Array fixture is 1.
        $this-&gt;assertEquals(1, sizeof($this-&gt;fixture));
    }

</description>
		<content:encoded><![CDATA[<p>I just stumbled across another piece of fantastic code comments that I&#8217;d love to share. It&#8217;s from the PHPUnit2 documentation, have a laugh:</p>
<p>    protected function setUp()<br />
    {<br />
        // Create the Array fixture.<br />
        $this-&gt;fixture = Array();<br />
    }</p>
<p>    public function testNewArrayIsEmpty() {<br />
        // Assert that the size of the Array fixture is 0.<br />
        $this-&gt;assertEquals(0, sizeof($this-&gt;fixture));<br />
    }</p>
<p>    public function testArrayContainsAnElement() {<br />
        // Add an element to the Array fixture.<br />
        $this-&gt;fixture[] = &#8216;Element&#8217;;</p>
<p>        // Assert that the size of the Array fixture is 1.<br />
        $this-&gt;assertEquals(1, sizeof($this-&gt;fixture));<br />
    }</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marius Mårnes Mathiesen</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-84548</link>
		<dc:creator>Marius Mårnes Mathiesen</dc:creator>
		<pubDate>Wed, 15 Mar 2006 14:24:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-84548</guid>
		<description>I just stumbled across another piece of fantastic code comments that I&#039;d love to share. It&#039;s from the PHPUnit2 documentation, have a laugh:&lt;br&gt;&lt;br&gt;    protected function setUp() &lt;br&gt;    {&lt;br&gt;        // Create the Array fixture.&lt;br&gt;        $this-&gt;fixture = Array();&lt;br&gt;    }&lt;br&gt; &lt;br&gt;    public function testNewArrayIsEmpty() {&lt;br&gt;        // Assert that the size of the Array fixture is 0.&lt;br&gt;        $this-&gt;assertEquals(0, sizeof($this-&gt;fixture));&lt;br&gt;    }&lt;br&gt; &lt;br&gt;    public function testArrayContainsAnElement() {&lt;br&gt;        // Add an element to the Array fixture.&lt;br&gt;        $this-&gt;fixture[] = &#039;Element&#039;;&lt;br&gt; &lt;br&gt;        // Assert that the size of the Array fixture is 1.&lt;br&gt;        $this-&gt;assertEquals(1, sizeof($this-&gt;fixture));&lt;br&gt;    }</description>
		<content:encoded><![CDATA[<p>I just stumbled across another piece of fantastic code comments that I&#39;d love to share. It&#39;s from the PHPUnit2 documentation, have a laugh:</p>
<p>    protected function setUp() <br />    {<br />        // Create the Array fixture.<br />        $this-&gt;fixture = Array();<br />    }</p>
<p>    public function testNewArrayIsEmpty() {<br />        // Assert that the size of the Array fixture is 0.<br />        $this-&gt;assertEquals(0, sizeof($this-&gt;fixture));<br />    }</p>
<p>    public function testArrayContainsAnElement() {<br />        // Add an element to the Array fixture.<br />        $this-&gt;fixture[] = &#39;Element&#39;;</p>
<p>        // Assert that the size of the Array fixture is 1.<br />        $this-&gt;assertEquals(1, sizeof($this-&gt;fixture));<br />    }</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kjetil</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-18</link>
		<dc:creator>Kjetil</dc:creator>
		<pubDate>Sat, 25 Feb 2006 02:24:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-18</guid>
		<description>Too shy: just enable automatic code folding for comments in IntelliJ. Then you can unfold if you need a close look.</description>
		<content:encoded><![CDATA[<p>Too shy: just enable automatic code folding for comments in IntelliJ. Then you can unfold if you need a close look.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kjetil</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-84547</link>
		<dc:creator>Kjetil</dc:creator>
		<pubDate>Fri, 24 Feb 2006 23:24:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-84547</guid>
		<description>Too shy: just enable automatic code folding for comments in IntelliJ. Then you can unfold if you need a close look.</description>
		<content:encoded><![CDATA[<p>Too shy: just enable automatic code folding for comments in IntelliJ. Then you can unfold if you need a close look.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ole Christian Rynning</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-17</link>
		<dc:creator>Ole Christian Rynning</dc:creator>
		<pubDate>Wed, 22 Feb 2006 07:48:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-17</guid>
		<description>For object oriented languages I feel the class header should ALWAYS be commente.

_Especially if the classname is a generic one like *HashTable_. 

One of many nuiances working with legacy code is figuring out in which context(s) classes are used and sometimes the mere purpose of them without reading through the entire class.

If you call outside objects methods its useful to briefly tag them with a comment or even a @see doclet.</description>
		<content:encoded><![CDATA[<p>For object oriented languages I feel the class header should ALWAYS be commente.</p>
<p>_Especially if the classname is a generic one like *HashTable_. </p>
<p>One of many nuiances working with legacy code is figuring out in which context(s) classes are used and sometimes the mere purpose of them without reading through the entire class.</p>
<p>If you call outside objects methods its useful to briefly tag them with a comment or even a @see doclet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ole Christian Rynning</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-84546</link>
		<dc:creator>Ole Christian Rynning</dc:creator>
		<pubDate>Wed, 22 Feb 2006 04:48:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-84546</guid>
		<description>For object oriented languages I feel the class header should ALWAYS be commente.&lt;br&gt;&lt;br&gt;_Especially if the classname is a generic one like *HashTable_. &lt;br&gt;&lt;br&gt;One of many nuiances working with legacy code is figuring out in which context(s) classes are used and sometimes the mere purpose of them without reading through the entire class.&lt;br&gt;&lt;br&gt;If you call outside objects methods its useful to briefly tag them with a comment or even a @see doclet.</description>
		<content:encoded><![CDATA[<p>For object oriented languages I feel the class header should ALWAYS be commente.</p>
<p>_Especially if the classname is a generic one like *HashTable_. </p>
<p>One of many nuiances working with legacy code is figuring out in which context(s) classes are used and sometimes the mere purpose of them without reading through the entire class.</p>
<p>If you call outside objects methods its useful to briefly tag them with a comment or even a @see doclet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Too shy to say my name.</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-16</link>
		<dc:creator>Too shy to say my name.</dc:creator>
		<pubDate>Tue, 21 Feb 2006 00:26:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-16</guid>
		<description>Obvious comments do suck when you look at the code. However, sometimes (like just before negotiating your salary or vacation plans - or for some other personal or professional reason) you might want to use the javadoc tool to generate fancy and goodlooking API documents to show someone to prove, or create the illusion of, work well done! In this case the tagline &quot;Never, ever, say in comments what the code already says.&quot; is not appliable as there is no code to look at, but only the generated API docs! I still agree that comments should not be verbose, but they should be there (even if they are slightly useless and redundant when you have the souce code in front of you). Keep them in dense form though. 

P.S. Wouldn&#039;t it be nice with a &quot;do not show comments&quot;-function in the IDE? Then we could have both clean code and nice API docs at the same time with no annoyance. 

P.S.S. Almost forgot; writing good code is just as hard as writing good comments. Some programmers are actually better at writing comments than code and in those cases having comments to read before rewriting their uncomprehensible code is nice.</description>
		<content:encoded><![CDATA[<p>Obvious comments do suck when you look at the code. However, sometimes (like just before negotiating your salary or vacation plans &#8211; or for some other personal or professional reason) you might want to use the javadoc tool to generate fancy and goodlooking API documents to show someone to prove, or create the illusion of, work well done! In this case the tagline &#8220;Never, ever, say in comments what the code already says.&#8221; is not appliable as there is no code to look at, but only the generated API docs! I still agree that comments should not be verbose, but they should be there (even if they are slightly useless and redundant when you have the souce code in front of you). Keep them in dense form though. </p>
<p>P.S. Wouldn&#8217;t it be nice with a &#8220;do not show comments&#8221;-function in the IDE? Then we could have both clean code and nice API docs at the same time with no annoyance. </p>
<p>P.S.S. Almost forgot; writing good code is just as hard as writing good comments. Some programmers are actually better at writing comments than code and in those cases having comments to read before rewriting their uncomprehensible code is nice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Too shy to say my name.</title>
		<link>http://johannesbrodwall.com/2006/02/17/if-you-cant-say-anthing-useful/comment-page-1/#comment-84545</link>
		<dc:creator>Too shy to say my name.</dc:creator>
		<pubDate>Mon, 20 Feb 2006 21:26:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.brodwall.com/johannes/blog/?p=83#comment-84545</guid>
		<description>Obvious comments do suck when you look at the code. However, sometimes (like just before negotiating your salary or vacation plans - or for some other personal or professional reason) you might want to use the javadoc tool to generate fancy and goodlooking API documents to show someone to prove, or create the illusion of, work well done! In this case the tagline &quot;Never, ever, say in comments what the code already says.&quot; is not appliable as there is no code to look at, but only the generated API docs! I still agree that comments should not be verbose, but they should be there (even if they are slightly useless and redundant when you have the souce code in front of you). Keep them in dense form though. &lt;br&gt;&lt;br&gt;P.S. Wouldn&#039;t it be nice with a &quot;do not show comments&quot;-function in the IDE? Then we could have both clean code and nice API docs at the same time with no annoyance. &lt;br&gt;&lt;br&gt;P.S.S. Almost forgot; writing good code is just as hard as writing good comments. Some programmers are actually better at writing comments than code and in those cases having comments to read before rewriting their uncomprehensible code is nice.</description>
		<content:encoded><![CDATA[<p>Obvious comments do suck when you look at the code. However, sometimes (like just before negotiating your salary or vacation plans &#8211; or for some other personal or professional reason) you might want to use the javadoc tool to generate fancy and goodlooking API documents to show someone to prove, or create the illusion of, work well done! In this case the tagline &#8220;Never, ever, say in comments what the code already says.&#8221; is not appliable as there is no code to look at, but only the generated API docs! I still agree that comments should not be verbose, but they should be there (even if they are slightly useless and redundant when you have the souce code in front of you). Keep them in dense form though. </p>
<p>P.S. Wouldn&#39;t it be nice with a &#8220;do not show comments&#8221;-function in the IDE? Then we could have both clean code and nice API docs at the same time with no annoyance. </p>
<p>P.S.S. Almost forgot; writing good code is just as hard as writing good comments. Some programmers are actually better at writing comments than code and in those cases having comments to read before rewriting their uncomprehensible code is nice.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

