{"id":26709,"date":"2017-06-17T11:03:19","date_gmt":"2017-06-17T11:03:19","guid":{"rendered":"https:\/\/dev.railscarma.com\/rails-development-coding-conventions-best-practices\/"},"modified":"2024-01-10T11:41:26","modified_gmt":"2024-01-10T11:41:26","slug":"meilleures-pratiques-des-conventions-de-codage-du-developpement-rails","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/fr\/blog\/articles-techniques\/meilleures-pratiques-des-conventions-de-codage-du-developpement-rails\/","title":{"rendered":"D\u00e9veloppement Rails\u00a0: conventions de codage et meilleures pratiques"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Qu'est-ce qu'il y a dans un nom<\/h4>\n

A good name answers important questions. What does it contain? What does it mean? How would I use it?
\nWhat  role  does  it  play?
\nAlways name your methods based on their behaviour, not implementation.
\nConsider,<\/p>\n

\"coding\"<\/a><\/p>\n

By looking at the method name above, we can predict it\u2019s going to perform 2-3 database operations, but
\nwhen I\u2019m working in Business model, why would it concern me?
\nGoing  by,  naming  method  based  on  their  business  role,  the  method  can  be  renamed  as,<\/p>\n

\"Rails<\/a><\/p>\n

D\u00e9nomination structurelle<\/strong><\/h4>\n

Another common strategy is to name things for their role in the program. It\u2019s the input or the output. It\u2019s the recurring phrase or the middle sentence.  Consider the code for counting differences between two points;<\/code><\/p>\n

\"\"<\/a><\/p>\n

Here the arguments first and second are pretty vague, considering the fact that we\u2019re not even sure if the order matters. In this context, it doesn\u2019t.
\nI can then restructure my code as;<\/p>\n

\"des<\/a><\/p>\n

Ce que nous pouvons en conclure, c\u2019est que la premi\u00e8re \u00e9tape consistait \u00e0 d\u00e9crire le probl\u00e8me en anglais. Le calcul de la distance entre deux brins concerne le nombre de mutations rencontr\u00e9es entre les deux brins.<\/p>\n

Refactorisation<\/strong><\/h4>\n

La r\u00e9organisation du code est g\u00e9n\u00e9ralement assez triviale. Le plus d\u00e9licat est de savoir par o\u00f9 commencer et de reconna\u00eetre que vous pouvez le faire. Pour surmonter cet obstacle, il suffit de le faire plusieurs fois. Trouvez un conditionnel et pour chacun de ses blocs, cr\u00e9ez un objet dont la seule responsabilit\u00e9 est de faire cette chose.<\/p>\n

Refactoring is about recognizing a snippet of code as exhibiting characteristics that are known to be problematic.Applying a change that is known to fix this category of problem.
\nThis problematic pattern is called Code Smell, \u201ccode smell is a surface indication that usually corresponds to a deeper problem in the system.\u201d \u2013 Martin Fowler
\nStarting small is never a bad idea, if you can refactor code at micro level, then when it all comes together, it will become a refactored code.
\nConsider two code snippets for example,<\/p>\n

\"sum\"                       <\/a>\"old\"<\/a><\/p>\n

Quelle est la similitude entre les morceaux de code ci-dessus\u00a0? Les deux ont chaque boucle, et si nous essayons de trouver leur code qui sent mauvais,<\/span>
<\/p>\n