Etichetta Open Source

Ho iniziato a lavorare al mio primo progetto open source su Codeplex e ho trovato un codice terribile. (Ho imparato che C # ha ancora l'istruzione "goto") Ho iniziato ad aggiungere funzionalità che il "proprietario" voleva e dopo aver esplorato la base di codice e visto che casino era (ad esempio usando "goto") volevo ripulirlo un po. Ma sono un po 'preoccupato ed è per questo che mi rivolgo a tutti voi: è corretto galateo per me "correggere" il "codice errato" o dovrei lasciarlo e lavorare su nuove funzionalità? Come ho detto prima, sono nuovo in tutta la scena OSS e lavoro in una squadra in generale, quindi non vorrei rovinare tutto.

Va bene farlo, se sei modesto e non si rompe nulla . Non puoi andare in giro riformattando il codice e introducendo dei bug. Ha buoni test unitari? In caso contrario, inizierei a contribuire con l'aggiunta di unit test e poi aggiusterò la struttura in seguito.

Lo scopo dell'open source è quello di avere più occhi su un progetto e migliorarlo. Ciò include migliorare il codice. Detto questo, è una buona forma pubblicizzare sulla lista ciò che si intende fare. Potresti ottenere un po 'di push back o potresti avere un sacco di +1. Quelle gotoaffermazioni potrebbero essere lì perché l'autore originale non poteva pensare a un modo migliore per portare a termine il lavoro. Se torni indietro, è bene entrare in una finestra di dialogo per scoprire da dove proviene la pressione. Cerca di non lasciare che diventi personale e cerca di affrontare le preoccupazioni.

In conclusione, i test unitari parlano più forte del dogma. Se puoi provare che il codice non funzionerà in certi casi così com'è adesso, otterrai il pollice in alto o l'autore originale entrerà e risolverà le cose.

Ricorda, in open source, la community è più importante del codice. Se non esiste una comunità (sia degli utenti che degli sviluppatori), non esiste alcun progetto.

Le persone che sono gelosamente difensive del loro codice in genere non pubblicano il mondo affinché venga esaminato a fondo, e se lo fanno, la comunità circostante non dura molto a lungo. Sii discreto, ma non preoccuparti che ferirai i sentimenti.

Basta dire loro cosa vuoi fare prima di investire troppo tempo in esso. A volte ci sono ragioni storiche per cose non ovvie. Il motivo per cui i goto vengono evitati è che possono produrre percorsi imprevisti attraverso il codice. Di conseguenza, il pericolo di rimuovere goto è che non si nota uno dei percorsi benefici e lo si omette accidentalmente dal refactor.

D'altra parte, forse l'autore originale non riusciva a pensare a un modo più pulito di scriverlo in quel momento. È qui che il codice parla più forte delle parole, perché potrebbero non credere che possa essere fatto più pulito fino a quando non le mostri. Uno dei miei primi contributi open source è stato una correzione dello stack di annullamento che ha migliorato significativamente le prestazioni, ma che alcuni sviluppatori principali hanno affermato che sembrava troppo complesso quando l'ho descritto per la prima volta. Un esempio di codice breve li ha portati a bordo.

Se si scopre che ci sono davvero dei buoni motivi per lasciarlo entrare, spingerei almeno per un commento che spieghi questi motivi.

Parlando per esperienza ...

Il primo progetto Open Source a cui ho contribuito, ero pieno di piscio e aceto quando ho iniziato anche io.

Ciò che ho fatto immediatamente è stato passare attraverso un mucchio di file sorgente e iniziare a stilizzare le cose secondo le mie preferenze personali, creare una patch enorme e inviarla.

Se stai lavorando con qualcuno che è "buono" (come lo ero io), rifiuterà immediatamente la patch. Soprattutto perché, quando si contribuisce a un progetto open source, è necessario suddividere le correzioni in blocchi di dimensioni ridotte che risolvono un singolo problema. 'Removed all gotos' non è un buon esempio di commit atomico. Anche se lo si suddivide in commit più piccoli e ben documentati, potrebbe comunque essere rifiutato.

Il motivo è che, poiché il codice viene elaborato da più persone (con stili diversi) nel tempo, non è realmente possibile accettare modifiche nell'intera libreria per adattarsi allo stile di uno sviluppatore. Se fosse possibile cambiare stile per motivi di stile, ogni progetto open source non andrebbe mai avanti perché il codice verrebbe costantemente modificato per adattarsi a diversi stili di sviluppo.

Il refactoring del codice e l'aggiunta di funzionalità (o la rimozione di cruft obsoleto) di solito hanno la precedenza sul codice di "pulizia".

La parte più difficile e gratificante di lavorare su un progetto open source è, ti verrà chiesto perché stai proponendo di apportare le modifiche che stai inviando. Se puoi dare una buona ragione, ci sono maggiori possibilità che la tua patch venga inviata.

Il mio consiglio è di apportare alcune di queste modifiche su un file sorgente per dare un'idea di ciò che stai cercando di fare prima. Se le modifiche sono ben giustificate e accettate, chiedi se ulteriori modifiche potrebbero migliorare la qualità del progetto. In questo modo non perderai molto sforzo per nulla se le tue patch verranno rifiutate in futuro.

Lo sviluppo di open source è molto più che scrivere codice. Stai lavorando per costruire una relazione di fiducia perché lo faranno i gatekeeper (gli sviluppatori che controllano l'accesso push) ciò che devono per proteggere l'integrità del progetto. Man mano che invii più patch, il gatekeeper percepirà meglio il tuo stile e non dovrai giustificare le tue modifiche.

È un processo che richiede tempo ma è molto gratificante. Non solo si impara molto da essere in grado di guardare e criticare il codice di qualcun altro, ma si sarà essere criticato sul proprio stile.

Prima di perdere molto tempo a cercare di "correggere l'ingiustizia degli errori dello stile di programmazione degli altri", chiediti:

Le modifiche che stai proponendo si basano sull'aggiunta di valore al progetto o sulla base della tua religione stilistica interna.

C'è molta religione su Stack Overflow (e relativi siti di scambio di stack). Intendo molto . Le persone pensano e parlano dello stile all'infinito, come se più ne parli, più ti avvicini allo stile di codifica "perfetto, ideale, indistruttibile, infallibile". Ne parlo troppo soprattutto perché è divertente.

Nel mondo Open Source, lo stile non è così importante. La funzione è .

Nota: tutti questi consigli presuppongono che il tuo gatekeeper sia un programmatore ragionevole e di talento. Se lo è, considera fortunato di non esserti bloccato con uno dei bizzarri b & & # & es la cui unica preoccupazione è proteggere il loro "bambino". Essi non esistono in natura, quindi non stupitevi se si verifica uno.

Qualità> Etichetta

Secondo me non dovresti preoccuparti di modificare il codice di altre persone non appena scopri che ha una qualità scadente. Per ottenere una buona qualità del software, devi semplicemente preoccuparti di un codice pulito. Non vedo alcun problema nel commettere miglioramenti al codice di altre persone, altre persone dovrebbero essere consapevoli e grate che ci siano programmatori che lavorano sul loro codice.

Se riuscissi a trovare un modo migliore per risolvere il problema senza usare "goto", allora ti suggerisco di provarlo. Un piccolo sforzo per migliorare il codice oggi può farti risparmiare molto più impegno in futuro.

Anche comunicare con l'autore originale è una buona idea.

Non c'è nulla di implicitamente sbagliato in goto. Guarda il codice dell'assemblaggio - molte goto (salti e rami) dappertutto.

Il motivo per cui gotoha un brutto nome in questi giorni è a causa della dichiarazione Go To del documento Dijkstra considerata dannosa che ha indicato la dichiarazione goto come una cosa molto brutta.

Si noti che 50 anni fa non era ancora stata nominata l'ingegneria del software e che la maggior parte dei linguaggi di programmazione erano essenzialmente astrazioni della macchina sottostante, così come il linguaggio della macchina conteneva goto, così fecero. Puoi provare a programmarne alcuni in Microsoft Basic (quello originale, su Apple] [o Commodore 64) per avere un'idea di come fosse quella mentalità.

Ciò di cui Dijkstra stava sostenendo era che per mantenere le cose semplici non saltare dappertutto, ma invece mantenere un percorso di programma più semplice con un finale comune. Ad esempio un ritorno da un metodo. In altre parole, solo salti locali, non globali.

Questo è stato un passo verso l'introduzione di chiamate a metodi con argomenti, modularizzazione di codice, pacchetti ecc. Che sono stati tutti introdotti per domare la complessità dello sviluppo del software. La dichiarazione goto fu solo il primo spettatore in quella guerra.