<?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"
	>
<channel>
	<title>Comments on: Skeleton Classes</title>
	<atom:link href="http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/feed/" rel="self" type="application/rss+xml" />
	<link>http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/</link>
	<description>my god, it's full of stars</description>
	<pubDate>Sun, 06 Jul 2008 19:33:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Shadowfiend</title>
		<link>http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/#comment-37801</link>
		<dc:creator>Shadowfiend</dc:creator>
		<pubDate>Thu, 09 Aug 2007 15:52:52 +0000</pubDate>
		<guid isPermaLink="false">http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/#comment-37801</guid>
		<description>&lt;p&gt;Caleb's point is an excellent one, and in fact I'd argue it's probably the biggest advantage of skeleton classes. By documenting beforehand, you can have a clear outline of what your method is supposed to do before you even write it, so that if you have to expand what it does, you can critically look at your original intentions and decide whether another method is needed.&lt;/p&gt;

&lt;p&gt;Moreover, bear in mind that skeleton classes are basically the level right above the UML class diagram -- the difference being that you're looking at it in code rather than as a drawing. Test-first strategies, by the way, bring some similar advantages, namely in allowing you to exercise your API before you write it so you get a better feel for how it will work.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Caleb&#8217;s point is an excellent one, and in fact I&#8217;d argue it&#8217;s probably the biggest advantage of skeleton classes. By documenting beforehand, you can have a clear outline of what your method is supposed to do before you even write it, so that if you have to expand what it does, you can critically look at your original intentions and decide whether another method is needed.</p>
<p>Moreover, bear in mind that skeleton classes are basically the level right above the UML class diagram &#8212; the difference being that you&#8217;re looking at it in code rather than as a drawing. Test-first strategies, by the way, bring some similar advantages, namely in allowing you to exercise your API before you write it so you get a better feel for how it will work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Caleb</title>
		<link>http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/#comment-37656</link>
		<dc:creator>Caleb</dc:creator>
		<pubDate>Wed, 08 Aug 2007 16:19:57 +0000</pubDate>
		<guid isPermaLink="false">http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/#comment-37656</guid>
		<description>&lt;p&gt;I would suggest, when writing skeletons, that you also take the opportunity to heavily document the functions, even if it's just with comments above the signature.  It will keep the code readable and keep you from forgetting exactly what the function needs to take care of.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I would suggest, when writing skeletons, that you also take the opportunity to heavily document the functions, even if it&#8217;s just with comments above the signature.  It will keep the code readable and keep you from forgetting exactly what the function needs to take care of.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Noah Everett</title>
		<link>http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/#comment-37649</link>
		<dc:creator>Noah Everett</dc:creator>
		<pubDate>Wed, 08 Aug 2007 15:16:30 +0000</pubDate>
		<guid isPermaLink="false">http://warpspire.com/tipsresources/interface-scripting/skeleton-classes/#comment-37649</guid>
		<description>&lt;p&gt;Very nifty. Also using the same naming structure for all your classes helps in the long run so when you are up to your knees in classes and you need to figure out what the "getter/setter" for this specific object is without going back to the source file itself.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Very nifty. Also using the same naming structure for all your classes helps in the long run so when you are up to your knees in classes and you need to figure out what the &#8220;getter/setter&#8221; for this specific object is without going back to the source file itself.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.271 seconds -->
