Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Ruby On Rails coding conventions, standards   and best practicesDavid PaluyAugust 2012
Philosophy (from Rails)●   DRY – Dont Repeat Yourself●   Convention over Configuration●   YAGNI - You aint gonna need it
Source code Style●   Two spaces, no tabs●   Boolean tests:    dont use “and” and “or”,    always use “&&” and “| |”
Go Easy on the Comments●   If its obvious – dont explain it●   Remove old commented code●   “How to” comments
Camels for Classes,        Snakes Everywhere Else●   “Snake case”:    lowercasse_words_separated_by_underscore●   “Camel c...
Parentheses (Optional)
Parentheses (Do & Dont)
Folding Up Lines
Folding Up Blocks
if vs unless
while vs until
Use Modifier Forms
each, NOT for
In the Wild
Use Symbols to Stand for Something
Composing Methods for Humans
Make the code a little more articulate
Readable Code
Readable code makes your  classes easier to test
Gitthe diff says what you did;your commit message should tell mewhy you did this
SummaryGood code is like a good joke:  It needs no explanation
Credentials
Prochain SlideShare
Chargement dans…5
×

Ruby On Rails coding conventions, standards and best practices

15 324 vues

Publié le

  • Dating for everyone is here: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Dating direct: ❶❶❶ http://bit.ly/39mQKz3 ❶❶❶
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Ruby On Rails coding conventions, standards and best practices

  1. 1. Ruby On Rails coding conventions, standards and best practicesDavid PaluyAugust 2012
  2. 2. Philosophy (from Rails)● DRY – Dont Repeat Yourself● Convention over Configuration● YAGNI - You aint gonna need it
  3. 3. Source code Style● Two spaces, no tabs● Boolean tests: dont use “and” and “or”, always use “&&” and “| |”
  4. 4. Go Easy on the Comments● If its obvious – dont explain it● Remove old commented code● “How to” comments
  5. 5. Camels for Classes, Snakes Everywhere Else● “Snake case”: lowercasse_words_separated_by_underscore● “Camel case”: ClassName good Class_name bad● Constants: (my own preference) ALL_UPPERCASE = true
  6. 6. Parentheses (Optional)
  7. 7. Parentheses (Do & Dont)
  8. 8. Folding Up Lines
  9. 9. Folding Up Blocks
  10. 10. if vs unless
  11. 11. while vs until
  12. 12. Use Modifier Forms
  13. 13. each, NOT for
  14. 14. In the Wild
  15. 15. Use Symbols to Stand for Something
  16. 16. Composing Methods for Humans
  17. 17. Make the code a little more articulate
  18. 18. Readable Code
  19. 19. Readable code makes your classes easier to test
  20. 20. Gitthe diff says what you did;your commit message should tell mewhy you did this
  21. 21. SummaryGood code is like a good joke: It needs no explanation
  22. 22. Credentials

×