Come si codifica senza offendere?

Chiedi. Cioè, chiedi alla gente con cui lavori. Fai del tuo meglio per attenersi allo stile stabilito del codice esistente. Chiedere in particolare se esiste un elenco di documenti per gli standard di codifica e seguirlo. Se non ce n'è uno, scrivi una prima bozza basata su ciò che osservi nel codice e poi chiedi agli altri membri del team di criticarlo. Farai un servizio alla compagnia (e ai nuovi sviluppatori che verranno dopo di te) iniziando a documentare le pratiche di codifica accettate. L'unico rischio è quello di rimanere intrappolati nel mezzo se si scopre che i veterani non sono d'accordo l'uno con l'altro su ciò che è o non è accettabile.

Inoltre, non aver paura di essere te stesso . Potresti essere il nuovo, ma sei un membro del team e le tue opinioni sono valide. Se riesci a pensare a modi migliori per fare qualcosa, suggerilo. Rispetta gli altri membri del team e il modo stabilito di fare le cose, ma non lasciare che ti spingono in giro. La società non ti avrebbe assunto se non avesse valutato il tuo contributo.

Aiuterà molto se puoi trovare qualcuno nel team che sembra amichevole e particolarmente disposto a rispondere alle domande. (Se è una buona squadra, dovrebbero essere tutti, ma le squadre non sono sempre così.) Il tuo capo potrebbe aver assegnato qualcuno per aiutarti a iniziare. Usa quella persona come risorsa. Annota le domande mentre ti si presentano, quindi chiedi a quella persona utile di rispondere di tanto in tanto.

Per quanto riguarda il check-in del codice "troppo spesso", perché non crea il tuo ramo per i tuoi commit periodici e poi unisci di nuovo al trunk quando il codice è pronto? Non c'è niente di male a nessuno nel farlo, e quando i tuoi colleghi ti vedono ottenere benefici da SVN che vorrebbero, potrebbero seguire il tuo esempio.

Per quanto riguarda gli spazi bianchi: basta farlo comunque il codice lo fa già. Vai con il flusso.

Per quanto riguarda i check-in SVN: Documentali molto chiaramente. Questo aiuta le persone a capire cosa sta succedendo nel codice. (Seguito: quali sono le loro obiezioni ai controlli frequenti?)

In generale: inizia a creare un documento standard di codifica. Non cercare di riempirlo con 100 regole. Aggiungi le regole appena vengono visualizzate.

Inoltre: fai domande ai tuoi colleghi sviluppatori. Questo dà loro l'opportunità di valutare prima di fare qualcosa che non gli piacerà. Inoltre, costruisce relazioni. Inoltre, si impara di più su come funziona il negozio.

Per quanto riguarda lo stile di formattazione del codice (spazi bianchi, tabulazioni, dove vanno le parentesi, ecc.) devi seguire lo standard prevalente nel codice. Se non ce n'è uno, non penso che abbiano molto di cui lamentarsi. Quando si arriva a questo, se si mettono le parentesi sulla propria linea o no, si mettono degli spazi attorno agli elenchi dei parametri dei metodi, ecc. È una preferenza personale, e si dovrebbe cedere allo stile prevalente perché alla lunga, veramente non importa . Ciò che conta è essere coerenti.

Quando si tratta di controllare il codice in SVN, proverei a evangelizzare ciò che ritengo sia il modo giusto di fare le cose, piuttosto che lasciarmi trasportare al vapore. Non controllo il mio codice a meno che non costruisca e superi test, e se sto facendo diverse modifiche non correlate, interrompo il mio lavoro in diversi commit. Se qualcosa si rompe per un po ', creo un ramo e faccio il mio lavoro lì. I commit ricevono commenti descrittivi. Questo funziona meglio della mia esperienza rispetto al metodo "controlla in un mucchio di modifiche il venerdì alle 5:00" e sembra essere la "migliore pratica" prevalente secondo la maggior parte di ciò che ho letto qui e altrove. p>     

Prima leggi i documenti delle convenzioni di codifica (se non ne hanno uno allora chiedi loro di scriverne uno così puoi seguirlo)

Quindi prendi nota e fai uno sforzo cosciente per seguire ciò e quello che dicono. Potrebbe sembrare che siano severi, ma gli standard di codifica sono importanti, è meglio far notare ora che cosa è sbagliato piuttosto che lasciarlo trasformarsi in un problema più avanti quando si apportano cambiamenti più grandi.

Sono sicuro che farai lo stesso tra un anno o due quando alcuni novizi stanno calpestando le dita dei piedi:)

Richiedi gli standard del codice aziendale. Prestare maggiore attenzione ai dettagli. Se vedi che gli altri seguono una forma molto specifica di spazi bianchi e modelli di tutore, quindi seguili. Come Sr. potresti obiettare che questo è pignolo, ma come Jr. o nuovo ragazzo in un progetto devi dimostrare che puoi seguire prima di poter guidare.

Inoltre, comprendi che qualsiasi nuovo sviluppatore di un progetto avrà effettivamente un necessario "tempo di accelerazione". Quindi non ti preoccupare oltre.

La cosa migliore che puoi fare è seguire i consigli che ti danno. Non c'è modo di dire in anticipo ciò che vogliono. A meno che tu non sia un sensitivo.

Tuttavia, suggerirei che mentre le persone danno consigli, lo documentate. Hai una wiki? Se è così, usalo. In caso contrario, un file di testo archiviato con il codice sorgente potrebbe essere una buona idea. Costruisci una guida alla programmazione ben organizzata. Ti aiuterà a ricordare come fare le cose, e se qualcuno contraddice i consigli precedenti che ti sono stati dati, ti darà un punto di riferimento per discutere dell'inconsistenza. Inoltre, quando la prossima persona si unisce al team, non dovrà passare attraverso quello che stai attraversando.

Suggerirei di non attribuire il consiglio nel documento ai singoli (quindi "i blocchi di codice dovrebbero essere rientrati di tre spazi", non "Bill mi ha detto che i blocchi di codice dovrebbero essere rientrati di tre spazi"). Tuttavia, se è possibile registrare tali informazioni in modo non invadente (ad esempio nel commento di commit, scrivere "regola aggiunta sui rientri basata sul consiglio di Bill"), allora potrebbe essere utile per risolvere le contraddizioni, perché è possibile ottenere immediatamente due punti di vista Su qualcosa. Quello che sto pensando qui, in realtà, è che se ti viene dato un consiglio contraddittorio, devi evitare di diventare un calcio che viene calciato da due colleghi che non sono d'accordo su qualcosa. È un po 'un approccio da cover-as-as, ma potrebbe essere prudente.

Facile è trovare la guida di stile e seguirla. La maggior parte non ha nulla di troppo offensivo in loro, e ti impedirà di offendere gli altri.