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

Trovo una quantità molto preoccupante di errori di ortografia che vedo ogni giorno nella nostra base di codice, da cui riprodurrò un esempio molto breve ma rappresentativo:

ArgumnetCount
Timeount
Gor message from queue 

Purtroppo questo non è in alcun modo limitato a una persona. Ci sono molti madrelingua inglese nel nostro team che contribuiscono a questo, tuttavia posso anche individuare alcuni dei peggiori errori di ortografia per il nostro architetto del software che è americano, nato e cresciuto.

Questi si trovano anche in e-mail, presentazioni, documenti, qualsiasi informazione scritta che abbiamo in una società di sviluppo software.

Vorrei sapere come scoprire se si tratta di un problema serio o no?

_{Ho sempre incontrato questi errori di ortografia con preoccupazione, ma la mia politica personale, personale e ufficiale è che non siamo pagati per scrivere le cose nel modo giusto, siamo pagati per fare le cose, quindi all'interno dell'azienda non ho mai criticato nessuno a riguardo. Ma ho sollevato questo problema con alcuni dei miei amici più cari e non l'ho mai risolto per sempre.}

Gli errori di ortografia possono significare una delle due cose:

• La persona che li produce non ha una buona conoscenza dell'inglese e non impiega il tempo per compensare utilizzando strumenti adeguati (dizionari, correttori ortografici, ecc.)
• La persona che li produce è competente in inglese, ma non si preoccupa affatto dell'ortografia.

O è un segno abbastanza negativo, perché significa che la persona in questione non ha la leggibilità, la manutenibilità e l'eleganza in cima alla lista delle priorità; se la causa è la mancanza di conoscenza della lingua inglese, significa anche che alla persona mancano due abilità essenziali: la 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 " esprimerli bene anche in un linguaggio di programmazione).

Ma perché esattamente gli errori di ortografia sono cattivi, tutto il resto è uguale? Dopotutto, il codice funziona e al compilatore non importa affatto come si nominano gli identificatori, purché non violino le regole di sintassi. Il motivo è che scriviamo codice non solo per i computer, ma anche e soprattutto per gli umani. Se così non fosse, useremmo comunque il montaggio. Il codice sorgente viene scritto una volta, ma letto centinaia di volte durante il suo ciclo di vita. Gli errori di ortografia rendono più difficile la lettura e la comprensione del codice sorgente - errori lievi fanno inciampare il lettore per una frazione di secondo, molti di essi possono causare notevoli ritardi; errori davvero negativi possono rendere illeggibile il codice sorgente. C'è un altro problema, ovvero che la maggior parte del codice che scrivi sarà indicato da un altro codice e che il codice più spesso viene scritto da qualcun altro. Se si sbaglia l'ortografia degli identificativi, qualcun altro dovrà ricordare (o cercare) non solo quale sia il nome, ma anche come sia stato scritto in modo errato. Ciò richiede tempo e interrompe il flusso di programmazione; e poiché la maggior parte del codice viene toccata più di una volta durante la manutenzione, ogni errore di ortografia provoca molte interruzioni.

Considera come il tempo dello sviluppatore è uguale allo stipendio uguale alle spese, penso che dovrebbe essere abbastanza facile fare un caso di questo; 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 dalla direzione).

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

Detto questo, capisco che non si tratta di questi esempi particolari. 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 un programmatore significa essere precisi e attenti con errori di battitura, virgole, punti e virgola, punti, che è agnostico in linguaggio umano il più delle volte.

La prima volta che perdi tempo a cercare la Timeoutvariabile solo per scoprire che è stata scritta Timeount, saprai un'altra ragione per cui l'ortografia è importante.

Se questo problema ti disturba, la maggior parte degli IDE ora consente il controllo ortografico nei commenti in modo che i dislessici possano almeno sembrare che sappiano come si scrive. Mi aiuta sicuramente! È quindi una banale "correzione" 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 dolorosi in linguaggi tipicamente statici come Java, in cui l'IDE può produrre un menu di nomi di classi e metodi. Sono intollerabili nei linguaggi tipizzati dinamicamente.

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

Nella mia esperienza, l'ortografia corretta è solo leggermente correlata alla conoscenza della lingua inglese del programmatore. Ho visto madrelingua inglese produrre codice con ortografia e interruzioni di parola essenzialmente casuali e ho visto madrelingua inglese che sono attenti a produrre ortografia corretta. Ma l'ortografia corretta è fortemente correlata alla qualità complessiva del codice. Programmatori capaci, indipendentemente dalla loro conoscenza della lingua inglese, si preoccupano della qualità del loro lavoro e sono attenti alla denominazione.

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

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

String s = "Wikipedia"; / * Assegna il valore "Wikipedia" alla variabile s. * /

Il fatto è che alcune persone sono scrittori naturalmente più attenti di altri (sia che ciò sia dovuto all'educazione, sia a causa dell'atteggiamento o dell'intelligenza o altro, non è rilevante). Quanto spendere per risolvere questa è una domanda sul valore aziendale: ottieni più valore dalla correzione degli errori di battitura, rispetto allo sforzo di risolverli? In caso di cose interne, la risposta è generalmente no. I tuoi clienti non si lamenteranno di errori di battitura nei commenti del codice sorgente (a meno che non stia facendo open source).

La tipizzazione errata intenzionale e i commenti inappropriati non sono professionali e dovrebbero essere evitati, ma l'attenzione dovrebbe essere rivolta alle cose che contano (ovvero generare valore aziendale, se si lavora per affari).

Ovviamente le cose pubblicamente visibili devono essere attentamente lette.

Il problema qui non è l'invidia stessa ma la mancanza di chiarezza nei commenti. L'inglese perfetto non è necessario, l'inglese chiaro lo è. È banale eseguire qualcosa tramite Google per rilevare gli errori evidenti.

Ad esempio, non è chiaro a prima vista se Gor message from queuesignifica "ricevuto un messaggio dalla coda" o "Messaggio GOR dalla coda". Dovresti leggere il codice per capire il significato del commento (sconfiggendo così l'oggetto del commento).

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

Dovrebbe essere ovvio che al compilatore non interessano gli errori di ortografia, purché si utilizzi lo stesso ortografia, ad esempio 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 in cui posso vedere che sarebbe parlare con le persone che fanno la manutenzione, e potresti iniziare chiedendo se qualcuno ha avuto un momento più difficile seguendo il codice che conteneva errori di ortografia.

Non penso che ci sia alcun modo per rimuovere completamente la soggettività da questo problema, ma per ridurlo, potresti (manualmente o tramite uno script) scansionare la fonte per ottenere un numero stimato di errori ortografici per un particolare modulo di codice e vedere se la manutenzione sui moduli con un numero maggiore di errori di ortografia è occorso in media più tempo rispetto ai moduli con meno errori di ortografia.

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

Nella mia esperienza, tali errori di ortografia di base sono preoccupanti e possono essere sintomatici di problemi più profondi. Ogni progetto ho lavorato con gli errori "banali" come che ha avuto problemi reali nella progettazione che in qualche modo hanno reso il processo di riesame solo per affiorano durante lo sviluppo, che è non quando si vuole scoprire che la funzionalità critica si ha realmente bisogno non c'è.

Ricontrolerei le specifiche del sistema (se esistono) ed esaminerei il progetto generale; Non sarei sorpreso se trovassi dei buchi.

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

1) Nel codice sorgente. Se hai un identificatore come ArgumnetCount, questo può creare problemi reali quando qualcuno arriva e usa l' ortografia corretta . Quindi dovresti correggere quegli errori quando possibile. Se devi preservare la compatibilità con le API all'indietro, puoi fare qualcosa del tipo:

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

2) In testo leggibile dall'uomo (e-mail, documentazione, commenti in codice). Scrivere questi correttamente è importante, ma direi che è una priorità più bassa, poiché il software di analisi nella tua testa è molto più tollerante. Se vedi un testo con alcuni errori, è ancora leggibile, quindi non preoccuparti, non è un tuo problema. Ma se qualcuno ti invia delle sciocchezze associative gratuite e si aspetta che tu usi quelle sciocchezze come modello per un'applicazione web multiutente, allora dovresti inviare all'autore una nota educata chiedendo chiarimenti (qualcosa come: "Idiota analfabeta, come si fa ti aspetti che capisca questa merda? ")

L'ortografia corretta dell'ortografia è un must nel codice. Ho anche una grande base di codice piena di cose incomprensibili ed è un incubo da mantenere.

Non lasciarti sfuggire di mano. Cerca di educare tutti che i manutentori del codice non sono dei lettori di mente.

Bene, questo è un problema culturale a molte facce.

Parlando da una prospettiva tedesca: notiamo come la nostra lingua viene sempre più influenzata dai termini inglesi. Questo vale fino a quando le compagnie nazionali hanno slogan inglesi o pubblicità. Alcune persone, specialmente nelle posizioni dirigenziali, sono apparentemente incapaci di pronunciare una sola frase in tedesco. Il loro discorso è pieno di parole d'ordine e incomprensibile gergo di gestione. Diciamo che tali persone parlano "denglish".

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

È colore o colore? Quale versione inglese ritieni sia quella corretta? L'ortografia corretta di un uomo è un'altra scusa per iniziare una guerra vincibile.

Se vuoi iniziare una guerra, scegli attentamente le tue battaglie e vincile. Nel tuo caso, non preoccuparti dei commenti, preoccupati meno degli interni e concentrati (quasi) esclusivamente sulle API

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

Un programmatore che non si prende il tempo di nominare correttamente le variabili e di scrivere correttamente i commenti non sta quasi sicuramente impiegando il tempo per fare qualcos'altro correttamente. Il fatto che il programmatore sia un madrelingua inglese non è un vero problema, poiché i problemi con il suo inglese possono (e dovrebbero) essere affrontati durante la revisione tra pari.

Sì, è un problema serio per il prodotto, per il team e per le persone.

• Per il prodotto: la correzione può introdurre difetti rilevati solo dai clienti
• Per il team: il team trascorre il tempo a correggere la codifica sciatta anziché creare valore
• Per gli individui: l'ortografia sbagliata ti fa sembrare stupido e abbassa la tua reputazione professionale tra i tuoi pari.