diff options
Diffstat (limited to 'railties/guides/source/contributing_to_rails.textile')
| -rw-r--r-- | railties/guides/source/contributing_to_rails.textile | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/railties/guides/source/contributing_to_rails.textile b/railties/guides/source/contributing_to_rails.textile index 84778ed9ee..a5912643c0 100644 --- a/railties/guides/source/contributing_to_rails.textile +++ b/railties/guides/source/contributing_to_rails.textile @@ -161,7 +161,7 @@ h4. Fork the Rails Source Code Fork Rails. You’re not going to put your patches right into the master branch, OK? This is where you need that copy of Rails that you cloned earlier. Think of a name for your new branch and run <shell> -git checkout -b my_new_branch +git checkout -b my_new_branch </shell> It doesn’t really matter what name you use, because this branch will only exist on your local computer. @@ -175,6 +175,15 @@ Now get busy and add your code to Rails (or edit the existing code). You’re on * Include tests that fail without your code, and pass with it * Update the documentation +h4. Follow the Coding Conventions + +Rails follows a simple set of coding style conventions. + +* Two spaces, no tabs +* Prefer +&&+/+||+ over +and+/+or+ +* +MyClass.my_method(my_arg)+ not +my_method( my_arg )+ or +my_method my_arg+ +* Follow the conventions you see used in the source already + h4. Sanity Check You should not be the only person who looks at the code before you submit it. You know at least one other Rails developer, right? Show them what you’re doing and ask for feedback. Doing this in private before you push a patch out publicly is the “smoke test” for a patch: if you can’t convince one other developer of the beauty of your code, you’re unlikely to convince the core team either. |