Quando si contribuisce a un progetto di dominio pubblico o open source apparentemente non più mantenuto, si suggerisce di seguire lo stile di codifica dell'autore originale anche se è terribile?Segui lo stile di codifica dell'autore originale? Anche se è orribile/pigro/ti fa sanguinare gli occhi?
Ancora più importante, ci sono motivi per cui si vorrebbe seguire lo stile di codifica dell'autore originale piuttosto che ripulirlo in modo significativo?
Seguire lo stile di codifica originale. È molto, molto meglio essere coerente, anche se non è carino per te.
Se si decide di ripulire lo stile di codifica, farlo separatamente da eventuali altre modifiche. Non ingombrare il controllo del codice sorgente con i cambiamenti di stile. Crea uno (o più) checkin in cui la sola cosa sta cambiando lo stile del codice. Non mescolare i cambiamenti reali con cambiamenti insignificanti, rende impossibile individuare le modifiche rilevanti quando si verifica il controllo del codice sorgente.
Se si sa che è non mantenuto, e si stanno apportando modifiche ad esso, quindi ho il sospetto che si diventerà il proprietario/manutentore defacto in futuro.
Quindi, detto questo, manderei una e-mail all'autore/manutentore originale, vedere cosa pensano della formattazione o dei cambiamenti di stile e andare avanti con le pistole in fiamme.
Se non si inviano patch, quindi no. Eseguilo attraverso un filtro di codice e formatta automaticamente il codice nel tuo stile preferito, quindi esegui l'hacking.
Se non viene nemmeno mantenuto perché ti preoccupi?
Scriverò usando il mio stile preferito e pulendo qualsiasi codice con cui ho dovuto lavorare. Lo faccio regolarmente anche al lavoro ...
Bene, direi che se si sta apportando una piccola modifica all'interno di una funzione, potrebbe essere più chiaro seguire lo stile negativo.
Se si creano nuovi metodi, classi, proprietà e così via, utilizzare uno stile chiaro ed efficiente. Puoi aggiungere un commento all'inizio di queste sezioni, in modo che altri possano capire cosa sta succedendo. Potresti anche aggiungere una breve nota in alto che spiega quando hai iniziato il codice e che stavi utilizzando uno stile diverso, ecc.
Se esegui il controllo del codice sorgente, puoi lasciarlo da solo come tutto lo stile le modifiche renderanno impossibile il confronto con le versioni precedenti.
Se si vuole cambiare lo stile fanno con il codice di riferimento prima di apportare altre modifiche e quindi controllare in.
Poi Check it out e apportare le modifiche di codifica. In questo modo sarà più facile tracciare le tue modifiche dal punto in cui l'hai presa.
Personalmente lascerei lo stile da solo a meno che non stiate apportando modifiche significative.
Heck no! Qualunque cosa tu faccia non rendere peggio per l'amor del cielo!
Se si aggiunge il proprio codice farlo nel proprio stile. Questo renderà almeno parte della base di codice facile da mantenere e capire. Se stai apportando aggiornamenti minori al codice esistente, potresti voler seguire quello stile.
Sono sulla stessa barca, devo mantenere un sistema basato su Access 2, business critical, che è un miscuglio completo di stili.
Quale sarebbe la vostra risposta se la domanda fosse: Dovreste mantenere la stessa fattura scadente quando state ristrutturando la vostra casa?
Se stai riparando un muro rotto nel bagno, non vale la pena ri-piastrellare l'intero muro perché non hanno usato il muro a secco giusto.
Quando si rimodella la cucina, è possibile correggere l'impianto idraulico per quella stanza o raddrizzare un pavimento difettoso. Questo perché rende il resto del lavoro più facile per te. E questo è tutto, che tipo di vantaggio ti dà rispetto al costo per te/il tuo cliente.
Non si ricollegherebbe una lampada perché aveva bisogno di una nuova lampadina.
Se si sta codificando per uno standard definito dall'azienda (o anche solo uno standard definito dal team), e il codice su cui si sta lavorando non corrisponde allo standard (o è così vecchio che non lo è corrisponde allo standard attuale), quindi pulisci definitivamente il codice se stai per apportare modifiche importanti comunque. (Come altri hanno già detto, fallo nel codice di riferimento e verificalo. Quindi controlla di nuovo e apporta le modifiche che devi apportare per correggere bug, aggiungere funzionalità, ecc.)
Come affermato da altri , assicurarsi che tutte le modifiche di stile siano verificate nel proprio sistema di controllo della versione separatamente dalle modifiche funzionali.
Tuttavia, il mio suggerimento è di essere in grassetto e ripulire il codice come meglio credi; "Lascia il campeggio più pulito di quello che hai trovato". Formaggio, ma vero;)
Basta fare in modo che si sono preparati a difendere le modifiche;)
1 - L'unica volta vorrei andare contro questo consiglio è se lo stile codice originale era orribile * perché * è era incoerente. –
+1 per la separazione dei commit delle modifiche al codice rispetto alle variazioni di stile – crashmstr
Ben inserito. +1 per aver discusso delle differenze: questo è un problema ENORME. Ho anche visto degli errori introdotti dopo la "riformattazione del codice" quando, ad esempio, le persone hanno abbandonato (o rimosso) {} che hanno causato problemi. – DarkSquid