Se trovo un errore di battitura non critico nel codice (diciamo, un apostrofo errato in un'istruzione di stampa (errore)), vale la pena impegnarsi per risolvere l'errore, o dovrebbe essere semplicemente lasciato solo?

In particolare, sono curioso di valutare il gumming-up del registro di commit rispetto al valore di risoluzione di questi errori di battitura non critici. Sono propenso a risolverli. Sono pedante?

La mia sensazione personale è che il miglioramento della qualità valga il piccolo inconveniente di una voce aggiuntiva del registro di commit, anche per piccoli miglioramenti. Dopotutto, i piccoli miglioramenti contano molto quando si tiene conto dell'effetto finestra rotta .

Potresti voler aggiungere un prefisso con un TRIVIAL:tag o contrassegnarlo come banale se il tuo VCS lo supporta.

Non sei pedante, ed è meglio risolverli individualmente. Più una modifica è atomica, meglio è: non si desidera confondere una correzione di bug con 500 modifiche di commento / errore di battitura.

Nel caso generale: Sì

Ne vale sempre la pena per aumentare la manutenibilità del tuo software.

Provaci.

Se stai per inviare un rilascio ...

... e se non sei il capo squadra, verifica con lui / lei .

Per quanto riguarda il contenuto del registro di commit ...

Concordo con gli altri sul fatto che dovresti almeno scrivere qualcosa che lo distingua dai commit relativi a "feature", se si tratta solo di correggere un refuso isolato.

Una pratica comune è avere alcune attività che non muoiono mai nel tracker dei problemi per tenere traccia delle modifiche senza tempo e senza fine. Ad esempio, non è raro avere un'attività per:

• grandi pulizie automatizzate innocue (spazzate di spazi bianchi),
• battute di caccia alla grammatica e agli errori di battitura,
• costruire modifiche al sistema,
• eccetera...

Basta essere cauti sul fatto che questi non vengono utilizzati come ID attività da buttare via per qualsiasi cosa quando le persone diventano pigre sulla creazione di biglietti correttamente documentati. Soprattutto se rifiuti i commit che non sono collegati a un ID (il che è una buona cosa, ma grandi compiti come questi saranno ancora più attraenti per gli sviluppatori pigri).

I Typos dovrebbero essere aggiunti come commit. La correzione di parole errate o errori grammaticali aumenterà la leggibilità del tuo codice.

L'uso di un messaggio di commit come "Typo fisso" o "Typo fisso in file.c" ti aiuterà a distinguere questi commit da altri commit di codice importanti.

Sì, dovresti assolutamente farlo, in particolare all'inizio di un progetto.

Perché? Due punti:

1. Probabilmente non saprai se un refuso è "critico" o no fino a quando non è troppo tardi. Alcune correzioni probabilmente non vengono riparate perché tutti pensano che non sarà un grosso problema. Fino a quando non lo è.

2. Riparare un refuso all'inizio e deliberatamente sarà molto più facile che risolverlo dopo che sono state fatte diverse centinaia di righe di chiamate di codice / funzione. Ancora una volta, gli hack temporanei possono diventare semipermanenti sorprendentemente rapidamente. Questo è il motivo per cui ho a che fare con oggetti che hanno entrambi i metodi "CollapseAll" E "ColapseAll".

Per gli errori grammaticali che possono essere visualizzati da un utente finale, quindi sì, vale sicuramente la pena di eseguire il commit in quanto è del tutto possibile che un utente o un QA possa presentarsi e segnalare l'errore e che debba essere monitorato. Se è già stato risolto, potrebbe accelerare il tempo necessario per risolvere il problema.

Se si tratta di un errore grammaticale nei commenti intorno al codice, tuttavia, non farei nulla al riguardo a meno che non faccia parte delle modifiche al codice effettivo e nel qual caso stai aggiornando la documentazione del codice.

Se sei preoccupato di gommare il registro di commit, stai facendo qualcos'altro di sbagliato. :-) Gli impegni frequenti sono una buona cosa! Commetto sempre correzioni di errore di battitura. Inseriscili nel codebase al più presto e velocizza il ciclo di sviluppo!

Io voto sì. Controllali. Ho lavorato per un'azienda che odiava le persone che effettuavano il check-in. Intendo quasi tutto. Le revisioni del codice erano estese e quindi se hai verificato una modifica che ha appena risolto un errore di battitura, ti sei lamentato. Puoi immaginare lo stato del codice. In realtà il codice non era terribile, ma trasudava come melassa piuttosto che scorreva come il vino.

Il tuo processo di gestione delle modifiche lo consente?

Nel mio ambiente, ogni commit che eseguo deve essere ricollegato a una richiesta di modifica che è stata richiesta dagli utenti aziendali o a una modifica obbligatoria a livello di sistema, completa dei corrispondenti processi di test dell'utente finale. Un errore di battitura come quello che stai descrivendo probabilmente non verrebbe registrato come uno di questi (ho trovato errori di battitura ed errori grammaticali in una delle mie app che esistevano da oltre 4 anni senza che nessuno se ne accorgesse), quindi se / quando arrivavano gli auditor chiamare avrei avuto un momento molto difficile spiegarmi.

Vorrei salvare un cambiamento come lo stai descrivendo (e in realtà ne ho uno, in realtà - un nome di metodo è scritto in modo errato e l'ho appena scoperto) per un momento in cui ho un cambiamento "reale" che deve essere fatto anche e messo "riparati vari errori di battitura" nel registro.

Usa DVCS per modificare la cronologia

Se sei preoccupato per una cronologia di commit pulita, considera di fare il tuo lavoro principale nei rami delle caratteristiche . Se ti capita di lavorare con un VCS distribuito , puoi facilmente modificare la cronologia di commit prima di inviarla al ramo principale. Se sei su SVN, prova Git: può interagire in modo bidirezionale con Subversion e puoi anche modificare la cronologia prima di impegnarti effettivamente in Subversion.

In caso contrario, mantenere il buon senso

Se non si desidera o non è possibile modificare la cronologia del commit, non esiste alcun motivo funzionale per eseguire un commit anticipato o atomico per un errore di battitura minore che non influisce sui test automatici o sulla compilazione . In questi casi, a mio avviso, mantenere pulita la cronologia dei commit dovrebbe essere più importante che eseguire commit davvero atomici. Mischiare una o due correzioni di errori di battitura con una modifica "regolare" non danneggerà alcun potenziale processo di revisione. Tuttavia, potresti voler raggruppare diverse banali correzioni in un commit, magari quando "ripulisci" dopo una sessione di codifica più ampia.

Si noti che i bug funzionali devono comunque essere impegnati al più presto in un commit atomico.

Il tono generale delle risposte qui sembra suggerire una strategia di "impegnare tutto velocemente" anche per errori di battitura minori. Tendo a non essere d'accordo e accogliere con favore la discussione.