¿Cómo saber si los errores ortográficos en el código fuente son un problema grave o no? [cerrado]

Encuentro una cantidad muy preocupante de errores ortográficos que veo todos los días en nuestra base de código, de la cual reproduciré un ejemplo muy breve pero representativo:

ArgumnetCount
Timeount
Gor message from queue 

Lamentablemente, esto no se limita a una sola persona. Hay muchos angloparlantes no nativos en nuestro equipo que contribuyen a eso, sin embargo, también puedo señalar algunos de los peores errores ortográficos para nuestro Arquitecto de software que es estadounidense, nacido y criado.

Estos también se encuentran incluso en correos electrónicos, presentaciones, documentos, cualquier información escrita que tengamos en una empresa de desarrollo de software.

Me gustaría saber cómo averiguar si es un problema grave o no.

_{Siempre me he enfrentado a estos errores ortográficos con preocupación, pero mi política personal, personal y oficial es que no se nos paga para deletrear las cosas bien, se nos paga para que se hagan las cosas, así que dentro de la empresa nunca critiqué a nadie al respecto. Pero he planteado este problema con algunos de mis amigos cercanos, y nunca lo resolví definitivamente.}

Los errores de ortografía pueden significar una de dos cosas:

• La persona que los hace no es competente en inglés y no se toma el tiempo para compensar mediante el uso de herramientas adecuadas (diccionarios, correctores ortográficos, etc.)
• La persona que los hace es competente en inglés, pero no le importa la ortografía.

Cualquiera de las dos es una mala señal, porque significa que la persona en cuestión no tiene legibilidad, facilidad de mantenimiento y elegancia en su lista de prioridades; Si la causa es la falta de dominio del idioma inglés, también significa que la persona carece de dos habilidades esenciales: comunicación escrita en inglés y un sentimiento general de idiomas (si no puede expresar sus pensamientos claramente en inglés, es probable que pueda ' t expresarlos bien en un lenguaje de programación tampoco).

Pero, ¿por qué exactamente los errores ortográficos son malos, todo lo demás es igual? Después de todo, el código funciona y al compilador no le importa en absoluto cómo nombra sus identificadores, siempre que no violen las reglas de sintaxis. La razón es que escribimos código no solo para computadoras, sino también y, sobre todo, para humanos. Si ese no fuera el caso, todavía estaríamos usando el ensamblaje. El código fuente se escribe una vez, pero se lee cientos de veces durante su ciclo de vida. Los errores de ortografía dificultan la lectura y la comprensión del código fuente: los errores leves hacen que el lector tropiece durante una fracción de segundo, muchos de ellos pueden causar retrasos considerables; errores realmente malos pueden hacer que el código fuente sea completamente ilegible. Hay otro problema, que es que la mayoría del código que escribes será mencionado por otro código, y ese código la mayoría de las veces es escrito por otra persona. Si escribe incorrectamente sus identificadores, alguien más tendrá que recordar (o buscar) no solo cuál es el nombre, sino también cómo está escrito incorrectamente. Esto lleva tiempo y rompe el flujo de programación; y como la mayoría del código se toca más de una vez en mantenimiento, cada error de ortografía causa muchas interrupciones.

Considere cómo el tiempo del desarrollador es igual al salario es igual a los gastos, creo que debería ser lo suficientemente fácil como para justificar esto; después de todo, romper el flujo y volver a entrar puede tomar hasta 15 minutos. De esta manera, un error grave de ortografía puede costar fácilmente unos pocos cientos de dólares en un mayor desarrollo y mantenimiento (pero son costos indirectos, no directamente visibles en las estimaciones y evaluaciones, por lo que a menudo son ignorados por la administración).

Realmente dudo si "Timeount" es una cuestión de no ser un hablante nativo. La gente hace toneladas de errores tipográficos en su primer idioma. No calificaría estos ejemplos particulares como "Engrish".

Dicho esto, entiendo que no se trata de estos ejemplos particulares. Estoy de acuerdo contigo en principio. Me he encontrado con problemas reales causados ​​por este tipo de cosas ("si no hay columnas con nombre de archivos adjuntos, crear archivos adjuntos").

Ser un programador se trata de ser preciso y cuidadoso con los errores tipográficos, comas, punto y coma, puntos, lo que es agnóstico al lenguaje humano la mayor parte del tiempo.

La primera vez que pierdas el tiempo buscando la Timeoutvariable solo para descubrir que se escribió Timeount, sabrás otra razón por la que la ortografía es importante.

Si este problema le molesta, la mayoría de los IDE ahora permiten la corrección ortográfica en los comentarios para que los disléxicos puedan al menos parecer que saben cómo deletrear. ¡Seguro que me ayuda! Por lo tanto, es una "solución" trivial tener una buena ortografía.

Los errores ortográficos en los nombres y métodos de clases públicas son simplemente poco profesionales. Cuestan tiempo y dinero. Son dolorosos en lenguajes estáticamente escritos como Java, donde el IDE puede producir un menú de nombres de clases y métodos. Son intolerables en lenguajes de tipo dinámico.

Peor aún son los errores ortográficos en los nombres de tablas de bases de datos y los nombres de columnas.

En mi experiencia, la ortografía correcta está solo ligeramente relacionada con el dominio del inglés del codificador. He visto a hablantes nativos de inglés producir código con ortografía esencialmente aleatoria y saltos de palabras, y he visto hablantes de inglés no nativos que tienen cuidado de producir la ortografía correcta. Pero la ortografía correcta está muy relacionada con la calidad general del código. Los programadores capaces, sin importar su dominio del inglés, se preocupan por la calidad de su trabajo y son cuidadosos con los nombres.

En el código fuente, presentaciones internas y documentos, etc., los pequeños errores tipográficos que no alteran el significado o dificultan la comprensión no son un problema. Simplemente fíjelos en la fuente usted mismo si los encuentra irritantes.

Además, particularmente en los comentarios, la sustancia es más importante que la forma. No Engrish aquí:

Cadena s = "Wikipedia"; / * Asigna el valor "Wikipedia" a la variable s. * /

El hecho es que algunas personas son naturalmente escritoras más cuidadosas que otras (ya sea debido a la educación, a la actitud, a la inteligencia o lo que sea, no es relevante). ¿Cuánto gastar esfuerzo para arreglar eso es una pregunta de valor comercial: obtienes más valor al arreglar los errores tipográficos, que gastas esfuerzo en arreglarlos? En caso de cosas internas, la respuesta suele ser no. Sus clientes no van a quejarse de los errores tipográficos en sus comentarios de código fuente (a menos que esté haciendo código abierto).

La escritura incorrecta intencional y los comentarios inapropiados no son profesionales y deben evitarse, pero el enfoque debe estar en las cosas que importan (es decir, generar valor comercial, si trabaja para negocios).

Por supuesto, las cosas públicamente visibles deben ser cuidadosamente revisadas.

El problema aquí no es el engrish en sí mismo, sino la falta de claridad en los comentarios. El inglés perfecto no es necesario, el inglés claro sí. Es trivial ejecutar algo a través de Google para detectar los errores obvios.

Por ejemplo, no está claro a primera vista si Gor message from queuesignifica "recibió un mensaje de la cola" o "Mensaje GOR de la cola". Tendría que leer el código para comprender el significado del comentario (lo que anula el objeto del comentario).

Debe solicitar implementar revisiones de código en su empresa. Luego puede "criticar" a las personas de manera constructiva mientras le hacen lo mismo.

Debería ser obvio que al compilador no le importan las faltas de ortografía, siempre y cuando esté utilizando la misma ortografía, por ejemplo, al hacer referencia a una variable. La pregunta entonces es si los errores ortográficos tienen un impacto negativo en la capacidad de los miembros del equipo para mantener el código.

La única forma en que puedo hacer eso es hablar con las personas que realizan el mantenimiento, y puede comenzar preguntando si alguien tuvo más dificultades para seguir el código que contenía errores ortográficos.

No creo que haya ninguna forma de eliminar la subjetividad de este problema por completo, pero para reducirlo, podría (manualmente o mediante un script) escanear la fuente para obtener un número estimado de errores ortográficos para un módulo de código en particular, y ver si el mantenimiento en los módulos con un mayor número de faltas de ortografía tomó más tiempo en promedio que aquellos módulos con menos faltas de ortografía.

No todos los módulos son iguales, por supuesto, por lo que podría pensar en ponderar sus resultados con varias métricas, como la complejidad ciclomática del módulo.

En mi experiencia, estos errores de ortografía básicos son preocupantes y pueden ser sintomáticos de problemas más profundos. Todos los proyectos en los que he trabajado con errores "triviales" como ese tenían problemas reales en el diseño que de alguna manera pasaron por el proceso de revisión solo para surgir durante el desarrollo, que no es cuando quieres descubrir que la funcionalidad crítica realmente necesitas no esta ahi

Verificaría dos veces las especificaciones del sistema (si existen) y examinaría el diseño general; No me sorprendería si encontraras algunos agujeros.

Esto es en realidad dos cuestiones separadas, pero relacionadas. Depende de dónde están los errores ortográficos:

1) En código fuente. Si tiene un identificador como ArgumnetCount, eso puede crear problemas reales cuando alguien viene y usa la ortografía correcta . Por lo tanto, debe corregir esos errores siempre que sea posible. Si necesita preservar la compatibilidad con API hacia atrás, puede hacer algo como:

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

2) En texto legible por humanos (correos electrónicos, documentación, comentarios de código). Escribirlos correctamente es importante, pero diría que es una prioridad más baja, ya que el software de análisis dentro de su cabeza es mucho más indulgente. Si ve un texto con algunos errores, aún puede leerse, entonces no se preocupe, no es su problema. Pero si alguien le envía un sinsentido asociativo libre y espera que use ese sinsentido como modelo para una aplicación web multiusuario, entonces debe enviar al autor una nota cortés solicitando una aclaración (algo como: "Usted analfabeta, imbécil, ¿cómo? esperas que entienda esta mierda? ")

El inglés correcto deletreado es imprescindible en el código. También tengo una gran base de código llena de galimatías y es una pesadilla de mantener.

No dejes que esto se salga de control. Trate de educar a todos que los encargados del mantenimiento del código no son lectores de la mente.

Bueno, este es un problema cultural de muchos lados.

Hablando desde una perspectiva alemana: notamos cómo nuestro propio idioma se ve cada vez más influenciado por los términos en inglés. Esto va tan lejos como las empresas nacionales que tienen lemas o publicidad en inglés. Mientras tanto, algunas personas, especialmente en puestos directivos, aparentemente no pueden pronunciar una sola frase en alemán. Su discurso está lleno de palabras de moda y jerga de gestión incomprensible. Decimos que esas personas están hablando "inglés".

Dado este estado de cosas y que el inglés es la "lengua franca", especialmente en los negocios de software, es inevitable que el gran número de hablantes no nativos influya en el inglés. Pero para los hablantes nativos de inglés, esto es aún mejor que tener que aprender, por ejemplo, chino para participar en la industria de SW.

¿Es color o color? ¿Cuál versión de inglés crees que es la correcta? La ortografía correcta de un hombre es la excusa de otro hombre para comenzar una guerra ganable.

Si quieres comenzar una guerra, elige tus batallas con cuidado y gánalas. En su caso, no se preocupe por los comentarios, preocúpese menos por lo interno y concéntrese (casi) exclusivamente en las API

Tengo una máxima: el código ordenado no significa necesariamente una mente ordenada, pero el anverso es ciertamente cierto: código desordenado, mente desordenada.

Un programador que no se toma el tiempo para nombrar las variables correctamente y deletrea los comentarios correctamente, es casi seguro que no se toma el tiempo para hacer nada más correctamente. Si el programador es un hablante nativo de inglés no es un problema real, ya que los problemas con su inglés pueden (y deben) abordarse durante la revisión por pares.

Sí, es un problema grave para el producto, para el equipo y para las personas.

• Para el producto: la corrección puede introducir defectos que solo son captados por los clientes
• Para el equipo: el equipo pasa tiempo arreglando códigos descuidados en lugar de crear valor
• Para las personas: la mala ortografía te hace ver estúpido y disminuye tu posición profesional entre tus compañeros.