Skip to content

Commit

Permalink
Add coding style to contributing guide
Browse files Browse the repository at this point in the history
  • Loading branch information
lifo committed May 20, 2009
1 parent dfcc3e2 commit 8ba4307
Showing 1 changed file with 10 additions and 1 deletion.
11 changes: 10 additions & 1 deletion railties/guides/source/contributing_to_rails.textile
Expand Up @@ -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 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> <shell>
git checkout -b my_new_branch git checkout -b my_new_branch
</shell> </shell>


It doesn’t really matter what name you use, because this branch will only exist on your local computer. It doesn’t really matter what name you use, because this branch will only exist on your local computer.
Expand All @@ -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 * Include tests that fail without your code, and pass with it
* Update the documentation * 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 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. 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.
Expand Down

0 comments on commit 8ba4307

Please sign in to comment.