Dovevo correggere errori di ortografia e grammatica nel codice e non apportare modifiche alla funzionalità effettiva del codice?

Procedi con attenzione qui.

Spesso, qualsiasi modifica al codice ha effetti a valle. Potrebbe essere necessaria una revisione del codice. Potrebbe essere necessario eseguire dei test. Potrebbe essere necessaria una revisione della sicurezza. Ecc. Cambiare errori di ortografia e grammatica potrebbe innescare molto lavoro non programmato da parte di altri.

E mentre il tuo intento è quello di non apportare modifiche alla funzionalità effettiva, si verificano dei bug.

Prima di modificare qualsiasi codice, chiedi.

Lo farebbe è considerata una cattiva etichetta o meschina se:

• Ho modificato questi documenti per correggere la grammatica e l'ortografia, specialmente sui documenti che non sono rivolti al pubblico?
• l'autore originale è dislessico?

Dipende principalmente dalla cultura della tua organizzazione.

In alcune aziende, il cambiamento continuo da parte di tutti coloro che leggono tali documenti è benvenuto. In altre società, sarebbe considerato scortese senza il permesso dell'autore.

Considero questo tipo di cambiamento un miglioramento della qualità. La documentazione interna ha un valore anche se non è rivolta all'utente finale e migliorarne la qualità la rende più preziosa. Personalmente tendo anche a fidarmi maggiormente della documentazione se non contiene un'enorme quantità di errori di battitura. A volte un errore di battitura o una grammatica sbagliata potrebbe anche cambiare il significato o portare a malintesi.

Riassumendo: lo trovo piuttosto positivo.

Fai attenzione però che se ti capita di spendere un molte volte le persone potrebbero chiedersi se non hai niente di meglio da fare, come programmare ...

Presumi il peggiore dei tuoi cambiamenti:

• Commetti errori che rompono qualcosa
• I tuoi impegni relativamente minori potrebbero ingombrare i log delle modifiche, ecc
• Il tuo datore di lavoro potrebbe pensare che il tuo tempo venga speso per fare cose più utili

Per questo motivo, apporto modifiche "non richieste" solo se, fondamentalmente, stavo cambiando comunque il codice / documento. Quindi, se mi viene assegnato il compito di cambiare una classe e so che la sua funzionalità dovrà essere comunque testata di nuovo, potrei anche rifattorizzarla e correggere un po 'di ortografia se credo sinceramente che migliorerà la qualità o farà risparmiare tempo a tutti alla fine. Come accennato in un'altra risposta: la "regola dei boy scout": lascia il campeggio più ordinato di quando sei arrivato.

Ma non accendere accidentalmente incendi boschivi accampandosi inutilmente :) Per qualsiasi altro cambiamenti, fatene un caso a chi sta decidendo cosa fare. Spiegare i vantaggi delle correzioni e gli eventuali rischi. Esempi di vantaggi potrebbero essere il fatto che il codice con errori di ortografia inibisce la ricerca nella base di codice, la percezione negativa dell'utente da messaggi o documenti con errori di ortografia e così via. Lascia che sia loro a decidere se vale il tempo / il rischio.

Se stiamo parlando di modifiche davvero minori come la correzione di errori di battitura o virgole mancanti, ecc., allora non direi che è una brutta cosa correggerle semplicemente come le trovi. Quello che non farei è andare in giro a dire a chiunque che hai apportato le modifiche poiché potrebbe sembrare una ricerca di attenzione nella migliore delle ipotesi e nel peggiore dei casi essere un meschino ortografia / grammatica nazista.

Un altro vantaggio da correggere -come-hai-scoperto-è che non vuoi sembrare qualcuno che dà la caccia a questi errori.

Il codice può essere leggermente diverso, sebbene tu dichiari che non stai modificando il codice effettivo , quindi presumo che siano solo cose come i commenti, quindi non c'è alcuna possibilità che abbia un impatto sulla funzionalità, nel qual caso suggerirei che va bene.

Dovevo correggere errori di ortografia e grammatica nel codice e non apportare modifiche alla funzionalità effettiva del codice?

Ci sono errori visibili al pubblico (nel front-end) o il client (nel registro della console del cliente)? ​​

Se sì, chiedi al team / responsabile del progetto di autorizzarti a correggerli.

niente o chiedi al team / project leader se puoi fare qualche refactoring e risolvere poi qualsiasi altro problema che il codice potrebbe avere.

In ogni caso, non criticare il tuo collega, specialmente se è dislessico.

Non modificare il codice a meno che non sia collegato direttamente al bug o al ticket di miglioramento su cui stai lavorando. (hai un sistema di biglietteria di qualche tipo per lavorare su sistemi esistenti, giusto?) La tua modifica dovrebbe essere necessaria anche per completare il lavoro del biglietto.

Se credi fermamente che questo codice debba essere cambiato , crea un ticket per la revisione e, se approvato, puoi fare il lavoro.

Come si suol dire, "Nessuna buona azione rimane impunita". Ci sono così tanti modi in cui quella che sembra una modifica banale potrebbe andare storta, a volte in modo ritardato.

Ad esempio, nella mia azienda abbiamo creato un sistema di avviso basato sul monitoraggio / scraping dei file di registro. I messaggi di errore nei registri possono generare qualsiasi cosa, da un avviso minore a un avviso per tutte le mani. Nel corso degli anni, abbiamo purtroppo creato messaggi di errore di registro con tutte le variazioni di errori di battitura. Se uno sviluppatore troppo zelante "risolveva" i messaggi di errore, il nostro sistema di avviso potrebbe improvvisamente diventare silenzioso.

Ciò a cui tutto si riduce è il contesto.

Ad esempio, lavoro per un'azienda multinazionale in un team che si trova in più paesi. Sono l'unico madrelingua inglese, quindi ogni giorno incontro errori di grammatica e ortografia nei nostri nomi in codice e nei commenti.

Di solito li lascio così come sono, poiché correggere gli errori non porta alcun beneficio ed è sempre molto facile capire l'intenzione di chi scrive a causa del contesto. (In cima alla mia testa, riesco a pensare a una cartella a cui accedono diversi file con il nome "risorse".

La modifica dei nomi può avere effetti a cascata se si tratta di un oggetto codice effettivo e se il nome è descrittivo anche se con errori di ortografia, non vedo il vantaggio di aggiungere al tuo carico di lavoro.

Non credo che i miei colleghi stranieri si offenderebbero se iniziassi a correggere i loro errori nei miei commit, ma nel tempo, se dovessi farlo ancora e ancora, potrebbero iniziare a pensare che le loro abilità in inglese siano inadeguate.

In conclusione, chiediti se il contesto della situazione vale il lavoro extra e se il contesto significa un potenziale lieve contro l'autore originale.

Non credo che la correzione di errori di ortografia e grammatica nel codice altrui darà a qualcuno l'impressione che tu sia un programmatore migliore per questo di avere una migliore conoscenza della lingua inglese.

I documenti rivolti al pubblico e le voci di log dovrebbero avere standard molto più elevati in termini di correttezza ortografica e grammaticale rispetto ai documenti e al codice interni. Naturalmente, è anche consigliabile pulire costantemente il codice su cui stai lavorando. Ciò significa che ogni volta che si lavora su una funzione / correzione di un bug, è necessario lasciare la parte interessata più pulita di prima (regola di boyscout). Quello che non dovrebbe essere il caso è che quando modifichi il codice, le modifiche contengono solo correzioni grammaticali e ortografiche.

Inoltre, dovresti chiedere al tuo manager prima di fare questa abitudine regolarmente, perché lui / lei può aiutarti nell'affrontare i tuoi colleghi che potrebbero essere sensibili alla correzione dei loro contributi.

Ci sono due categorie di cui hai a che fare qui: documenti destinati al pubblico e documenti interni e codice.

Per documenti interni e codice, non preoccuparti di modifiche superflue. Finché i file sono comprensibili e funzionano come dovrebbero, non c'è davvero nulla da guadagnare. Modifiche come questa in realtà non aggiungono nulla e possono ingombrare la cronologia del controllo della versione. Tuttavia, se stai già apportando una modifica a un particolare documento e vedi anche alcuni errori di battitura da correggere, vai avanti. In tal caso è davvero più un componente aggiuntivo di una modifica già necessaria.

Per i documenti destinati al pubblico e i messaggi dell'interfaccia utente, è importante assicurarsi che ci siano pochi errori e che tutto sia grammaticalmente corretto. Se è qualcosa che è chiaramente errato, lo cambierei sicuramente. Se si tratta di una modifica più soggettiva (ad es. Modifica del testo o virgola di Oxford), mi consulterei con l'autore principale o il tuo manager prima di salvare qualsiasi modifica. Ancora una volta, trovo che molte piccole modifiche come questa possono ingombrare il controllo della versione, quindi personalmente preferisco salvare le modifiche con altri aggiornamenti più importanti o mettere da parte le modifiche e fare un caricamento in gruppo di un gruppo di modifiche di copia contemporaneamente . È qualcosa di cui puoi parlare con il tuo manager per vedere cosa preferisce.

Lavoro in una piccola società di sviluppo che ha un'atmosfera aperta e amichevole e sono il dipendente più giovane.

Hai un manager. Questa è la persona che dovresti chiedere!

Le nostre opinioni possono essere considerate come un consiglio, ma il tuo capo è la persona che deve prendere una decisione. Devono decidere come utilizzare al meglio il tuo tempo .

Mi imbatto in semplici errori di ortografia, refusi e grammatica errata.

Se sei autorizzato a modificare questi documenti e certo non stai cambiando il significato previsto , allora presumo che sia OK. Tuttavia, essere certi del significato inteso non è banale ed è facile alterare il significato senza volerlo.

In altri casi, nel codice mi imbatto in molti errori di battitura nelle istruzioni di debug, console output e messaggi che vengono presentati all'utente.

Gli errori nel codice (messaggi di qualsiasi tipo inclusi) devono essere adeguatamente risolti utilizzando un sistema di tracciamento dei bug. Possono quindi essere assegnate correttamente le priorità e gestite su quella base.

Ed è possibile rovinare queste modifiche e rovinare il codice facendolo. Succede tutto il tempo.

Sarebbe considerato una cattiva etichetta, o meschino se:

Ho modificato questi documenti per correggere la grammatica e l'ortografia, specialmente sui documenti che non sono " t rivolto al pubblico?

I documenti interni privati ​​non hanno bisogno di essere riparati in questo modo. Dai la priorità ad altri lavori rispetto a questo.

L'autore originale è dislessico?

Le capacità o i limiti dell'autore originale non sono rilevanti per come viene utilizzato il tuo tempo.

Dovevo correggere errori di ortografia e grammatica nel codice e non apportare modifiche alla funzionalità effettiva del codice?

Qualsiasi modifica al codice è una modifica formale. Le modifiche ai commenti e ad altri elementi possono introdurre bug: le persone commettono errori nel farlo. Lo sconsiglio senza istruzioni esplicite dalla tua direzione.

Se il documento non è rivolto al pubblico, come hai menzionato per alcuni di loro, qual è il vantaggio effettivo nell'apportare queste correzioni, a parte il fatto che non ti infastidisce?

Se stai non modificare la funzionalità del codice e la presentazione grammaticale migliorata non ha alcun impatto sull'immagine dell'azienda, quindi non hai aggiunto alcun valore al codice.

Se passi del tempo a "aggiustare" qualcosa che aggiunge nessun valore, hai solo sprecato il tuo tempo e il tempo e i soldi del tuo datore di lavoro, il che non è la strada da percorrere per nessuno, ma soprattutto per la persona più giovane nella catena alimentare.

irritare le persone, chi chiederà "perché è stato necessario aggiustarlo?", e probabilmente solleverai la domanda generale: "questa persona non ha un lavoro che aggiunge valore da fare? In caso contrario, il lavoro di questa persona è necessario per noi avere, affatto? "

Non chiedere nemmeno se va bene fare queste correzioni, perché non ci sono problemi da risolvere e nessun miglioramento offerto dalla correzione.

Per i messaggi che lo fanno essere presentato agli utenti finali / clienti, identificarli definitivamente per il fissaggio, far sapere a qualcuno più in alto che l'hai visto e offrirti di correggerlo. Certamente, errori di base di questo tipo non si riflettono bene sull'azienda, quindi correggerli aggiunge un valore sostanziale.