Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Update coding convention from master #7015

Merged
merged 1 commit into from

4 participants

@sikachu
Collaborator

The documentation on the http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html was outdated about indenting decision. Let's update that.

@fxn fxn merged commit 45d78a3 into from
@lunks

Is there any discussion about indenting after private/protected? At the same time I want to stay in convention with Rails', I'd like to see the arguments favoring indent. I honestly prefer to not indent methods after private/protected.

Owner

@lunks there is really no discussion going on. Of course this only applies to the Rails code base, Rails applications can have other conventions.

Conventions are arbitrary up to some point. There are people who prefer not to use parens for method definitions, there are people who prefer to surround arguments in a method call with spaces, there are people who put private/protected against the left margin so that they stand out... Though we all have our preferences, at the end of the day it does not matter much, those are the conventions agreed in the project and we stick to them to have a uniform code base.

I understand, but what motivated the change into the private/protected indenting? Please do not think of this as rant, I'm rather curious about what made you guys change your mind about this.
I prefer the older convention, and as far as discussions went on my side so far, there were no compelling arguments to either way. As such, changing this probably was led by someone stating "hey, this is better because of x." and the change was made by @sikachu afterwards.

Owner

Ah, sure.

That was the convention of the project before (https://rails.lighthouseapp.com/projects/8994/source-style) and got somehow changed. Don't remember the details. I believe David himself feels strong about indenting after private/protected in particular.

Collaborator

@lunks it was not a decision reached by consensus among rails core. some of us do not like the intented style, but ultimately it's not something that there's much point arguing about as we have much more important things to do :)

THIS IS NOT WHAT I WANT! I WANT MY CODING STYLE BACK!

Indeed, @jonleighton, not much to talk about other than pick one and live with it.

Thanks for the input. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 9, 2012
  1. @sikachu
This page is out of date. Refresh to see the latest.
Showing with 8 additions and 8 deletions.
  1. +8 −8 railties/guides/source/contributing_to_ruby_on_rails.textile
View
16 railties/guides/source/contributing_to_ruby_on_rails.textile
@@ -307,16 +307,16 @@ h4. Follow the Coding Conventions
Rails follows a simple set of coding style conventions.
-* Two spaces, no tabs.
-* No trailing whitespace. Blank lines should not have any space.
-* Do not indent after private/protected. Private/protected should have the same indentation as the methods around.
+* Two spaces, no tabs (for indentation).
+* No trailing whitespace. Blank lines should not have any spaces.
+* Indent after private/protected.
* 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+.
-* a = b and not a=b.
-* Follow the conventions you see used in the source already.
+* Prefer class << self over self.method for class methods.
+* Use +MyClass.my_method(my_arg)+ not +my_method( my_arg )+ or +my_method my_arg+.
+* Use a = b and not a=b.
+* Follow the conventions in the source you see used already.
-These are some guidelines and please use your best judgment in using them.
+The above are guidelines -- please use your best judgment in using them.
h4. Sanity Check
Something went wrong with that request. Please try again.