<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Software is too expensive to build cheaply... &#187; coding standards</title>
	<atom:link href="http://twasink.net/blog/tags/coding-standards/feed/" rel="self" type="application/rss+xml" />
	<link>http://twasink.net/blog</link>
	<description>Robert's Rambling Ruminations Regarding Reality</description>
	<lastBuildDate>Fri, 16 Jul 2010 06:57:24 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Interfaces with EJB3</title>
		<link>http://twasink.net/blog/2007/01/interfaces-with-ejb3/</link>
		<comments>http://twasink.net/blog/2007/01/interfaces-with-ejb3/#comments</comments>
		<pubDate>Sat, 27 Jan 2007 21:54:49 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[ejb]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[wotif]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=204</guid>
		<description><![CDATA[Starting last October, we went through a process of upgrading the main application at Wotif to be running under Java EE 5 (not just Java SE 5). The biggest part of this was upgrading from EJB 2 to EJB 3.
One of the things I noticed was that EJB3 gives you a lot of choices for [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2007/01/interfaces-with-ejb3/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>ehcache dissected</title>
		<link>http://twasink.net/blog/2005/10/ehcache-dissected/</link>
		<comments>http://twasink.net/blog/2005/10/ehcache-dissected/#comments</comments>
		<pubDate>Thu, 20 Oct 2005 23:20:00 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Hibernate]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[anti-pattern]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[ehcache]]></category>
		<category><![CDATA[patterns]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=174</guid>
		<description><![CDATA[At work, we are a heavy user of ehcache. Well, we would be&#8230; it was initially written at Wotif, to overcome problems with the Jakarta JCS project. I recently had to sit down and figure out exactly how it works, and thought I&#8217;d take a moment to write it up.
*Update*: I tested the Hibernate serialization [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/10/ehcache-dissected/feed/</wfw:commentRss>
		<slash:comments>19</slash:comments>
		</item>
		<item>
		<title>Interfaces are interesting&#8230;</title>
		<link>http://twasink.net/blog/2005/06/interfaces-are-interesting/</link>
		<comments>http://twasink.net/blog/2005/06/interfaces-are-interesting/#comments</comments>
		<pubDate>Thu, 09 Jun 2005 22:17:54 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[patterns]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=148</guid>
		<description><![CDATA[Cedric&#8217;s got an interesting post on obtaining extensibility via interfaces As usual, he makes a lot of very good points, and (again, as usual when I link to Cedric&#8217;s posts), there are a couple that I think could be elaborated on.

I&#8217;d suggest you read Cedric&#8217;s post to get the main gist, but here&#8217;s a quick [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/06/interfaces-are-interesting/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>I&#8217;m not a Hungarian Notation user</title>
		<link>http://twasink.net/blog/2005/05/im-not-a-hungarian-notation-user/</link>
		<comments>http://twasink.net/blog/2005/05/im-not-a-hungarian-notation-user/#comments</comments>
		<pubDate>Thu, 12 May 2005 07:55:13 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=138</guid>
		<description><![CDATA[Joel Spolsky wrote an interesting article which had a brief history of Hungarian notation, amongst other things. Cedric Beust&#8217;s picked it up and made the claim that We are all Hungarian Notation users. I&#8217;m not buying it.

I&#8217;ve got two disagreements with Hungarian notation.
The &#8220;information&#8221; encoded in the variable name is often irrelevant. This is the [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/05/im-not-a-hungarian-notation-user/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>Your code sucks because&#8230;</title>
		<link>http://twasink.net/blog/2005/05/your-code-sucks-because/</link>
		<comments>http://twasink.net/blog/2005/05/your-code-sucks-because/#comments</comments>
		<pubDate>Wed, 11 May 2005 22:48:16 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[anti-pattern]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=137</guid>
		<description><![CDATA[I rediscovered this article while doing some research. It gives an extensive list of reasons why your code sucks.
]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/05/your-code-sucks-because/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Coding Convention: Put identifying parameters first</title>
		<link>http://twasink.net/blog/2005/03/coding-convention-put-identifying-parameters-first/</link>
		<comments>http://twasink.net/blog/2005/03/coding-convention-put-identifying-parameters-first/#comments</comments>
		<pubDate>Thu, 10 Mar 2005 10:16:57 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=118</guid>
		<description><![CDATA[When declaring a FactoryMethod put identifying parameters first.

For example, instead of this:
[source='java']public Contact createContact(Country countryToBeCovered, String contactName);[/source]
do this:
[source='java']public Contract createContact(String contactName, Country countryToBeCovered);[/source]
This is mostly for test code, where you may well be creating several different instances of the same object as part of a test fixture. Placing identifying parameters first helps to distinguish them [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/03/coding-convention-put-identifying-parameters-first/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Beware the mechanical coder, my son&#8230;</title>
		<link>http://twasink.net/blog/2005/02/beware-the-mechanical-coder-my-son/</link>
		<comments>http://twasink.net/blog/2005/02/beware-the-mechanical-coder-my-son/#comments</comments>
		<pubDate>Fri, 18 Feb 2005 15:32:08 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=110</guid>
		<description><![CDATA[Stumbled upon this beauty today (minor changes to protect the guilty)

[source='java']
StringBuffer query = new StringBuffer(&#8221;select foo.id from FooBar foo where foo.endTime >= ? &#8221;
  + &#8220;and foo.endTime < ? "
  + "and foo.bar.id = ? "
  + "order by foo.startTime desc");
[/source]
Immediately after this little piece of truth and beauty was this:
[source='java']
List results [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/02/beware-the-mechanical-coder-my-son/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Long != meaningful</title>
		<link>http://twasink.net/blog/2005/02/long-meaningful/</link>
		<comments>http://twasink.net/blog/2005/02/long-meaningful/#comments</comments>
		<pubDate>Wed, 16 Feb 2005 14:24:14 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=109</guid>
		<description><![CDATA[Meaningful names for variables, methods, and classes go a long way to making uncommented code possible. However, meaning is not conveyed simply by length.

Consider this snippet (a real example, with the class name changed)[1]. It&#8217;s just a variable declaration in a method that&#8217;s only a few lines long, but it conveys the point:
[source='java']DamnThatIsAVeryLongClassName damnThatIsAVeryLongClassName = [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/02/long-meaningful/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Don&#8217;t propagate exceptions in test fixtures</title>
		<link>http://twasink.net/blog/2005/02/dont-propagate-exceptions-in-test-fixtures/</link>
		<comments>http://twasink.net/blog/2005/02/dont-propagate-exceptions-in-test-fixtures/#comments</comments>
		<pubDate>Wed, 09 Feb 2005 16:56:10 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=107</guid>
		<description><![CDATA[Been seeing this pattern a lot today. I&#8217;m working with integration tests, which have a lot of test fixtures around to do common tasks (such as inserting data into the database). These test fixtures propagate exceptions. In many cases, they simply declare that they throw java.lang.Exception. Ouch.

Exceptions coming from test fixtures are noisy; they mean [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/02/dont-propagate-exceptions-in-test-fixtures/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Programming by difference</title>
		<link>http://twasink.net/blog/2005/02/programming-by-difference/</link>
		<comments>http://twasink.net/blog/2005/02/programming-by-difference/#comments</comments>
		<pubDate>Mon, 07 Feb 2005 22:45:11 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=105</guid>
		<description><![CDATA[I&#8217;m currently working my way through Michael Feathers Working Effectively With Legacy Code. Damn good book, BTW. Anyway, this was this section on &#8220;programming by difference&#8221; that got my thinking while reading it.

In this section, Michael describes adapting a MessageForwarder. The existing implementation has a method, getFromAddress(), which says who the message that is being [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/02/programming-by-difference/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
