Cosa fare se un collega sta modificando il codice solo per modificarne l'aspetto?

Cosa dovresti fare se un collega sta modificando il tuo codice?

Senza lo scopo di aggiungere funzionalità o correggere bug, solo per cambiare l'aspetto ...

Parlane con loro. Entra nella conversazione con l'atteggiamento di "Non lo fanno per infastidirmi o perché hanno una qualche forma di disturbo ossessivo-compulsivo; stanno cercando di migliorare il mio codice".

Perché potresti sbagliarti. Potrebbe essere una sottile correzione di bug e non l'hai individuata.

Oppure, potrebbe essere che esiste uno standard di codifica che non sai che stai violando e che lo stanno solo correggendo.

Oppure, potrebbe essere che stanno cercando di infastidirti, o hanno una qualche forma di disturbo ossessivo-compulsivo. In tal caso, chiedi loro di smettere e, se non funziona, prendilo con il tuo capo.

Ma non lo saprai mai se non lo chiedi.

Non sono così sposato con come il mio codice lo cerca per disturbarmi. :) Cerco di imparare dai cambiamenti. Il mio collega ha modificato i nomi delle variabili? Scrivi un ciclo più efficiente? Rendi il codice più leggibile?

Se non riesco a vedere come i cambiamenti hanno migliorato ciò che era già lì, di solito chiedo al collega che ha apportato i cambiamenti quale fosse la motivazione dietro di loro. È possibile che il vantaggio non sia ovvio per me. E se ho ragione e hanno torto, allora forse posso spiegare perché l'ho scritto come ho fatto io.

Se tutto il resto fallisce, ripristina il check-in. ;)

Modifica: tutte le scommesse sono disattivate se il desiderio di apportare modifiche estetiche ha introdotto un bug.

IMO tu e il tuo team dovreste comunque utilizzare uno standard di codifica. In questo caso, la domanda diventa "il tuo codice originale è conforme allo standard?" Se 'sì', il tuo collega non dovrebbe toccare il tuo codice a meno che non lo cambi in modo funzionale. Se "no", temo che il tuo collega abbia tutto il diritto di riordinare il tuo codice. Come capo progetto mi ritrovo a farlo sempre.

Se non stai usando uno standard di codifica, l'intero argomento di ciò che costituisce un "buon codice" diventa troppo soggettivo. Quindi perché dovresti usare uno standard di codifica :)

Come una di quelle persone (le persone che occasionalmente riformattano il codice di altre persone), la ragione principale per cui lo faccio è la leggibilità. Alcune persone sono solo estremamente sciatte con il loro rientro o con la combinazione di schede e spazi.

La cosa principale che ho l'abitudine di cambiare è ridurre le righe lunghe in modo da poter leggere il tutto senza scorrimento orizzontale. Suddividerò le istruzioni complesse in istruzioni separate o riformatterò le chiamate / dichiarazioni del metodo per elencare un parametro per riga se non tutto si adatta comodamente su una singola riga. Modificherò anche i commenti, sia per correggere gli errori inglesi o semplicemente per chiarire le cose.

Sì, potrei lasciarlo da solo, ma preferirei ridurre lo sforzo mentale necessario per leggere il codice.

Cosa dovresti fare al riguardo? Innanzitutto, considera che forse questa persona sta migliorando il tuo codice. Inoltre, dovresti assicurarti di avere un certo consenso nel tuo team su come formattare il codice. Se ogni persona ha abitudini diverse, rallenterà tutti. Se non stanno migliorando il tuo codice e stanno andando controcorrente, allora devi confrontarli a riguardo. Se il problema persiste, potrebbe essere necessario coinvolgere gli altri.

Chiedi loro perché lo stanno facendo; una spiegazione valida può diminuire la tua frustrazione, ma dovresti far loro sapere quanto ti disturba. Chissà, forse hanno pensato che ti stessero facendo un favore e si fermeranno quando apprenderanno che ti offende. Oppure potresti avere a che fare con qualcuno che è veramente affetto da una condizione medica.

Gli è permesso? Le modifiche migliorano il codice? Se è così, ingoia il tuo orgoglio. Se ritieni che la qualità del codice sia peggiorata, prendila con il collega e chiedi loro perché hanno sentito la necessità di modificare il codice senza evidenti vantaggi. Se viene fatto per dispetto o perché la persona si sente erroneamente meglio di te e non riesci a risolverlo con loro, prendilo con il tuo capo.

Gli IDE come Visual Studio hanno un'opzione chiamata Format Documentche formatterà il codice in base alle regole che l'utente ha impostato nell'IDE. È possibile che il tuo collega lo stia utilizzando (automaticamente o senza saperlo o con una domanda deliberata). Forse il loro IDE utilizza spazi anziché tabulazioni o viceversa, e questi vengono applicati automaticamente senza nemmeno saperlo? Ma devi parlare con loro per scoprirlo.

Per inciso, spesso riformattare il codice dei colleghi se ovviamente non segue un qualche tipo di schema di formattazione (cioè è ovunque). Si spera un modo sottile per farli notare. (Tuttavia, non lo riformulerei se fosse pulito, ma non di mio gradimento).

Se lo sta cambiando in modo che soddisfi gli standard di codifica della tua squadra, dovresti seguire gli standard la prossima volta.

Se lo modifica in modo che non segua più gli standard di codifica della tua squadra, informalo che cosa sta facendo di sbagliato e chiedigli di cambiarlo.

... Il tuo team ha una serie di standard di formattazione del codice che sono utilizzati da tutti, giusto?

Occasionalmente riordinare il codice scritto da colleghi disordinati (o correggere errori di battitura nei commenti). Sanno che sono ossessivo nella formattazione e nell'ordine del codice e quindi mi permettono di farlo senza lamentarmi troppo. A volte mi danno anche una bibita o un biscotto gratis.

Ovviamente si tratta di un lavoro occasionale , in quanto ha rotto la funzionalità di "colpa" in SVN.

Questo è anche un modo molto semplice per fare una sorta di revisione del codice (di solito leggo la maggior parte del codice commesso dai miei colleghi nei moduli su cui sto lavorando).

Convenzioni di codice è la risposta. Dovresti averne uno al lavoro. In caso contrario, inizia subito (un buon punto di partenza è la guida di stile di Google ). Quando ci sono regole scritte (o almeno comunemente conosciute) la risposta alla tua domanda è banale.

Sento che stai pensando che sia offensivo farlo ...? Ad esempio, io stesso riparerei immediatamente questo codice

int myFunction( ) {

    int i ;
  return  0;

}

diventare

int myFunction() {
    int i;
    return 0;
}

quindi ... dovrei essere punito a causa della mia azione? Nella vita reale, in realtà ho tonnellate di registri SVN che leggono "Formattazione". ;-)

Utilizzare uno strumento di controllo dello stile

Inizia a utilizzare StyleCop o simili e applica le regole di stile del codice e impone inoltre a tutti gli sviluppatori di utilizzarlo. Tutto il codice avrà lo stesso aspetto senza eccezioni. E incontra i saggi per discutere delle regole più appropriate per la tua organizzazione. Anche se le regole predefinite sono già molto simili al codice framework .net stesso.

È il modo più semplice per farlo. Mi sono ritrovato a correggere il codice di qualcun altro in uno dei miei precedenti datori di lavoro perché quest'altro ragazzo stava scrivendo un codice con quantità eccessive di righe vuote e nessuna regola di rientro. Il codice era in realtà illeggibile da uno sviluppatore medio. Se StyleCop esistesse allora, molti di noi sarebbero davvero felici.

questo è un pensiero che ho visto su internet parlare di refactoring e forse spiegare perché qualcuno dovrebbe toccare il tuo codice per renderlo migliore:

Perché?

Esistono due motivi principali per il refactoring:

1. Per migliorare il codice / il design prima di costruirlo al top: è davvero difficile trovare un buon codice al primo tentativo. Il primo tentativo di implementare qualsiasi progetto iniziale ci mostrerà che abbiamo frainteso o dimenticato qualche logica.

2. Adattarsi ai cambiamenti nei requisiti. Il cambiamento avviene nello sviluppo del software; per rispondere ai cambiamenti è meglio avere una buona base di codice. Abbiamo due opzioni per entrambi gli scenari, il percorso del codice o il refactoring. L'applicazione di patch al codice ci porterà a un codice non mantenibile e aumenterà il nostro debito tecnico, è sempre meglio fare il refactoring.

Quando?

1. Prima è, meglio è, più è facile.

2. più veloce e meno rischioso di refactoring su un codice recentemente refactored piuttosto che in attesa di refactoring per il completamento del codice.

Che cosa?

1. Tutto il codice e tutto il design sono candidati per il refactoring.

2. Un'eccezione per il mancato refactoring di qualcosa potrebbe essere un pezzo di codice funzionante che ha una qualità bassa, ma a causa della scadenza prossima, preferiamo mantenere il nostro debito tecnico piuttosto che rischiare la planificazione.

Devi solo lasciargli fare del suo meglio, se sarebbe fantastico per entrambi e risparmiare tempo in futuro!

Saluti