Scribd
Upload
4K views2 pages

Rails Coding Standards Defined

The best applications are coded properly. This sounds like an obvious statement, but by 'properly', I mean that the code not only does its job well, but is also easy to add to, maintain and debug. you can refer "http://wiki.rubyonrails.org/rails/pages/CodingStandards" for coding standards Also to cut short the story here is the summary: I've found some recurring issues that arise relating to code quality, so have set out to write a mini-code standard. 1. IN ESSENCE: ALL CODE SHOULD BE READABLE! 2. DO NOT OPTIMIZE for performance - OPTIMIZE FOR CLARITY OF CODE 3. STYLE: use 2 spaces for indent (not tabs) 4. STYLE: Line up hash arrows for readability 5. STYLE: put spaces around => hash arrows 6. STYLE: put spaces after ',' in method params - but none between method names and '(' 7. VIEWS: use HAML for views 8. VIEWS: break up the structure with white space to help readability - VERTICALLY TOO! 9. VIEWS STYLE: Rely on structure of page, without having to insert messages or new components... * Example: Effect to visually highlight then drop out an existing element rather than flash a message * Example: Highlight newly added row rather than a message about it 10. AVOID logic in views - they should be simple * put html generating logic into helpers * instead of inline ruby logic, add to models (filtering, checking) 11. NEVER use ActiveRecord models in migrations unless you re-define them within the migration * ...otherwise the migration fails when you later remove/rename the AR class * BETTER SOLUTION: use bootstrapping until deployed!!! 12. AJAX only for sub-components of an object, and avoid over-use you are free to add your views to it as per your experience and expertise

Uploaded by

Neeraj Choudhary
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
4K views2 pages

Rails Coding Standards Defined

The best applications are coded properly. This sounds like an obvious statement, but by 'properly', I mean that the code not only does its job well, but is also easy to add to, maintain and debug. you can refer "http://wiki.rubyonrails.org/rails/pages/CodingStandards" for coding standards Also to cut short the story here is the summary: I've found some recurring issues that arise relating to code quality, so have set out to write a mini-code standard. 1. IN ESSENCE: ALL CODE SHOULD BE READABLE! 2. DO NOT OPTIMIZE for performance - OPTIMIZE FOR CLARITY OF CODE 3. STYLE: use 2 spaces for indent (not tabs) 4. STYLE: Line up hash arrows for readability 5. STYLE: put spaces around => hash arrows 6. STYLE: put spaces after ',' in method params - but none between method names and '(' 7. VIEWS: use HAML for views 8. VIEWS: break up the structure with white space to help readability - VERTICALLY TOO! 9. VIEWS STYLE: Rely on structure of page, without having to insert messages or new components... * Example: Effect to visually highlight then drop out an existing element rather than flash a message * Example: Highlight newly added row rather than a message about it 10. AVOID logic in views - they should be simple * put html generating logic into helpers * instead of inline ruby logic, add to models (filtering, checking) 11. NEVER use ActiveRecord models in migrations unless you re-define them within the migration * ...otherwise the migration fails when you later remove/rename the AR class * BETTER SOLUTION: use bootstrapping until deployed!!! 12. AJAX only for sub-components of an object, and avoid over-use you are free to add your views to it as per your experience and expertise

Uploaded by

Neeraj Choudhary
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

The best applications are coded properly.

This sounds like an obvious statement,


but by 'properly', I mean that the code not only does its job well, but is also
easy to add to, maintain and debug.

you can refer "http://wiki.rubyonrails.org/rails/pages/CodingStandards" for coding


standards

Also to cut short the story here is the summary:

I've found some recurring issues that arise relating to code quality, so have set
out to write a mini-code standard.

1. IN ESSENCE: ALL CODE SHOULD BE READABLE!

2. DO NOT OPTIMIZE for performance - OPTIMIZE FOR CLARITY OF CODE

3. STYLE: use 2 spaces for indent (not tabs)

4. STYLE: Line up hash arrows for readability

5. STYLE: put spaces around => hash arrows

6. STYLE: put spaces after ',' in method params - but none between method names
and '('

7. VIEWS: use HAML for views

8. VIEWS: break up the structure with white space to help readability - VERTICALLY
TOO!

9. VIEWS STYLE: Rely on structure of page, without having to insert messages or


new components...

* Example: Effect to visually highlight then drop out an existing element rather
than flash a message

* Example: Highlight newly added row rather than a message about it

10. AVOID logic in views - they should be simple

* put html generating logic into helpers

* instead of inline ruby logic, add to models (filtering, checking)

11. NEVER use ActiveRecord models in migrations unless you re-define them within
the migration

* ...otherwise the migration fails when you later remove/rename the AR class

* BETTER SOLUTION: use bootstrapping until deployed!!!


12. AJAX only for sub-components of an object, and avoid over-use

you are free to add your views to it as per your experience and expertise

You might also like