kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

Add coding style to contributing guide

Browse source
This commit is contained in:
Pratik Naik 2009-05-20 23:44:38 +02:00
parent dfcc3e2f89
commit 8ba4307bf7
1 changed files with 10 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
railties/guides/source/contributing_to_rails.textile
View file

@ -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.