Scribd Logo
Upload

Welcome to Scribd!

  • Rails Coding Standards Defined

    Uploaded by

    Neeraj Choudhary
    4K views2 pages
    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

    Original Title

    Rails coding standards defined

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    TXT, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    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

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as TXT, PDF, TXT or read online from Scribd
    Flag for inappropriate content
    4K views2 pages

    Rails Coding Standards Defined

    Uploaded by

    Neeraj Choudhary
    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

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as TXT, PDF, TXT or read online from Scribd
    Flag for inappropriate content
    of 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