{"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":"migliori-pratiche-per-le-convenzioni-di-codifica-dello-sviluppo-dei-binari","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/it\/blog\/articoli-tecnici\/migliori-pratiche-per-le-convenzioni-di-codifica-dello-sviluppo-dei-binari\/","title":{"rendered":"Sviluppo delle rotaie: convenzioni di codifica e migliori pratiche"},"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

Cosa c'\u00e8 in un nome<\/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

Denominazione strutturale<\/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

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

Ci\u00f2 che possiamo concludere da ci\u00f2 \u00e8 che il primo passo \u00e8 stato descrivere il problema in inglese. Il calcolo della distanza tra due filamenti riguarda il conteggio delle mutazioni incontrate tra i due filamenti.<\/p>\n

Refactoring<\/strong><\/h4>\n

La riorganizzazione del codice \u00e8 generalmente piuttosto banale. La parte difficile \u00e8 sapere da dove cominciare e riconoscere che puoi farcela. Parte del superamento di quella barriera consiste semplicemente nel farlo alcune volte. Trova un condizionale e, per ciascuno dei suoi blocchi, crea un oggetto la cui unica responsabilit\u00e0 \u00e8 fare quella cosa.<\/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

Qual \u00e8 la somiglianza tra le parti di codice sopra? Entrambi hanno ciascun loop e se proviamo a trovare il loro odore di codice,<\/span>
<\/p>\n