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

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

Perché potresti sbagliarti. Potrebbe trattarsi di un piccolo bug fix e tu non l'hai notato.

Oppure, potrebbe esserci uno standard di codifica che non sai di ciò che stai violando, e lo stanno solo correggendo.

Oppure potrebbe essere che stiano cercando di infastidirti o che abbiano qualche forma di disturbo ossessivo-compulsivo. In questo caso, chiedigli gentilmente di smettere e, se ciò non funziona, fallo andare con il tuo capo.

Ma non lo saprai mai se non chiedi.

Non sono così sposato con il modo in cui il mio codice cerca di infastidirmi. :) 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 c'era già, di solito chiedo al collega che ha apportato i cambiamenti quale sia stata la motivazione che li ha motivati. È possibile che il vantaggio non sia ovvio per me. E se ho ragione e loro 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, però.

IMO tu e il tuo team dovreste comunque utilizzare uno standard di codifica. Se questo è il caso, allora 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 funzionalmente. Se "no", temo che il tuo collega abbia tutto il diritto di riordinare il tuo codice. Come un progetto guidato mi trovo a farlo tutto il tempo.

Se non stai usando uno standard di codifica, allora l'intera argomentazione di ciò che costituisce "codice buono" diventa troppo soggettiva. Quindi perché dovresti usare uno standard di codifica:)

Chiedi loro perché lo stanno facendo; una spiegazione valida può diminuire la tua frustrazione, ma dovresti far loro sapere quanto ti dà fastidio. Chissà, forse pensavano che ti stessero facendo un favore e si fermerebbero quando impareranno che ti offende. Oppure potresti avere a che fare con qualcuno che è veramente sofferente a causa di una condizione medica.

È permesso? Le modifiche migliorano il codice? Se è così, deglutisci il tuo orgoglio. Se ritieni che la qualità del codice sia peggiorata, affidati al collaboratore e chiedi loro perché hanno sentito la necessità di modificare il codice senza alcun beneficio evidente. Se viene fatto per dispetto o perché la persona ritiene erroneamente di essere migliore di te e non riesci a risolverlo con esso, fallo andare con il tuo capo.

Gli IDE come Visual Studio hanno un'opzione chiamata Format Document che formatta il codice in base alle regole che l'utente ha impostato nell'IDE. Potrebbe essere il tuo collega che sta usando questo (automaticamente senza sapere, o con un'applicazione 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 riformatterò il codice dei colleghi di lavoro se ovviamente non sta seguendo un qualche tipo di schema di formattazione (cioè è dappertutto). È un modo, sperabilmente sottile, di farli notare. (Tuttavia, non lo riformatterei se fosse pulito, ma non di mio gradimento).

Se la sta cambiando in modo da soddisfare gli standard di codifica della tua squadra, dovresti seguire gli standard la prossima volta.

Se lo cambia in modo tale da non seguire più gli standard di codifica della tua squadra, informalo su cosa sta facendo male e chiedigli di cambiarlo.

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

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

Ovviamente questo è un lavoro occasionale , in quanto ha rotto la funzionalità "blame" 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 del codice è la risposta. Dovresti averne uno al lavoro. Se non lo fai, inizia subito (un buon punto di partenza è guida allo stile di google ). Quando ci sono regole scritte (o almeno conosciute) la risposta alla tua domanda è banale.

Sento che pensi che sia offensivo farlo ...? Ad esempio, io stesso risolverei 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 log SVN leggere 'Formattazione'. ; -)

Utilizza uno strumento di controllo dello stile

Inizia a utilizzare StyleCop o simili e applica le regole di stile del codice e rendi anche un obbligo per tutti gli sviluppatori di utilizzarlo. Tutto il codice sarà uguale senza eccezioni. E unisciti a wiseheads per discutere le regole più appropriate per la tua organizzazione. Anche se le regole di default sono molto simili al codice del framework .net già.

È 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é questo altro ragazzo stava scrivendo codice con quantità eccessive di righe vuote e senza regole di indentazione di sorta. Il codice era in realtà illeggibile da uno sviluppatore medio. Se StyleCop esistesse allora renderebbe molti di noi davvero felici.

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

Perché?

Ci sono due ragioni principali per il refactoring:

1. Per migliorare il codice / design prima costruendo su di esso: è davvero difficile trovare un buon codice il primo tentativo. Il primo tentativo di implementare qualsiasi volontà di progettazione iniziale mostraci che abbiamo interpretato male o dimenticato qualche logica.

2. Per adattarsi ai cambiamenti nel requisiti. Il cambiamento accade nel sviluppo software; essere reagire al cambiamento è meglio avere una buona base di codice. Abbiamo due opzioni per entrambi gli scenari, percorso il codice o refactoring. Patching the il codice ci porterà a non mantenibili codice, e aumenterà il nostro debito tecnico, è sempre meglio a refactoring.

Quando?

1. Quanto prima è il migliore è più facile.

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

Che cosa?

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

2. Un'eccezione per non riscrivere qualcosa potrebbe essere un pezzo di codice funzionante, la cui qualità è bassa, ma essendo vicina a una scadenza, preferiamo mantenere il nostro debito tecnico piuttosto che rischiare la planificazione.

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

applausi