come scoprire se gli errori di ortografia nel codice sorgente sono un problema serio o no? [chiuso]

Gli errori di ortografia possono significare due cose:

• La persona che li crea non ha una buona conoscenza della lingua inglese e non ha il tempo di compensare utilizzando strumenti appropriati (dizionari, correttori ortografici, ecc.)
• La persona che li fa è competente in inglese, ma non si preoccupa affatto dell'ortografia.

O è un segno abbastanza brutto, perché significa che la persona in questione non ha leggibilità, manutenibilità ed eleganza in cima alla lista delle priorità; se la causa è una mancanza di padronanza della lingua inglese, significa anche che alla persona mancano due abilità essenziali: una comunicazione scritta in inglese e un sentimento generale per le lingue (se non riesci ad esprimere chiaramente i tuoi pensieri in inglese, è probabile che tu possa farlo). li esprimo bene anche in un linguaggio di programmazione).

Ma perché esattamente gli errori di ortografia sono sbagliati, a parità di tutti gli altri? Dopotutto, il codice funziona e il compilatore non si preoccupa affatto del nome degli identificatori, purché non violino le regole di sintassi. Il motivo è che scriviamo il codice non solo per i computer, ma anche e soprattutto per gli umani. Se così non fosse, staremmo ancora usando l'assemblaggio. Il codice sorgente viene scritto una volta, ma letto centinaia di volte durante il suo ciclo di vita. Errori di ortografia rendono più difficile la lettura e la comprensione del codice sorgente - errori lievi inducono il lettore a inciampare per una frazione di secondo, molti di questi possono causare ritardi considerevoli; errori veramente brutti possono rendere il codice sorgente completamente illeggibile. C'è un altro problema, ovvero che la maggior parte del codice che scrivi verrà riferita da un altro codice e che il codice più spesso è scritto da qualcun altro. Se incaselli i tuoi identificatori, qualcun altro dovrà ricordare (o cercare) non solo il nome, ma anche il modo esatto in cui viene scritto erroneamente. Questo richiede tempo e interrompe il flusso di programmazione; e poiché la maggior parte del codice viene toccata più volte durante la manutenzione, ogni errore di ortografia causa un sacco di interruzioni.

Considera come il tempo di sviluppo sia uguale alle spese di stipendio, penso che dovrebbe essere abbastanza facile da spiegare un caso; dopo tutto, interrompere il flusso e rientrare in esso può richiedere fino a 15 minuti. In questo modo, un grave errore di ortografia può facilmente costare qualche centinaio di dollari in ulteriore sviluppo e manutenzione (ma sono costi indiretti, non direttamente visibili nelle stime e nelle valutazioni, quindi spesso vengono ignorati dal management).

La prima volta che sprechi tempo a cercare la variabile Timeout solo per scoprire che è stata scritta come Timeount , conoscerai un altro motivo per cui l'ortografia è importante.

In realtà dubito che "Timeount" sia una questione di non essere un madrelingua. Le persone fanno un sacco di errori nella loro prima lingua. Non classificherei questi particolari esempi come "Engrish".

Detto questo, capisco che non si tratta di questi particolari esempi. Sono d'accordo con te in linea di principio. Mi sono imbattuto in problemi reali causati da questo tipo di cose ("se non ci sono colonne denominate allegati, crea allegati").

Essere programmatori significa essere precisi e attenti con errori di battitura, virgole, punti e virgola, punti che sono per lo più indipendenti dalla lingua umana il più delle volte.

Se questo problema ti infastidisce, la maggior parte degli IDE ora permettono il controllo ortografico nei commenti in modo che i dislessici possano almeno sembrare come sanno come si scrive. Mi aiuta sicuramente! È quindi una "correzione" banale per avere una buona ortografia.

Gli errori di ortografia nei nomi e nei metodi delle classi pubbliche sono semplicemente poco professionali. Costano tempo e denaro. Sono dolorose in linguaggi tipizzati staticamente come Java, dove l'IDE può produrre un menu di nomi di classi e metodi. Sono intollerabili nelle lingue digitate dinamicamente.

Ancora peggio sono gli errori di ortografia nei nomi delle tabelle del database e dei nomi delle colonne.

Nella mia esperienza, l'ortografia corretta è solo leggermente correlata alla padronanza della lingua inglese del programmatore. Ho visto madrelingua inglese produrre codice con spelling e interruzioni di parole essenzialmente casuali, e ho visto persone di madrelingua inglese che prestano attenzione a produrre ortografie corrette. Ma l'ortografia corretta è strettamente correlata alla qualità generale del codice. I programmatori in grado, a prescindere dalla loro conoscenza della lingua inglese, si preoccupano della qualità del loro lavoro e sono attenti ai nomi.

Nel codice sorgente, nelle presentazioni interne e nei documenti ecc. piccoli errori di battitura che non alterano il significato o ostacolano la comprensione non sono un problema. Basta correggerli nella fonte da soli se li trovi irritanti.

Inoltre, in particolare nei commenti, la sostanza è più importante della forma. No Engrish qui:

String s = "Wikipedia"; /* Assigns the value "Wikipedia" to the variable s. */

Il fatto è che alcune persone sono naturalmente scrittori più attenti di altri (se questo è dovuto all'educazione, oa causa dell'atteggiamento, oa causa dell'intelligenza o di qualsiasi altra cosa, non è rilevante). Quanto spendere gli sforzi per risolvere questa è una questione di valore aziendale: ottieni più valore dal correggere gli errori di battitura, piuttosto che spendere sforzi per risolverli? In caso di roba interna, la risposta è di solito no. I tuoi clienti non si lamenteranno di errori di digitazione nei tuoi commenti al codice sorgente (a meno che tu non stia facendo open source).

Errori intenzionali intenzionali e commenti inappropriati non sono professionali e dovrebbero essere evitati, ma l'attenzione dovrebbe essere concentrata sulle cose che contano (cioè generare valore aziendale, se lavori per affari).

Le cose pubblicamente visibili devono ovviamente essere attentamente rilette.

Il problema qui non è l'enigma in sé ma la mancanza di chiarezza dei commenti. L'inglese perfetto non è necessario, l'inglese è chiaro. È banale eseguire qualcosa tramite Google per raccogliere gli errori evidenti.

Ad esempio non è chiaro a prima vista se Gor message from queue significa "ha ricevuto un messaggio dalla coda" o "messaggio GOR dalla coda". Dovresti leggere il codice per capire il significato del commento (quindi sconfiggere l'oggetto del commento).

Dovresti chiedere di implementare le revisioni del codice nella tua azienda. Puoi quindi "criticare" le persone in modo costruttivo mentre fanno lo stesso con te.

Dovrebbe essere ovvio che il compilatore non si cura degli errori di ortografia, a patto che tu stia utilizzando la stessa ortografia, ad es. quando si fa riferimento a una variabile. La domanda diventa quindi se gli errori ortografici hanno un impatto negativo sulla capacità dei membri del team di mantenere il codice.

L'unico modo che posso vedere è quello di parlare con le persone che eseguono la manutenzione, e si potrebbe iniziare chiedendo se qualcuno ha avuto un tempo più difficile seguendo il codice che conteneva errori di ortografia.

Non penso che ci sia un modo per rimuovere completamente la soggettività da questo problema, ma per ridurlo, si potrebbe (manualmente o tramite uno script) scansionare l'origine per ottenere un numero stimato di errori di ortografia per un particolare modulo di codice, e vedere se la manutenzione dei moduli con un numero maggiore di errori di ortografia richiede in media più tempo rispetto a quelli con meno errori di ortografia.

Naturalmente non tutti i moduli sono uguali, quindi potresti pensare a ponderare i risultati con varie metriche come la complessità ciclomatica del modulo.

Nella mia esperienza errori di ortografia di base sono preoccupanti e possono essere sintomatici di problemi più profondi. Ogni progetto su cui ho lavorato con errori "banali" ha avuto problemi reali nel design che in qualche modo sono riusciti a passare attraverso il processo di revisione solo durante lo sviluppo, che è non quando si vuole scoprire che la funzionalità critica di cui hai veramente bisogno non ci sia.

Vorrei ricontrollare le specifiche del sistema (se esistono) ed esaminare la progettazione generale; Non sarei sorpreso se tu trovassi dei buchi.

In realtà si tratta di due problemi separati ma correlati. Dipende da dove sono gli errori ortografici:

1) Nel codice sorgente. Se hai un identificatore come ArgumnetCount , ciò può creare problemi reali quando qualcuno arriva e usa l'ortografia corretta . Quindi dovresti correggere quegli errori ogni volta che è possibile. Se hai bisogno di mantenere la compatibilità API indietro, puoi fare qualcosa di simile a:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) In testo leggibile dall'uomo (e-mail, documentazione, commenti al codice). Scrivere quelli giusti è importante, ma direi che è una priorità più bassa, dal momento che il software di parsing nella tua testa è molto più indulgente. Se vedi un testo con alcuni errori, è ancora leggibile, quindi non preoccuparti: non è un tuo problema. Ma se qualcuno ti manda delle sciocchezze associative libere e ti aspetti di usare quella sciocchezza come modello per un'applicazione web multiutente, allora dovresti inviare all'autore una nota educata che richiede chiarimenti (qualcosa del tipo: "Tu illetterato deficiente, come fare ti aspetti che capisca questa merda? ")

L'ortografia corretta è un must nel codice. Ho anche una grande base di codice piena di parole senza senso ed è un incubo da mantenere.

Non lasciare che questo sfugga di mano. Cerca di educare tutti che i manutentori del codice non sono lettori della mente.

Bene, questo è un problema culturale a molti lati.

Parlando da una prospettiva tedesca: notiamo come la nostra lingua sia sempre più influenzata dai termini inglesi. Questo si spinge fino alle società nazionali che hanno slogan o pubblicità in inglese. Alcune persone, specialmente nelle posizioni manageriali, nel frattempo apparentemente non sono in grado di pronunciare una frase in un semplice tedesco. Il loro discorso è pieno di parole d'ordine e gergo gestionale incomprensibile. Diciamo che queste persone stanno parlando "denglish".

Dato questo stato di cose e l'inglese è la "lingua franca", specialmente nel settore del software, è inevitabile che l'inglese stesso sia influenzato dal vasto numero di non madrelingua. Ma per i madrelingua inglesi è ancora meglio che dover dire, per esempio, i cinesi per prendere parte all'industria SW.

Colore o colore? Quale versione di inglese tu pensi sia quella giusta? Una mans corretta ortografia è un'altra scusa per iniziare una guerra vincibile.

Se vuoi iniziare una guerra, scegli attentamente le tue battaglie e vinci. Nel tuo caso, non ti preoccupare dei commenti, preoccupati meno di internals e concentrati (quasi) esclusivamente sulle API

Ho una massima: il codice Tidy non significa necessariamente una mente ordinata, ma il dritto è certamente vero: codice disordinato, mente disordinata.

Un programmatore che non impiega il tempo necessario per denominare le variabili correttamente e scrivere correttamente i commenti non ha quasi certamente il tempo di fare qualsiasi altra cosa correttamente. Se il programmatore è un madrelingua inglese non è un problema reale, poiché i problemi con il suo inglese possono (e dovrebbero) essere affrontati durante la peer review.

Sì, è un problema serio per il prodotto, per il team e per i singoli.

• Per il prodotto: la correzione può introdurre difetti che vengono catturati solo dai clienti
• Per il team: il team passa il tempo a sistemare la codifica in modo errato anziché creare valore
• Per gli individui: la cattiva ortografia ti fa sembrare stupido e riduce la tua posizione professionale tra i tuoi coetanei.