

Rails Development No-Nos - helium
http://www.chadfowler.com/2009/4/1/20-rails-development-no-no-s

======
old-gregg
_indents per line of more than 2 spaces. drives me baddy_

I _hate_ 2-space indentation. It's weird. It makes the code look less readable
and every other more or less popular programming language uses 4. I see no
reason why Ruby code needs to look like a narrow, dense spaghetti because of
this stupid "rule".

There is _nothing_ in the language that justifies this awkward feature: Ruby
isn't excessively nested and an average line length is short.

This language looks _beautiful_ when properly indented with 4 spaces. I've
heard from a couple of Pythonista friends that Ruby looked to much Perl-like
to them, I suspect _some_ of it can be attributed to this tradition of fucked
up indentation.

Before reading open source Ruby code I always reformat it properly: just a
hotkey in vim.

~~~
jeroen
The whole 2/4/8 spaces argument should be a reason to go for tabs. Then
everyone could set their own tab size and have their code indented as they
want.

Unfortunately, I don't think all editors play nice.

~~~
bkudria
Amen. And, don't inflict pain on others just because your editor sucks.

------
ConceptDog
Holy crap.. Articles that are almost entirely links to twitter need to burn in
hell.

~~~
bkudria
OK, I'll bite. What's wrong with Twitter?

~~~
windsurfer
I know I probably shouldn't do this (for fear of getting down-voted), but...
the basic problem with twitter is it's severe restriction on n

------
umjames
I don't think I agree with no comments in methods and not much comments
overall.

What if the comments specify why you're taking a certain approach over another
or something that was decided by other people? Comments are good for
documenting not what the code says, but the reasoning behind that code. This
is especially helpful if you haven't looked at it for awhile.

------
teej
> Tabs instead of spaces

Every editor on earth supports both. Why the hell do I have to use spaces if
the choice has -no effect whatsoever-.

~~~
old-gregg
You may be wondering why you're getting downmodded. That's because people
disagree with you. I suspect the good reason is that different editors handle
tabs differently. Some treat them as 2 spaces, some 4, some 8. I don't use
tabs and frankly I don't even know what my tab width is set to in vim.

Using tabs in the code shared between multiple people will produce _annoying_
inconsistencies. Spaces will look identical everywhere.

~~~
kscaldef
Well, I think the main argument for tabs is that they will look exactly how
each individual wants them to look. If you like things compressed
horizontally, set your tab width to 2. If you want things really spacious, set
it to 8. Spaces don't give individuals the option to tailor for their
preferences.

There are two non-trivial issues in this debate though:

1) mixing spaces and tabs is undeniable evil. Everyone on your team needs to
conform to one or the other. (And since I like spaces, everyone should use
spaces ;-). )

2) In a layout-based syntax like Haskell's, you cannot set your tab width
willy-nilly. The syntax defines a tab as equivalent to 8 spaces. Vary this in
your editor at your peril.

~~~
bkudria
What's wrong with mixing tabs and spaces?

The proper way to code is to use tabs to indent, and spaces after to align.
So, no spaces before tabs, only after, and tabs should only indent to the
current indentation level of the code (obviously).

~~~
kscaldef
The problem is that you must adopt a standard tab width for this to approach.
Otherwise when you mix this with team members who use only spaces, things with
become inconsistent. Also, as I pointed out, with languages like Python &
Haskell, it is required to fix the tab width.

At this point, where you must dictate a fixed tab width that everyone must
use, I fail to see any advantage to using tabs (other than a miniscule
reduction in file size).

------
erlanger
Almost all of these "No-No's" apply equally to development on any platform.
Adding "Rails" sorta makes it link-bait, since there's very little domain-
specific knowledge here:

    
    
      * Write tests
      * Don't write obfuscated code
      * Consistent indentation, using spaces
      * Don't mix presentation with logic
    

etc. etc.

