Segui la convenzione di denominazione del programmatore originale?

StackOverflow https://stackoverflow.com/questions/284113

Domanda

Se assumi un progetto da qualcuno per fare semplici aggiornamenti segui la sua convenzione di denominazione? Ho appena ricevuto un progetto in cui il programmatore precedente utilizzava Notazione ungherese ovunque. Il nostro prodotto principale ha uno standard di denominazione, ma nel corso degli anni molte persone hanno realizzato report personalizzati e hanno fatto quello che si sentivano.

Non ho tempo di cambiare tutti i nomi delle variabili già presenti nel codice.

Sono propenso alla leggibilità solo per continuare con la loro convenzione di denominazione.

È stato utile?

Soluzione

Sì, lo so. Rende più facile seguire le persone che lo ereditano dopo di te. Cerco di ripulire un po 'il codice per renderlo più leggibile se è davvero difficile da capire.

Altri suggerimenti

Concordo suggerendo che lasciare il codice come l'autore ha scritto va bene purché tale codice sia internamente coerente. Se il codice è difficile da seguire a causa di incoerenza, si ha la responsabilità di manutentore futuro (probabilmente tu) per renderlo più chiaro.

Se trascorri 40 ore a capire cosa fa una funzione perché usa variabili scarsamente nominate, ecc., dovresti riformattare / rinominare per chiarezza / aggiungere commenti / fare tutto ciò che è appropriato per la situazione.

Detto questo, se l'unico problema è che lo stile per lo più coerente utilizzato dall'autore è diverso dallo standard aziendale o da quello a cui sei abituato, penso che stai perdendo tempo a rinominare tutto. Inoltre, potresti perdere una fonte di competenza se l'autore originale è ancora disponibile per domande perché non riconoscerà più il codice.

Se non stai cambiando tutto il codice esistente con il tuo standard, direi che segui le convenzioni originali fintanto che stai modificando quei file. Mescolare due stili di codice nello stesso file sta distruggendo qualsiasi vantaggio che avrebbe uno stile di codice coerente, e il ragazzo successivo dovrebbe chiedersi costantemente " chi ha scritto questa funzione, come si chiamerà - FooBar () o fooBar () "?

Questo tipo di cose diventa ancora più complicato quando si importano librerie di terze parti: non si desidera riscriverle, ma il loro stile di codice potrebbe non corrispondere alle tue. Quindi, alla fine, ti ritroverai con diverse convenzioni di denominazione, ed è meglio tracciare linee chiare tra "il nostro codice" e " il loro codice " ;.

Spesso, apportare una modifica all'ingrosso a una base di codice solo per conformarsi alla guida di stile è solo un modo per introdurre nuovi bug con poco valore aggiunto.

Ciò significa che dovresti:

  1. Aggiorna il codice su cui stai lavorando per renderlo conforme alle linee guida mentre lavori su di esso.

  2. Usa le convenzioni nel codice per aiutare i futuri interventi di manutenzione.

Consiglierei 2., ma la Notazione ungherese mi fa sanguinare gli occhi: p.

Se stai mantenendo il codice che altri hanno scritto e che altre persone manterranno dopo di te, lo devi a tutti i soggetti coinvolti per non apportare modifiche gratuite. Quando entrano nel sistema di controllo del codice sorgente per vedere cosa hai cambiato, dovrebbero vedere cosa era necessario per risolvere il problema su cui stavi lavorando e non un milione di differenze perché hai fatto un sacco di ricerche globali e sostituito o riformattato il codice per adatta la tua convenzione di abbinamento del tutore preferito.

Naturalmente, se il codice originale fa davvero schifo, tutte le scommesse sono disattivate.

In generale, sì, preferirei convenzioni e leggibilità rispetto agli standard in questo scenario. A nessuno piace questa risposta, ma è la cosa giusta da fare per mantenere il codice mantenibile a lungo termine.

Quando un buon programmatore legge il codice, dovrebbe essere in grado di analizzare i nomi delle variabili e tenere traccia di diversi nella sua testa - purché coerenti, almeno all'interno del file sorgente. Ma se si interrompe tale coerenza, probabilmente costringerà il programmatore a leggere il codice a soffrire di dissonanza cognitiva, il che renderebbe un po 'più difficile tenere traccia di. Non è un assassino - i bravi programmatori lo supereranno, ma malediranno il tuo nome e probabilmente ti pubblicheranno su TheDailyWTF .

Continuerei sicuramente a usare la stessa convenzione di denominazione, poiché manterrà il codice coerente (anche se è costantemente brutto) e più leggibile rispetto alla combinazione di convenzioni di denominazione variabili. I cervelli umani sembrano essere piuttosto bravi nel riconoscimento di schemi e non vuoi davvero lanciare al cervello una palla curva rompendo gratuitamente detto schema.

Detto questo, sono tutt'altro che un po 'di notazione ungherese, ma se è quello con cui devi lavorare ...

Se il file o il progetto sono già scritti usando uno stile coerente, allora dovresti provare a seguire quello stile, anche se è in conflitto / contraddice il tuo stile esistente. Uno degli obiettivi principali di uno stile di codice è la coerenza, quindi se si introduce uno stile diverso nel codice che è già coerente (in sé) si perde quella coerenza.

Se il codice è scritto male e richiede un certo livello di pulizia per capirlo, ripulire lo stile diventa un'opzione più pertinente, ma dovresti farlo solo se assolutamente necessario (specialmente se non ci sono test unitari) come corri la possibilità di introdurre cambiamenti di rottura imprevisti.

Assolutamente sì. L'unico caso in cui non credo sia preferibile seguire la convenzione di denominazione del programmatore originale è quando il programmatore originale (o i successivi sviluppatori che hanno modificato il codice da allora) non sono riusciti a seguire una convenzione di denominazione coerente.

Sì. In realtà l'ho scritto in un documento sugli standard. Ho creato presso la mia attuale azienda:

Il codice esistente sostituisce tutti gli altri standard e pratiche (siano essi standard di settore o quelli presenti in questo documento). Nella maggior parte dei casi, dovresti camaleggiare il tuo codice in modo che corrisponda al codice esistente negli stessi file, per due motivi:

  1. Per evitare di avere più stili / motivi distinti all'interno di un singolo modulo / file (che contraddicono lo scopo degli standard e ostacolano la manutenibilità).
  2. Lo sforzo di refactoring del codice esistente tende ad essere inutilmente più costoso (richiede tempo e favorisce l'introduzione di nuovi bug).

Personalmente ogni volta che prendo il controllo di un progetto che ha uno schema di denominazione variabile diverso, tendo a mantenere lo stesso schema utilizzato dal programmatore precedente. L'unica cosa che faccio è diversa per ogni nuova variabile che aggiungo, ho messo un trattino basso prima del nome della variabile. In questo modo posso vedere rapidamente le mie variabili e il mio codice senza dover accedere alla cronologia dei sorgenti e confrontare le versioni. Ma quando si tratta di ereditare codice o commenti semplicemente illeggibili, di solito li analizzo e li ripulisco come meglio posso senza riscrivere il tutto (è arrivato a quello). L'organizzazione è la chiave per avere un codice estensibile!

se riesco a leggere il codice, (provo) a prendere le stesse convenzioni se non è comunque leggibile, ho bisogno di refactoring e quindi cambiarlo (a seconda di come è) considerevole

Dipende. Se sto costruendo una nuova app e rubando il codice da un'app legacy con una denominazione variabile merda, rifatterò una volta inserito nella mia app.

Si .. C'è litte che è più frustrante che entrare in un'applicazione che ha due stili drasticamente diversi. Un progetto su cui ho lavorato di recente ha avuto due modi diversi di manipolare i file, due modi diversi di implementare schermate, due diverse strutture fondamentali. Il secondo programmatore è persino arrivato a rendere le nuove funzionalità parte di una dll che viene chiamata dal codice principale. La manutenzione era da incubo e ho dovuto imparare sia i paradigmi che la speranza quando ero in una sezione che stavo lavorando con quello giusto.

Quando a Roma fai come fanno i romani.

(Ad eccezione dei nomi delle variabili indice, ad es. " iArrayIndex ++ " ;. Smetti di perdonare quell'idiozia.)

Penso di fare una correzione di bug come una procedura chirurgica. Entra, disturba il meno possibile, correggilo, esci, lascia la minima traccia del tuo essere lì.

Lo faccio, ma sfortunatamente, lì dove diversi sviluppatori prima di me non rispettavano questa regola, quindi ho diverse convenzioni di denominazione tra cui scegliere.

Ma a volte abbiamo il tempo di sistemare le cose, quindi alla fine sarà bello e pulito.

Se il codice ha già uno stile coerente, inclusa la denominazione, provo a seguirlo. Se i programmatori precedenti non erano coerenti, mi sento libero di applicare lo standard aziendale o i miei standard personali se non esiste uno standard aziendale.

In entrambi i casi cerco di contrassegnare le modifiche che ho fatto inquadrandole con commenti. So che con i sistemi CVS odierni questo spesso non viene fatto, ma preferisco ancora farlo.

Sfortunatamente, la maggior parte delle volte la risposta è sì. Il più delle volte, il codice non segue le buone convenzioni, quindi è difficile seguire il precedente. Ma per leggibilità, a volte è necessario seguire il flusso.

Tuttavia , se si tratta di un'applicazione abbastanza piccola, posso refactificare gran parte del codice esistente in "odore". meglio, allora lo farò. Oppure, se questo fa parte di una riscrittura più ampia, inizierò anche a programmare con gli attuali standard di codifica. Ma di solito non è così.

Se c'è uno standard nell'app esistente, penso che sia meglio seguirlo. Se non esiste uno standard (schede e spazi misti, parentesi graffe ovunque ... oh l'orrore), allora faccio quello che ritengo migliore e generalmente eseguo il codice esistente attraverso uno strumento di formattazione (come Vim). Manterrò sempre lo stile delle maiuscole, ecc. Del codice esistente se esiste uno stile coerente.

La mia unica eccezione a questa regola è che non userò la notazione ungherese a meno che qualcuno non abbia una pistola in testa. Non mi prenderò il tempo per rinominare le cose esistenti, ma tutto ciò che aggiungo nuovo non avrà alcuna verruca ungherese su di essa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top