<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.1.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Ruby and Code Consistency</title>
	<link>http://www.rubyfleebie.com/ruby-and-code-consistency/</link>
	<description>Because programming should be fun</description>
	<pubDate>Sat, 22 Nov 2008 08:26:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.1.2</generator>

	<item>
		<title>By: Robert</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-244</link>
		<author>Robert</author>
		<pubDate>Wed, 13 Jun 2007 12:22:22 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-244</guid>
					<description>Just remember that do .. end and { .. } does not mean _exactly_ the same thing: braces have a higher precedence than do .. end.</description>
		<content:encoded><![CDATA[<p>Just remember that do .. end and { .. } does not mean _exactly_ the same thing: braces have a higher precedence than do .. end.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: pangel</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-245</link>
		<author>pangel</author>
		<pubDate>Wed, 13 Jun 2007 12:54:51 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-245</guid>
					<description>@Robert : When can this be useful ?</description>
		<content:encoded><![CDATA[<p>@Robert : When can this be useful ?</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Robert</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-248</link>
		<author>Robert</author>
		<pubDate>Wed, 13 Jun 2007 14:10:05 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-248</guid>
					<description>@pangel: never? I'm sure it's possible to construct an example where it can be used, but I consider the difference a bug, since it is so non-intuitive.</description>
		<content:encoded><![CDATA[<p>@pangel: never? I&#8217;m sure it&#8217;s possible to construct an example where it can be used, but I consider the difference a bug, since it is so non-intuitive.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: slabounty</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-249</link>
		<author>slabounty</author>
		<pubDate>Wed, 13 Jun 2007 14:50:30 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-249</guid>
					<description>Why no use of return in 5.? It seems like it makes things more clear to use the return. Also, in 3., I feel it's better to have the parenthesis to make absolutely clear what it is you're trying to do rather than count on precedence. OK, surround the above with a IMHO.</description>
		<content:encoded><![CDATA[<p>Why no use of return in 5.? It seems like it makes things more clear to use the return. Also, in 3., I feel it&#8217;s better to have the parenthesis to make absolutely clear what it is you&#8217;re trying to do rather than count on precedence. OK, surround the above with a IMHO.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Frank</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-250</link>
		<author>Frank</author>
		<pubDate>Wed, 13 Jun 2007 15:26:17 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-250</guid>
					<description>@Robert : I didn't know about that. I think I prefer to not consider this when deciding to use the "do end" vs the braces. But it's good to know, thanks!

@slabounty : I have to say that these are all personal preferences. I do not pretend that my current conventions are the best coding practices. I even change my own conventions when I realize I don't like them. It takes some adjustment. For example, the "no return" thing you mention, I'm still not sure if I like it or not. Currently I am not using return if there is no need for it... but I might change my mind after a few projects. What I believe is important is to remain consistent in our coding style during the course of a single project... and one day, yes, to make up our mind.</description>
		<content:encoded><![CDATA[<p>@Robert : I didn&#8217;t know about that. I think I prefer to not consider this when deciding to use the &#8220;do end&#8221; vs the braces. But it&#8217;s good to know, thanks!</p>
<p>@slabounty : I have to say that these are all personal preferences. I do not pretend that my current conventions are the best coding practices. I even change my own conventions when I realize I don&#8217;t like them. It takes some adjustment. For example, the &#8220;no return&#8221; thing you mention, I&#8217;m still not sure if I like it or not. Currently I am not using return if there is no need for it&#8230; but I might change my mind after a few projects. What I believe is important is to remain consistent in our coding style during the course of a single project&#8230; and one day, yes, to make up our mind.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: slabounty</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-251</link>
		<author>slabounty</author>
		<pubDate>Wed, 13 Jun 2007 16:10:42 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-251</guid>
					<description>Well, I certainly agree with you on the consistency aspect. That is probably the most important thing.</description>
		<content:encoded><![CDATA[<p>Well, I certainly agree with you on the consistency aspect. That is probably the most important thing.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Thomaz Leite</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-252</link>
		<author>Thomaz Leite</author>
		<pubDate>Wed, 13 Jun 2007 16:42:02 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-252</guid>
					<description>When working on teams, people should use "more common" conventions, it's good for everyone and help you make friends :)</description>
		<content:encoded><![CDATA[<p>When working on teams, people should use &#8220;more common&#8221; conventions, it&#8217;s good for everyone and help you make friends <img src='http://www.rubyfleebie.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Gerry</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-253</link>
		<author>Gerry</author>
		<pubDate>Wed, 13 Jun 2007 16:45:32 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-253</guid>
					<description>&#62; There are a lot more… but I don’t see the point of writing them all.

I would be intersted in seeing some more.  The ones you posted I agree with and the more often a common style gets published the more it will get adopted.</description>
		<content:encoded><![CDATA[<p>&gt; There are a lot more… but I don’t see the point of writing them all.</p>
<p>I would be intersted in seeing some more.  The ones you posted I agree with and the more often a common style gets published the more it will get adopted.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: adam</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-254</link>
		<author>adam</author>
		<pubDate>Wed, 13 Jun 2007 17:18:16 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-254</guid>
					<description>Regarding if ! and unless: I think whatever makes it more readable makes sense. Sometimes if I say 'do_this unless x' is less readable than 'do_this if !x' because when you speak that aloud or in your head it just makes more sense. But this is assuming that the person reading the code already converts exclamation points into inverters in their head. 

The thing that bugs me most about reading other people's (readable) code is inconsistent whitespace and indentation. When proper whitespace and indentation are used it is easy to look at a chunk of code and _see_ how modular it is rather than trying to decipher how modular it is. I love the fact that python is such a whiner about indentation. I think if Ruby were a bit _less_ expressive then I would want Ruby to be a stickler for indentation and whitespace too.</description>
		<content:encoded><![CDATA[<p>Regarding if ! and unless: I think whatever makes it more readable makes sense. Sometimes if I say &#8216;do_this unless x&#8217; is less readable than &#8216;do_this if !x&#8217; because when you speak that aloud or in your head it just makes more sense. But this is assuming that the person reading the code already converts exclamation points into inverters in their head. </p>
<p>The thing that bugs me most about reading other people&#8217;s (readable) code is inconsistent whitespace and indentation. When proper whitespace and indentation are used it is easy to look at a chunk of code and _see_ how modular it is rather than trying to decipher how modular it is. I love the fact that python is such a whiner about indentation. I think if Ruby were a bit _less_ expressive then I would want Ruby to be a stickler for indentation and whitespace too.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Justin</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-255</link>
		<author>Justin</author>
		<pubDate>Wed, 13 Jun 2007 17:29:55 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-255</guid>
					<description>One very subtle convention I've run into in the past over and over is whether to use double quotes (") or single quotes (') for strings. For example, should one use:  :id =&#62; "myID", or  :id =&#62; 'myId' ? My convention has become to only use double quotes when I need to do some string insertions, such as:  :id =&#62; "myId_#{profile.id}". Otherwise always (or basically always... you know what I mean - by convention!) use single quotes. I've never really found any hard evidence to support my conclusion as to why I do this... which, in my mind, is that single quotes must be faster! Why? Because ruby doesn't parse over single quoted strings to find #{} insertions. So unless I need them, don't use the double quotes - which allow for string insertions and cause extra parsing. Does this make any sense? Agree/Disagree? :)</description>
		<content:encoded><![CDATA[<p>One very subtle convention I&#8217;ve run into in the past over and over is whether to use double quotes (&#8221;) or single quotes (&#8217;) for strings. For example, should one use:  :id =&gt; &#8220;myID&#8221;, or  :id =&gt; &#8216;myId&#8217; ? My convention has become to only use double quotes when I need to do some string insertions, such as:  :id =&gt; &#8220;myId_#{profile.id}&#8221;. Otherwise always (or basically always&#8230; you know what I mean - by convention!) use single quotes. I&#8217;ve never really found any hard evidence to support my conclusion as to why I do this&#8230; which, in my mind, is that single quotes must be faster! Why? Because ruby doesn&#8217;t parse over single quoted strings to find #{} insertions. So unless I need them, don&#8217;t use the double quotes - which allow for string insertions and cause extra parsing. Does this make any sense? Agree/Disagree? <img src='http://www.rubyfleebie.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Frank</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-256</link>
		<author>Frank</author>
		<pubDate>Thu, 14 Jun 2007 01:55:00 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-256</guid>
					<description>@Gerry : I'll take good note of this. I'll think of other conventions I am using and I will plug them in a future post.

@Adam : Very good point. Sometimes, it just feels more natural to use "if !" over unless (or the other way around). That "convention" shouldn't be too strict. The important part I think is to use one form or the other in a consistent manner.

@Justin : That's good material for a post, thanks! Personally, I try to always use double-quotes. If I'm using both forms, there is a risk that I forget when to use which one. But your convention on this issue makes perfect sense to me.</description>
		<content:encoded><![CDATA[<p>@Gerry : I&#8217;ll take good note of this. I&#8217;ll think of other conventions I am using and I will plug them in a future post.</p>
<p>@Adam : Very good point. Sometimes, it just feels more natural to use &#8220;if !&#8221; over unless (or the other way around). That &#8220;convention&#8221; shouldn&#8217;t be too strict. The important part I think is to use one form or the other in a consistent manner.</p>
<p>@Justin : That&#8217;s good material for a post, thanks! Personally, I try to always use double-quotes. If I&#8217;m using both forms, there is a risk that I forget when to use which one. But your convention on this issue makes perfect sense to me.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Shadowfiend</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-258</link>
		<author>Shadowfiend</author>
		<pubDate>Thu, 14 Jun 2007 18:04:03 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-258</guid>
					<description>Worth mentioning also is that two-space indent is typically the standard just about everywhere in the Ruby community. Regarding the precedence of {} over do..end, it's not something that's necessarily *useful*, so much as it is something that you need to watch out for, especially coupled with a propensity for leaving out parentheses. In the case where parentheses are dropped and you include {} on the tail end, the block won't be a block passed to the overall method, it will be a block passed _to the last parameter_, which makes a sizeable difference. It's not bad per se, it's just worth it to make sure that that's what you intend on doing.

As for obj vs return obj -- initially, I was more comfortable with return obj, but you get used to the other form very quickly, and it fast starts making more sense. The clarity isn't lost, because the return can be seen as implied. It just takes some acclimation to the Ruby way of doing things to get there.</description>
		<content:encoded><![CDATA[<p>Worth mentioning also is that two-space indent is typically the standard just about everywhere in the Ruby community. Regarding the precedence of {} over do..end, it&#8217;s not something that&#8217;s necessarily *useful*, so much as it is something that you need to watch out for, especially coupled with a propensity for leaving out parentheses. In the case where parentheses are dropped and you include {} on the tail end, the block won&#8217;t be a block passed to the overall method, it will be a block passed _to the last parameter_, which makes a sizeable difference. It&#8217;s not bad per se, it&#8217;s just worth it to make sure that that&#8217;s what you intend on doing.</p>
<p>As for obj vs return obj &#8212; initially, I was more comfortable with return obj, but you get used to the other form very quickly, and it fast starts making more sense. The clarity isn&#8217;t lost, because the return can be seen as implied. It just takes some acclimation to the Ruby way of doing things to get there.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Russ Brooks</title>
		<link>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-262</link>
		<author>Russ Brooks</author>
		<pubDate>Tue, 19 Jun 2007 14:05:14 +0000</pubDate>
		<guid>http://www.rubyfleebie.com/ruby-and-code-consistency/#comment-262</guid>
					<description>Regarding the "two-space indent vs. tabs" issue.  With dynamic [interpreted] languages, we have script files being parsed by a parser each time they are executed.  As programmers, we know that I/O is bad.  Good programmers constantly strive to minimize I/O [disk I/O, RAM I/O, DB I/O, etc].  So, isn't it wise to minimize the number of bytes that must pass through a language parser?  Using two spaces instead of a single tab can increases the number of bytes in a single code file by 5% to 20%.  This increases the number of bytes coming off the drives, into RAM, and through the parser, thereby reducing performance.  It also increases the physical size of your entire project unnecessarily.  Furthermore, it defeats the entire Ruby, Rails, and Web 2.0 modus operandi, "less is more".  Why would a good programmer do these things intentionally?  Lastly, it makes for code that is more difficult and slower to navigate and manage using the mouse and keyboard.  More characters exist that the cursor and pointer must travel through.  Because there are more characters, there is more room for error when highlighting code to move or copy it.

Less code volume is better.  Use tabs.

This really only applies to dynamic languages that execute at runtime.  Although, I would even argue that "fewer bytes is better" with compiled languages because that code still must be read and parsed at compile time, so by minimizing code volume, you minimize compile time.</description>
		<content:encoded><![CDATA[<p>Regarding the &#8220;two-space indent vs. tabs&#8221; issue.  With dynamic [interpreted] languages, we have script files being parsed by a parser each time they are executed.  As programmers, we know that I/O is bad.  Good programmers constantly strive to minimize I/O [disk I/O, RAM I/O, DB I/O, etc].  So, isn&#8217;t it wise to minimize the number of bytes that must pass through a language parser?  Using two spaces instead of a single tab can increases the number of bytes in a single code file by 5% to 20%.  This increases the number of bytes coming off the drives, into RAM, and through the parser, thereby reducing performance.  It also increases the physical size of your entire project unnecessarily.  Furthermore, it defeats the entire Ruby, Rails, and Web 2.0 modus operandi, &#8220;less is more&#8221;.  Why would a good programmer do these things intentionally?  Lastly, it makes for code that is more difficult and slower to navigate and manage using the mouse and keyboard.  More characters exist that the cursor and pointer must travel through.  Because there are more characters, there is more room for error when highlighting code to move or copy it.</p>
<p>Less code volume is better.  Use tabs.</p>
<p>This really only applies to dynamic languages that execute at runtime.  Although, I would even argue that &#8220;fewer bytes is better&#8221; with compiled languages because that code still must be read and parsed at compile time, so by minimizing code volume, you minimize compile time.</p>
]]></content:encoded>
				</item>
</channel>
</rss>
