Linee guida per la codifica per la fusione continua [chiusa]

È più una questione di utilizzo SCM corretto rispetto allo stile di codifica. Tuttavia, è necessario seguire alcune linee guida specifiche per lo stile di codifica:

• Evita le lunghe code, in particolare le linee che fanno più di una cosa (e sono quindi più propensi a contenere più di una modifica)
• Evita blocchi eccessivamente lunghi (funzioni, classi, blocchi nidificati, ecc.)

E utilizzo SCM-saggio:

• Scegli un buon SCM. Il più famoso al mondo (Subversion), sfortunatamente, non è buono.
• Branch in modo generoso (ecco perché hai bisogno di un buon SCM: quelli cattivi rendono la ramificazione e l'unione inutilmente difficili).
• Impegnati spesso. Se il tuo commit tocca più di un passo di implementazione, stai sbagliando.
• Pull and catch-up-merge spesso. Più tardi integrerai le modifiche di altre persone nella tua linea di sviluppo, più confuso sarà lo SCM.
• Se ritieni di dover reindentare, riformattare o refactoring, fallo in un commit separato e contrassegnalo come tale.
• Non mettere mai nulla sotto il controllo del codice sorgente che può essere derivato da qualcos'altro - questo significa nessun binario, nessun codice generato, nessun intermediario di costruzione, ecc.
• Per quanto riguarda gli script SQL, le opinioni divergono, ma IMO, uno script SQL, una volta eseguito il commit e spinto, non dovrebbe mai essere più toccato (a meno che non sia bacato al punto che non viene eseguito affatto). Inoltre, configura una procedura che assicuri che tutti eseguano gli script giusti e non li eseguano mai due volte. Mantenere un elenco di script già eseguiti nel database e un elenco di tutti gli script da eseguire nel controllo del codice sorgente è un modo semplice ma efficace, soprattutto perché l'elenco di to-run può essere ramificato e unito come qualsiasi altro file sorgente .

A patto che il team stia lavorando sul trunk piuttosto che sui rami delle funzionalità. Martin Fowler ti dirà che sono cattivi in questo articolo

Assicurati che:

• tutti usano lo stesso set di standard, specialmente se sono impostati nell'IDE in modo che faccia la formattazione per loro.

• i commit vengono eseguiti regolarmente in modo che la fusione avvenga spesso, quindi le unioni sono piccole. gli sviluppatori seguono principi solidi (classi e metodi sono piccoli) in modo che gli sviluppatori non lavorino l'uno sull'altro.

• il team comunica in modo che i rinominamenti importanti, lo spostamento dei pacchetti, ecc. possano accadere quando tutti ne sono a conoscenza.

Quindi non dovresti soffrire troppo nella fusione.

Prendi il mantra "Se non è rotto, non aggiustarlo" ancora di più - se è rotto, risolverlo costerà il tempo per risolvere e il tempo per risolvere il conflitto di fusione. La maggior parte delle volte sarai fortunato e non avrai conflitti di fusione. Il resto del tempo, vorrai essere davvero sicuro che il dolore valesse la pena.

vale a dire. Se non ti piace la formattazione, impara a conviverci. Non apportare modifiche che non sono rilevanti per la funzione su cui stai lavorando.

so that merging into other branches is smooth if not seamless.

Non credo che le linee guida di codifica siano di per sé molto utili, ma alcune buone pratiche nell'utilizzo degli strumenti di controllo della versione scelti aiuteranno:

• Evitare che due persone modificino la stessa sezione di codice contemporaneamente. Ciò non è sempre facile o possibile, specialmente nei team più grandi, ma più modifiche simultanee dello stesso codice sono ciò che crea conflitti di fusione.

• A sostegno del punto precedente, unisci il tuo lavoro non appena possibile. Non aspettare una settimana per unire se hai finito ora - vuoi mantenere la finestra durante la quale qualcun altro potrebbe modificare lo stesso codice su cui hai lavorato il più breve possibile.

• Impara a utilizzare i tuoi strumenti in modo efficace. Unisci i conflitti succederà e la fusione sembrerà molto più "uniforme" se saprai come risolverli. Aiuterà se crei dei progetti giocattolo e crei conflitti di proposito. Sai come risolvere un conflitto tra alberi? Puoi tornare a una versione precedente? Puoi unire le modifiche tra i rami?

• Coordinate. Se due persone devono lavorare su sezioni di codice sovrapposte, farle coordinare tra loro. Se sanno cosa stanno facendo, possono condividere i cambiamenti l'uno con l'altro durante il loro lavoro in modo che non ci siano sorprese al momento della fusione.

Always put the code for if, while, etc in “{}” with the brackets on their own line.

Una pessima unione è quindi molto più probabile che porti a un codice che non verrà compilato.

Do not have lot of boiler place comments, for example.

//-----
// Arther AXB
// Date method was added::
//-----

Spesso l'unione decide che i 2 metodi sono gli stessi a causa dei commenti e uniscono la data degli aggiornamenti, quando hai aggiunto il nuovo metodo.

Always put a "," on the last item in an emun

Quindi, quando due persone aggiungono un valore, l'unione spesso funziona.