¿cómo saber si los errores de ortografía en el código fuente son un problema grave o no? [cerrado]

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 de compensar con las herramientas apropiadas (diccionarios, correctores ortográficos, etc.)
• La persona que los hace es competente en inglés, pero no le importa la ortografía en absoluto.

O bien 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: la comunicación escrita en inglés y un sentimiento general por los idiomas (si no puede expresar sus pensamientos claramente en inglés, es probable que pueda hacerlo). No los expreses bien en un lenguaje de programación).

Pero, ¿por qué exactamente los errores de ortografía 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 nombre sus identificadores, siempre y cuando 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 ensamblador. 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 por una fracción de segundo, muchos de ellos pueden causar retrasos considerables; los errores realmente graves 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á referido por otro código, y ese código más a menudo es escrito por otra persona. Si escribe incorrectamente sus identificadores, alguien más tendrá que recordar (o buscar) no solo cuál es su nombre, sino también cómo está mal escrito. Esto lleva tiempo y rompe el flujo de programación; y dado que la mayoría del código se toca más de una vez en el mantenimiento, cada error ortográfico 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 explicar esto; después de todo, romper el flujo y volver a entrar puede demorar hasta 15 minutos. De esta manera, un grave error de ortografía puede costar fácilmente unos pocos cientos de dólares en un mayor desarrollo y mantenimiento (pero son costos indirectos, que no son directamente visibles en las estimaciones y evaluaciones, por lo que la administración a menudo los ignora).

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

Realmente dudo que "Timeount" sea 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".

Habiendo dicho eso, entiendo que no se trata de estos ejemplos en particular. Estoy de acuerdo contigo en principio. Me he encontrado con problemas reales causados por este tipo de cosas ("si no hay una columna llamada archivos adjuntos, cree archivos adjuntos").

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

Si este problema te molesta, la mayoría del IDE ahora permite 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 un "arreglo" trivial tener una buena ortografía.

Los errores de ortografía en los nombres y métodos de clases públicas son simplemente poco profesionales. Cuestan tiempo y dinero. Son dolorosos en lenguajes de tipo estático como Java, donde el IDE puede producir un menú de nombres de clases y métodos. Son intolerables en idiomas tipificados dinámicamente.

Peor aún son los errores de ortografía en los nombres de tablas y columnas de la base de datos.

En mi experiencia, la ortografía correcta está ligeramente relacionada con el dominio del inglés del codificador. He visto a los hablantes nativos de inglés producir código con ortografía y saltos de palabras esencialmente aleatorios, y he visto hablantes no nativos de inglés que tienen cuidado de producir la ortografía correcta. Pero la ortografía correcta está altamente 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 tienen cuidado con los nombres.

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

También, 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, escritores más cuidadosos que otros (ya sea que se deba a la educación, a la actitud, a la inteligencia o lo que sea, no es relevante). ¿Cuánto esfuerzo es un esfuerzo para solucionarlo? Es una pregunta de valor comercial: ¿obtiene más valor al corregir los errores tipográficos que el esfuerzo que dedica a corregirlos? En caso de cosas internas, la respuesta suele ser no. Sus clientes no se quejarán de los errores tipográficos en los comentarios de su código fuente (a menos que esté haciendo una fuente abierta).

Los errores de tipificación intencionales y los comentarios inapropiados no son profesionales y deben evitarse, pero el enfoque debe estar en las cosas importantes (es decir, generar valor comercial, si trabaja para empresas).

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

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

Por ejemplo, no está claro a primera vista si Gor message from queue significa "recibió un mensaje de la cola" o "mensaje GOR de la cola". Necesitará leer el código para comprender el significado del comentario (por lo tanto, vencer el objeto del comentario).

Debe solicitar la implementación de revisiones de código en su empresa. Luego, puede "criticar" a las personas de manera constructiva mientras ellos hacen lo mismo con usted.

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

La única forma en que puedo ver eso es hablar con las personas que realizan el mantenimiento, y usted podría comenzar preguntando si a alguien le resultó más difícil seguir el código que contenía faltas de ortografía.

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

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

En mi experiencia, tales errores ortográficos básicos son preocupantes, y pueden ser sintomáticos de problemas más profundos. Cada proyecto en el que he trabajado con errores "triviales" como ese tuvo problemas reales en el diseño que de alguna manera lo hicieron durante el proceso de revisión solo para surgir durante el desarrollo, que es no cuando se quiere averiguar que la funcionalidad crítica que realmente necesitas no está ahí.

Revisaría las especificaciones del sistema (si existieran) 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 las faltas de ortografía:

1) En el código fuente. Si tienes un identificador como ArgumnetCount , eso puede crear problemas reales cuando alguien aparece y usa la ortografía correcta . Así que deberías arreglar esos errores siempre que sea posible. Si necesita conservar la compatibilidad de API con versiones anteriores, 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 en código). Escribirlos correctamente es importante, pero yo 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, todavía es legible, entonces no se preocupe, no es su problema. Pero si alguien te envía una tontería asociativa gratuita y espera que uses esa tontería como modelo para una aplicación web multiusuario, debes enviar al autor una nota de cortesía que solicite una aclaración (algo así como: "Imbécil analfabeto, ¿cómo? ¿Esperas que entienda esta mierda? ")

La correcta ortografía del inglés es una necesidad en el código. También tengo una gran base de código llena de galimatías y es una pesadilla mantener.

No dejes que esto se te escape de las manos. Trate de educar a todos sobre que los mantenedores del código no son lectores de mentes.

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 gerenciales, son aparentemente incapaces de pronunciar una sola frase en alemán. Su discurso está lleno de palabras de moda y una jerga de administración incomprensible. Decimos que tales personas están hablando "denglish".

Dado que este estado de cosas y el inglés son la "lingua franca", especialmente en el negocio del software, es inevitable que el inglés sea influenciado por la gran cantidad de hablantes no nativos. Pero para los hablantes nativos de inglés esto es aún mejor que tener que aprender, digamos, el chino para participar en la industria de SW.

¿Es color o color? ¿De quién es la versión de inglés que tú crees que es la correcta? La ortografía correcta de un hombre es la excusa de otro hombre para comenzar una guerra que se puede ganar.

Si quieres comenzar una guerra, elige tus batallas con cuidado y gana. En su caso, no se preocupe por los comentarios, no se preocupe más por los aspectos internos y se centre (casi) exclusivamente en los API

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

Un programador que no se toma el tiempo de nombrar las variables correctamente y deletrear los comentarios correctamente es casi seguro que no se toma el tiempo de hacer otra cosa 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 detectados por los clientes
• Para el equipo: el equipo dedica tiempo a corregir la codificación descuidada en lugar de crear valor
• Para los individuos: la mala ortografía te hace ver estúpido y reduce tu posición profesional entre tus compañeros.