Di recente, mi sono imbattuto in numerosi progetti open source su Ruby (o la maggior parte era Ruby) su GitHub che, controllati con uno strumento di analisi del codice come Rubocop , creano molti reati .

Ora, la maggior parte di questi reati include l'uso di virgolette doppie invece di virgolette singole (quando non interpolazione), non seguendo le regole di 2 spazi per livello, superando la regola della lunghezza della linea di 80 caratteri o usando {e }per i blocchi di più righe.

[La] Guida allo stile di Ruby raccomanda le migliori pratiche in modo che i programmatori Ruby del mondo reale possano scrivere codice che può essere gestito da altri programmatori Ruby del mondo reale. ~ Fonte: Guida allo stile Ruby

Sebbene siano piccoli e facili da risolvere, è opportuno modificare lo stile di codifica di un progetto open source correggendo i reati e facendo una richiesta pull? Riconosco che alcuni progetti, come Rails, non accettano modifiche estetiche e alcuni sono troppo grandi per "risolverli" in una volta (Rails, ad esempio, genera oltre 80.000 reati durante l'esecuzione di Rubocop, indipendentemente dal fatto che dispongano di una piccola serie di codici convenzioni da seguire quando si contribuisce). Dopotutto, la Ruby Style Guide è lì per un motivo insieme a strumenti come Rubocop.

Le persone apprezzano la coerenza, quindi apportare questo tipo di cambiamenti è una cosa positiva per la comunità di Ruby in generale, giusto?

[Gli autori della Ruby Style Guide] non hanno escogitato tutte le regole dal nulla - si basano principalmente sulla mia vasta carriera come ingegnere informatico professionista, feedback e suggerimenti dai membri della comunità Ruby e vari apprezzate risorse di programmazione di Ruby, come "Programming Ruby 1.9" e "The Ruby Programming Language". ~ Fonte: Guida allo stile Ruby

Seguire le convenzioni e le migliori pratiche di stile di codifica della comunità non incoraggia sostanzialmente le cattive pratiche?

Chiedi ai manutentori.

Lo stile di codifica è una discussione abbastanza soggettiva, e regole come la lunghezza massima di 80 caratteri sono abbastanza soggettive - mentre l'accordo generale dovrebbe essere che le linee più brevi sono meglio leggere, 80 potrebbe essere troppo restrittivo per alcuni con le dimensioni dello schermo e gli IDE di oggi.

Anche altre regole possono essere ignorate di proposito. Ad esempio, uno sviluppatore potrebbe considerare meglio per lui l'uso globale delle doppie virgolette ed essere disposto ad accettare il "rischio" di interpolazione accidentale e un aumento estremamente ridotto dei tempi di analisi.

Inoltre, molti manutentori non gradiscono grandi cambiamenti nello stile di codifica poiché sono noiosi da rivedere e c'è la possibilità che possano introdurre errori. Ad esempio, una stringa potrebbe passare a virgolette singole, anche se conteneva un'interpolazione deliberata e avrebbe dovuto utilizzare virgolette doppie. I manutentori preferiscono eseguire la pulizia dello stile mentre lavorano su quel codice reale in modo da poter verificare che i cambiamenti di stile non introducano nuovi bug.

Sembra che tu sia motivato in gran parte dal rispetto per l'autorità dello strumento Rubocop e della Guida allo stile Ruby, che i manutentori potrebbero non condividere. Hanno già il loro stile e ci sono abituati, quindi ogni cambiamento influenzerebbe tutti coloro che lavorano al progetto, e questo è molto lavoro, specialmente se il progetto è grande.

Considera le motivazioni dei manutentori. Probabilmente vogliono che nuove persone si uniscano a loro inviando correzioni di bug, segnalazioni di bug, codice di lavoro e documentazione ben scritta. Se ti presenti e dici "Hai offese nel rubocop" non penseranno "Oh bene, qualcuno nuovo per aiutare a condividere il carico", penseranno "Chi è questo ragazzo? Perché ci sta dicendo Cosa fare?".

I progetti open source tendono ad essere meritocrazie: ottieni rispetto in base alla qualità del tuo lavoro. Se ti presenti e fai grandi cose e poi fai emergere le tue preoccupazioni di stile, è più probabile che ascoltino, anche se potrebbero ancora dire di no. C'è un open source che dice "Talk è economico, mostrami il codice".

Pragmatismo sul dogma, sempre. Le guide di stile di programmazione sono una forma particolarmente insidiosa del male che distoglie l'attenzione dalle preoccupazioni architettoniche verso assurdità frivole come le citazioni singole / doppie. Chiediti: fa davvero la differenza?

Possono essere buoni fino a un certo punto, ma nel momento in cui li tratti con un fervore quasi religioso, sei andato troppo lontano. Sono linee guida, suggerimenti, opinioni, NON fatti.

Dovrebbero essere semplicemente ignorati allora? No, è utile utilizzare gli strumenti per avere un'idea generale di ciò che deve essere visto, ma non di più.

È una meraviglia di quanto spesso i tipi junior confondano l'opinione per i fatti.

Puoi apportare queste modifiche solo se esiste un problema aperto per correggere la formattazione. Altrimenti avvia il tuo ramo e se l'autore vede che più persone usano il tuo ramo semplicemente perché è più leggibile. Si uniranno nel ramo da soli, ma saranno pronti a mantenere il ramo unendo gli aggiornamenti e correggendo costantemente la formattazione.

Se il progetto non è abbastanza importante per te per continuare a mantenere il tuo ramo, non vale la pena ripulirlo in primo luogo.

Le richieste pull possono essere prese personalmente dall'autore. Non è un meccanismo per offrire critiche e riformattare tutto il codice potrebbe essere considerato una critica.

Se non vuoi mantenere la tua filiale, ma vuoi contribuire a un progetto. Apri un nuovo problema e descrivi il motivo per cui il formato corrente ti sta causando problemi, quindi offri di risolvere il problema per l'autore. Se l'autore è d'accordo, ti assegnerà il problema e ora hai il permesso di fare una richiesta pull.

Hai toccato un argomento che concordo anche sul fatto che sia un problema dilagante su GitHub . A parte la formattazione, ci sono una serie di progetti che usano erroneamente le annotazioni e causano il caos con molti IDE. Posso pensare a tre progetti ampiamente popolari che usano erroneamente flag obsoleti che propagano messaggi di avviso nel mio IDE. Ho inviato richieste pull per risolverli, ma gli autori non usano lo stesso IDE, quindi le richieste pull vengono ignorate.

La diramazione, la fusione e il fissaggio sembrano essere l'unica soluzione.

Tratto dal sito Rubocop stesso (enfasi mio):

Una cosa mi ha sempre infastidito come sviluppatore Ruby: gli sviluppatori Python hanno un ottimo riferimento allo stile di programmazione (PEP-8) e non abbiamo mai avuto una guida ufficiale , che documenta lo stile di codifica Ruby e le migliori pratiche.

Ti prego di capire:

Non esiste una guida ufficiale per lo stile Ruby

Non sto dicendo che le guide di stile siano cattive. Ma non solo non esiste una guida ufficiale, ma avere una guida di stile è una scelta fatta a livello personale, di progetto, di squadra, aziendale. Le guide di stile sono, per usare un termine psicologico, una "norma sociale in gruppo".

Cosa significa questo per te? Bene, se non sei considerato parte del gruppo, ciò significa che è improbabile che tu, o qualsiasi altro sito web, riesca a dominare il gruppo. Quindi, se non sei un collaboratore attivo e rispettato di quel progetto specifico, molto probabilmente i tuoi suggerimenti verranno ignorati, o nella migliore delle ipotesi saranno un promemoria di precedenti considerazioni sull'avere una guida di stile. Nel peggiore dei casi sarà preso come un insulto, o come un intruso o un motociclista che si conficca il naso in cui non appartiene.

Non puoi semplicemente suggerire una guida di stile?

In effetti, sembra essere quello che vuoi fare: credi nel valore delle guide di stile, apprezzi molto la coerenza e vuoi evangelizzare per la dedizione alle linee guida di stile unificate.

Va bene, a patto che tu sia davvero chiaro che è ciò di cui ti occupi e che cosa vuoi realizzare. Se credi in una guida di stile particolare e credi che sia la vera guida di stile, o almeno migliore di qualunque cosa quei pagani senza legge stiano correndo in pratica, allora va bene lo stesso.

Ma ciò che le persone non apprezzano viene detto che il loro comportamento non è conforme a regole non ufficiali, non vincolanti, in gran parte arbitrarie che provengono da una fonte che non considerano un'autorità legittima. Quando è quello che hai deciso di fare, o se semplicemente è quello che ti viene percepito , otterrai meno "trattamento sul tappeto rosso" e più "nativi arrabbiati con lance e una grande pentola bollente" trattamento.

Per offrire un parere alternativo qui, in molti casi, un tale cambiamento sarebbe il benvenuto. I progetti open source tendono ad avere molti autori. Spesso non esiste uno "stile di codifica"; lo stile è esattamente quello che la persona che ha scritto il codice in questione ha usato. Se un file è stato scritto da una persona diversa da un'altra, anche lo stile potrebbe essere diverso. Anche nei progetti in cui esiste uno stile di consenso, a meno che non verifichino regolarmente questo stile, spesso non viene utilizzato.

Un esempio comune di ciò nella mia esperienza è quando qualcuno contribuisce con un codice tramite richiesta pull che è di qualità relativamente bassa in termini di stile. Tuttavia, il codice potrebbe funzionare. Diverse persone hanno opinioni diverse su questo. Alcune persone si rifiuteranno di unire una richiesta pull a meno che lo stile non sia buono. Ad alcune persone non importa, finché il codice funziona. Alcune persone preferiscono avere un buon stile, ma non vogliono spaventare i partecipanti con un sacco di commenti "sistemati qui gli spazi bianchi" (personalmente mi sento sempre un po 'in colpa nel fare questi commenti, anche se so che sono in meglio buono della base di codice, perché sembra che potrebbe spaventare il collaboratore).

Quindi non dare per scontato che lo stile che vedi sia quello desiderato dal progetto. In effetti, ciò può probabilmente essere generalizzato a contribuire all'open source in generale: non dare per scontato che il codice di un progetto open source sia il codice che desidera .

Dovresti essere consapevole di alcune cose, però:

• Alcune persone sono religiose riguardo allo stile. Se diventa chiaro che non vogliono muoversi, allora non preoccuparti.

• Questo è un grosso problema in moto . Tutti e il loro fratello hanno un'opinione su queste cose. Ottenere una tale richiesta pull unita può essere difficile per questo.

• Può anche essere difficile ottenere una tale richiesta pull unita perché otterrà conflitti di unione molto rapidamente; praticamente ogni volta che qualsiasi parte della base di codice che hai modificato cambia, anche se in modo banale.

Attaccherei con l'approccio "chiedi prima". Se sono aperti e sei disposto a rispettare la richiesta pull fino al completamento, quindi procedi.

Ero abituato ad avere una buona guida di stile, ma dato lo stato delle cose in Ruby, "Sono passato".

Fondamentalmente vivo con quello con cui lavoro e seguo le convenzioni generali che ho imparato da diversi lavori.

Per Ruby, che è la mia lingua preferita, ho anche (nella mia testa) diviso lo stile in universalmente accettato, generalmente accettato, le mie preferenze e le migliori pratiche. Cose che sono universalmente accettate Potrei inviare una modifica come parte di una richiesta di modifica per un problema o una richiesta di diramazione di funzionalità.

Esempi di ogni stile (secondo me):

Universalmente accettato per Ruby:

• spazi non tabulazioni
• due trattini spaziali
• method_names_use_underscores
• Le costanti iniziano con Caps.

Generalmente accettato:

• Non usare le parentesi se non necessario
• Utilizzare { }per blocchi a una riga e do endper blocchi a più righe.
• CONSTANTS_ARE_IN_ALL_CAPS
• Usa istruzioni predicative ( cond ? true : false) su if thense l'espressione si adatta su 1 riga.

Preferenze personali:

• Lunghezza della riga di 120 righe di caratteri
• le whendichiarazioni case sono indentate 2 dall'istruzione case.
• Usa virgolette singole a meno che non siano necessarie doppie.

Nessun accordo:

• Dichiarazioni del caso
• Lunghezza della linea

Migliori pratiche:

• metodi piccoli, <= 5 righe se possibile.
• classi piccole, <= 100 righe se possibile.
• Evita le costanti
• Il codice ha dei test

Infine, come altri hanno dettagliato, dovresti chiedere prima. Alla fine della giornata, la chiave per lo stile è la comunicazione tra gli sviluppatori e la sensibilità verso gli altri. Ad esempio, se voglio apportare una modifica di stile su un progetto open source, spesso farò prima una richiesta pull per una o due funzionalità effettive o correzioni di bug. Una volta che il manutentore mi conosce e vede che ho contribuito, allora potrei suggerire dei cambiamenti di stile. Li consiglio solo però. Ad esempio "Mentre facevo un'altra funzione sul progetto x, ho notato che hai un rientro di 4 spazi in un paio di file e mi chiedevo se potevo cambiarli in 2?"

Sebbene siano piccoli e facili da risolvere, pensi che sia giusto cambiare lo stile di codifica di un progetto open source correggendo i reati e facendo una richiesta pull?

Insomma no!

Ovviamente, sto assumendo qui che si tratti solo di questioni di stile e non di veri e propri bug - le richieste pull per quest'ultimo sarebbero sempre sensate (IMO.) Suppongo anche che tu sia estraneo al progetto e non in contatto con le persone che lo mantengono già.

Tuttavia, tra tutte le lingue ci sono sempre alcune persone che hanno le loro preferenze che differiscono dalla guida di stile, nel bene e nel male, e che cercano di applicare quei cambiamenti di stile a persone che non conosci e un progetto a cui non fai parte di se nient'altro potesse sembrare un po 'maleducato. Dopotutto: cosa stai realizzando (in realtà) se la richiesta è stata accettata? Con ogni probabilità, se i membri di un progetto volessero cambiare lo stile in qualcosa di diverso, lo avrebbero già fatto - e tutto ciò che faresti con quella richiesta è forzare uno stile su di loro che non funziona necessariamente meglio per i membri esistenti.

Questo cambia leggermente se sei disposto a contribuire al progetto in altri modi oltre a fare "correzioni" di stile. Direi che se vuoi aprire un dialogo con i manutentori su come ti piacerebbe lavorare sul progetto ma trovare difficile uno stile non standard, allora va bene. Ma non vorrei semplicemente andare alla cieca creando richieste pull per un mucchio di progetti che contengono solo cambiamenti di stile!

QUALSIASI cambiamento è suscettibile di introdurre bug, anche cambiando la formulazione tipografica del codice.
Pertanto, non è necessario apportare modifiche al codice a meno che non vi sia un caso aziendale valido e "ma il codice non ha un bell'aspetto" o "il codice non segue gli standard di codifica" non è un caso aziendale valido. Il rischio è semplicemente troppo grande.
Ora, se stai comunque apportando importanti modifiche a un file sorgente, è possibile accettare l'intero file in linea con gli standard, ma molto probabilmente apporterai piccole modifiche nel qual caso è quasi universalmente preferibile mantenere le tue modifiche in linea con il codice esistente anche se quel codice esistente non segue gli standard di codifica.
Diamine, il codice potrebbe essere il risultato di un generatore di codice e talvolta essere rigenerato. I generatori di codice sono noti per la produzione di codice brutto ...

Ho un paio di progetti .NET di discreto successo e ho avuto un paio di PR di persone che sembrano aver superato il codice con ReSharper e StyleCop e "risolto" un sacco di cose. Non accetto questi PR, per un paio di motivi:

• Mentre molte delle modifiche sono in meglio, alcune hanno un impatto negativo sul codice in qualche modo, di solito le prestazioni e scegliere le parti buone è troppo difficile.
• Anche se tutte le modifiche sono state benigne o addirittura benefiche, ogni modifica in ogni file in ogni commit deve essere rivista e, di nuovo, ci vuole solo troppo tempo.

Detto questo, se qualcuno volesse aggiungere un migliore controllo degli errori o commenti doc, accetterei quel PR in un batter d'occhio.

È necessario scoprire se i manutentori considerano queste violazioni dello stile di codifica un difetto o se il progetto ha uno standard diverso per lo stile di codifica.

Se ha uno standard diverso, potresti offrire di aiutare a documentarlo o formalizzarlo. Quindi si potrebbe scoprire che ci sono alcune violazioni di quello stile e potresti risolverle.