Browse files

Fix contributing guide to reflect preferred position on indentation

  • Loading branch information...
1 parent 522c0fd commit 51ccb7f59c83120bf6869f1febfebaec44bcface @brainopia brainopia committed Jan 26, 2012
Showing with 1 addition and 1 deletion.
  1. +1 −1 railties/guides/source/contributing_to_ruby_on_rails.textile
2 railties/guides/source/contributing_to_ruby_on_rails.textile
@@ -309,7 +309,7 @@ Rails follows a simple set of coding style conventions.
* Two spaces, no tabs.
* No trailing whitespace. Blank lines should not have any space.
-* Indent after private/protected.
+* Do not indent after private/protected. Private/protected should have the same indentation as the methods around.
* Prefer +&&+/+||+ over +and+/+or+.
* Prefer class << self block over self.method for class methods.
* +MyClass.my_method(my_arg)+ not +my_method( my_arg )+ or +my_method my_arg+.

15 comments on commit 51ccb7f

Ruby on Rails member


Ruby on Rails member

I've been secretly outdenting these for quite some time. :trollface:


Nice... But I can't wait for the day until tabs are used for indentation!


It changes everything. Again.


OMG! Rails isn't for beginners anymore!


Personally, I'm a fan of outdenting the private/protected declaration itself, like this:

class Foo

  def public_method
    # method definition goes here


  def private_method
    # method definition goes here


This helps private/protected stand out and is similar to the common indentation pattern for begin/rescue/ensure/end.


I tend to indent methods after private/protected because it makes them stand out. @sferik's approach works just as well.


I'm +1 for @sferik's suggestion


Hey how about this

class Module
  alias :______________________________PRIVATE______________________________  :private

class Foo

  def hello
    print "hello"


  def world
    print " world!\n"
end # => dissed!

@sferik I like your style!


@sferik I am with you on this. Outdenting make codes more readable as eyes would be able to catch the differences easily. 👎 on this change


Definitely with @sferik on this one. Making the distinction makes scanning code much faster.

Please sign in to comment.