Etichetta aperta all'origine

Va bene, se sei modesto e non infrange nulla . Non è possibile aggirare il codice di riformattazione e introdurre bug. Ha buoni test unitari? Altrimenti, inizierei a contribuire aggiungendo i test unitari e poi a correggere la struttura più tardi.

Lo scopo dell'open source è di avere più occhi su un progetto e migliorarlo. Ciò include rendere il codice migliore. Detto questo, è una buona forma pubblicizzare sulla lista quello che intendi fare. Potresti ottenere un respingimento o potresti ottenere un mucchio di +1. Quelle dichiarazioni goto potrebbero essere lì perché l'autore originale non poteva pensare a un modo migliore per portare a termine il lavoro. Se si ottiene il respingimento, è bene inserire una finestra di dialogo per scoprire da dove proviene la pressione. Cerca di non farlo diventare personale e cerca di risolvere i problemi.

In conclusione, i test unitari parlano più strong del dogma. Se riesci a dimostrare che il codice funzionerà male in certi casi come è ora, avrai il pollice alzato o l'autore originale entrerà e sistemerà le cose.

Ricorda che nell'open source la community è più importante del codice. Se non esiste una comunità (sia per gli utenti che per gli sviluppatori), non c'è alcun progetto.

Le persone che sono gelosamente difensive riguardo al loro codice in genere non le pubblicano per il controllo del mondo, e se lo fanno, la comunità circostante non dura molto a lungo. Siate cortesi, ma non preoccupatevi di ferire i sentimenti.

Dì semplicemente quello che vuoi fare prima di investire troppo tempo in esso. A volte ci sono ragioni storiche per cose che non sono ovvie. Il motivo per cui le gotos vengono evitate è che possono produrre percorsi imprevisti attraverso il codice. Di conseguenza, il pericolo di rimuovere gotos è che non si nota uno dei percorsi vantaggiosi e lo si omette accidentalmente dal refactoring.

D'altra parte, forse l'autore originale non riusciva a pensare a un modo più pulito di scriverlo al momento. È qui che il codice parla più strong delle parole, perché potrebbero non credere che possa essere fatto più pulito finché non le mostri. Uno dei miei primi contributi open source è stato un fix di undo stack che ha migliorato significativamente le prestazioni, ma che alcuni degli sviluppatori core hanno detto che erano troppo complessi quando l'ho descritto per la prima volta. Un campione di codice breve li ha portati a bordo.

Se si scopre che ci sono davvero dei buoni motivi per lasciarlo, spingo almeno per un commento che spieghi queste ragioni.

Parlando dall'esperienza ...

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

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

Se stai lavorando con qualcuno che è "buono" (come lo ero io) (s), rifiuterà immediatamente la patch. Principalmente perché, quando contribuisci a un progetto open source, devi abbattere le tue correzioni in blocchi di dimensioni di morso che risolvono un singolo problema. 'Removed all gotos' non è un buon esempio di commit atomico. Anche se lo si analizza in commit più piccoli e ben documentati, potrebbe essere ancora respinto.

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

Il codice di refactoring e l'aggiunta di funzionalità (o la rimozione di cruft deprecati) 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 presentando. Se puoi dare una buona ragione, c'è una migliore possibilità che la tua patch venga inviata.

Il mio consiglio è di fare alcune di queste modifiche su un file sorgente per dare un assaggio di ciò che stai cercando di fare prima. Se i cambiamenti sono ben giustificati e accettati, chiedete se ulteriori cambiamenti come questo migliorerebbero la qualità del progetto. In questo modo non sprecherai un grande sforzo per nulla se le tue patch verranno rifiutate in futuro.

Lo sviluppo di open source è più che scrivere codice. Stai lavorando per creare una relazione di fiducia perché i gatekeeper (sviluppatori che controllano l'accesso push) faranno ciò che devono per proteggere l'integrità del progetto. Mentre invii più patch il gatekeeper avrà una migliore percezione del tuo stile e non dovrai giustificare tanto le tue modifiche.

È un processo che richiede tempo ma è molto gratificante. Non solo imparerai molto dall'essere in grado di guardare e criticare il codice di qualcuno, ma tu sarà essere criticato sul tuo stile.

Prima di perdere un sacco di tempo cercando di "correggere l'ingiustizia degli errori dello stile di codifica altrui", chiediti:

Are the changes you're proposing based on adding value to the project or are they based on your own internal stylistic religion.

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

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

Nota: tutto questo consiglio presuppone che il tuo gatekeeper sia un programmatore ragionevole e di talento. Se (s) è, conta te stesso fortunato che non sei rimasto bloccato con uno dei whily b @ & # & la cui unica preoccupazione è proteggere il loro 'bambino'. Loro fanno esistono in natura, quindi non sorprenderti se ne incontri uno.

Qualità > Etiquette

Secondo me non dovresti preoccuparti di modificare il codice di altre persone non appena scopri che è di scarsa qualità. Per ottenere una buona qualità del software, è sufficiente avere cura del codice pulito. Non vedo alcun problema nel commettere miglioramenti al codice di altre persone che dovrebbero essere consapevoli e grati che ci siano programmatori che lavorano sul loro codice.

Se riesci a trovare un modo migliore per risolvere il problema senza utilizzare "goto", ti suggerisco di farlo. Un piccolo sforzo per rendere il codice migliore oggi potrebbe 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 assembly - un sacco di gotos (salti e rami) dappertutto.

Il motivo per cui goto ha un brutto nome in questi giorni è dovuto al documento Dijkstra Vai a dichiarazione considerata dannosa che ha evidenziato l'istruzione goto come una cosa molto brutta.

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

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

Questo è stato un passo verso l'introduzione di cose come chiamate di metodo con argomenti, modularizzazione di codice, pacchetti ecc. che sono stati tutti introdotti per domare la complessità dello sviluppo del software. La dichiarazione goto era solo la prima in questa guerra.