¿Debo señalar errores relacionados con la ortografía / gramática en el código de alguien? [cerrado]

106

Mientras revisaba el código de un compañero de trabajo, me encontré con algunos errores ortográficos en los nombres de funciones y también errores gramaticales como 'doesUserHasPermission ()' en lugar de 'doesUserHavePermission ()' en los nombres de funciones y variables.

¿Debo señalarle esto o estoy siendo demasiado pedante al notar esto?

Rahul
fuente
3
Podría tener cuidado de que la persona realmente quiera ayuda con su inglés, si no es su segundo idioma. Algunas personas se contentan con saber que no son incapaces de expresar un pensamiento estructurado, que simplemente son incapaces de tener un inglés adecuado. Si el inglés es su lengua materna, entonces sí, creo que la mala gramática es un problema.
Rei Miyasaka
31
Si. Es realmente frustrante cuando tienes una API con una ortografía incorrecta. Se propaga como un incendio forestal. Por lo tanto, es mejor corregirlo lo antes posible.
99
@Rei: si el inglés es su idioma nativo o no debe ser irrelevante en un entorno profesional; si no es demasiado malo para ellos, pero no es excusa, deben cumplir con los mismos estándares.
Thomas Bonini
44
@Rei, muchos trabajos de programación que veo anunciados requieren competencia en idiomas nativos por esta misma razón. Poder analizar los requisitos, el diseño, las especificaciones y la construcción son muy importantes para todo el producto de software en su conjunto.
Stephen Furlani
11
HTTP-RefererMe molesta a menudo. en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_term_referer
un nerd pagado el

Respuestas:

205

El código con errores ortográficos y gramaticales no se puede mantener .

  • Las personas no recordarán la mala gramática, por lo que intentarán llamar a la función como debería haberse escrito, y así es como ocurren los errores.

  • No puedes buscar algo en el código si no sabes cómo se escribe.

  • La mayoría de las personas que hacen gramática / ortografía lo hacen de manera inconsistente, por lo que introducirán muchos errores con nombres desiguales. Esto es particularmente problemático en los lenguajes que no requieren que las variables se declaren explícitamente antes de su uso, porque puede introducir una nueva ortografía y su código no se detendrá para hacerle saber que se equivocó.

Corregir estos problemas no es pedante, ni es necesario principalmente por las opiniones de los demás sobre la inteligencia, la alfabetización, etc. (aunque eso es un gran efecto secundario); Se trata de calidad de escritura , código mantenible .

HedgeMage
fuente
77
+1 A veces es importante evitar los sentimientos de alguien, pero cuando se trata de una revisión de código ... si lo captas, es un juego justo comentarlo. Mi compañía usa un crisol para las revisiones de código, lo que permite que todas las revisiones vean que fue capturado y permite al revisor marcarlo no como un defecto, sino como un estilo.
opello
15
+1: una vez que los errores ortográficos y gramaticales llegan a una API, es casi imposible volver a salir. Pasé la mayor parte de tres años teniendo que escribir "Actividad" en lugar de "Actividad", y siempre me dolió físicamente hacerlo.
John Bode
77
Para bien o para mal, las buenas prácticas de programación a menudo se reducen a algo muy parecido a la pedantería. Además, me gustaría encontrar a la persona que escribió mal Referrerla especificación HTTP original y patearlo en el tobillo. Por supuesto, probablemente fue Berners-Lee, así que me sentiría culpable después ...
Malvolio
2
@Stephan Furlani: ese era el punto que estaba tratando de hacer; era parte de una API que no teníamos. No pudimos arreglarlo de nuestra parte, y el proceso para arreglarlo fue feo y lo suficientemente largo como para que nadie quisiera meterse con él.
John Bode
2
@John Bode, creo que deberías haber creado una función de contenedor :) C # tiene un buen truco para eso (aunque olvidé su nombre).
Trabajo
38

Sí definitivamente. Es más fácil recordar el nombre si es gramaticalmente correcto. Intentar recordar el nombre y los errores gramaticales es algo completamente distinto.

Jason Baker
fuente
29

No los señale como defectos en una revisión formal del código. En su lugar, marque una lista y hable con él / ella PRIVADA sobre ellos. Sea lo más diplomático posible al respecto, solo "Oye, algo que noté, y me he encontrado con personas que REALMENTE desprecian este tipo de cosas, piensan que hace que el programador se vea descuidado y descuidado".

Si se trata de un código que un cliente verá, DEBE corregirse absolutamente. Nos guste o no, sí refleja la reputación de su empresa.

Para el ejemplo que diste, sospecho que comenzó como UserHasPermission, y alguien más le dijo que la práctica local era doesUserBlahBlah () en lugar de UserBlahBlah (), y simplemente pasó por alto el cambio de gramática.

John R. Strohm
fuente
12
Decir que se trata de las percepciones de los demás hace que parezca poco importante. Diga la verdad: están haciendo que el código sea más difícil de mantener y construir.
HedgeMage
55
@HedgeMage: Mi experiencia personal con cosas como esta es que algunas personas son EXTREMADAMENTE sensibles a las cosas que perciben como críticas de sí mismas. Peor aún, puede haber repercusiones políticas realmente feas, si la persona que parece criticar es amada por la gerencia. (Sí, tengo las cicatrices para probar esto). Y he visto organizaciones que literalmente no se preocuparon por este tipo de cosas, siempre y cuando el código funcionara, para alguna definición de "trabajado". Mi sensación personal es que tienes una mejor oportunidad de arreglarlo, con un mínimo de otros dolores de cabeza, si vas con cuidado.
John R. Strohm
12
@John Ciertamente puedo ver que una mala situación laboral puede obligar a alguien a caminar sobre cáscaras de huevo así, pero es una mala situación si eso es un problema en primer lugar. Alguien con un ego tan frágil (y una cultura en el lugar de trabajo que permite a sus travesuras) no es bueno para comenzar con los negocios.
HedgeMage
66
La mayoría de los programadores maduros aceptan bien las críticas. Después de todo, para eso son las revisiones por pares (y todos hacemos revisiones de código, ¿no?) Está bien criticar la ortografía y la gramática de los comentarios, los nombres de las funciones, etc. TODO se refleja no solo en el autor sino en toda su organización.
rapid_now
66
Tengo que estar de acuerdo con HedgeMage aquí, si no puede señalar errores como este durante una revisión de código (particularmente cuando están objetivamente equivocados, como el ejemplo en la pregunta), entonces tiene problemas más grandes ...
Dean Harding
10

Cámbialo tú mismo.

Esperemos que se encuentre en un entorno donde el código "propiedad" no sea un problema. Si tiene acceso al proyecto en el control de origen, simplemente entre y corríjalo usted mismo. Si ve que un compañero de trabajo en particular comete el mismo tipo de gramática o errores de ortografía de manera constante, es posible que desee señalarlo, pero eso dependerá de su relación, si la persona es un hablante nativo de inglés y su receptividad general. Pero si alguna vez decides hacer eso o no, simplemente ve y haz el arreglo. Hago esto todo el tiempo, si veo un error tipográfico, especialmente en una firma de método o propiedad pública, simplemente lo soluciono. Ocasionalmente, ni siquiera puedo resistir la tentación de corregir un error tipográfico en un comentario, pero solo soy yo :)

Marcie
fuente
55
Y luego descubres que acabas de romper el código de un tercero. Necesitas arreglar este tipo de cosas lo antes posible, no solo cuando puedes hacerlo después de que el primer tipo haya revisado todo.
David Thornley
Si le preocupa que una solución a cualquier fragmento de código pueda romper el código de "otra persona", y no tiene forma de saberlo, entonces tiene mayores problemas que la ortografía.
Cornel Masson
@ CornelMasson: No realmente. Esta es una parte clave del diseño de una API.
Carreras de ligereza en órbita el
6

Soy un desarrollador cuyo idioma nativo no es el inglés, en realidad es holandés, y no me importaría si alguien me señalara un error gramatical o de ortografía. De esa manera puedo seguir mejorando constantemente mi inglés. Y ciertamente no es difícil corregir todos los errores en todo su código fuente. Se puede escribir fácilmente una secuencia de comandos Perl simple para recorrer todos los archivos de una carpeta. ¿Quizás incluso se puede hacer con sed? No lo sé.

Entonces, ciertamente señalaría errores gramaticales o ortográficos en el código de otra persona, pero solo si estoy absolutamente seguro de si es correcto lo que estoy diciendo.


fuente
6

Supongo que vale la pena mencionar aquí que el encabezado de referencia HTTP en el protocolo HTTP estaba mal escrito como "referente" (y tenemos que vivir con él / hemos aprendido a vivir con él) :)

Conejo conejo
fuente
10
Y nunca queremos volver a ver ese tipo de cosas.
David Thornley
4

Estoy de acuerdo con otras respuestas que dicen que el código con errores gramaticales es imposible de mantener.

También quiero agregar algunas cosas:

  • El código a menudo es escrito por personas que no hablan inglés muy bien y / o el inglés no es su idioma nativo. Si hay un error gramatical en un código que revisa, esto no significa que su compañero de trabajo haya cometido este error. Tal vez fue solo un copiar y pegar de un sitio web.
  • Si el inglés no es el idioma nativo de su compañero de trabajo, puede ser una buena o muy mala idea contarle este error. Siendo de Francia, siempre agradezco los comentarios sobre los errores que hago en inglés, porque es la única forma en que puedo evitarlos en el futuro; Por otro lado, conozco a varias personas que se sienten realmente heridas si les cuentas sobre los errores gramaticales que cometen.
  • Como dijo John R. Strohm, nunca lo hagas públicamente. La mayoría de la gente estará realmente molesta por esto.
Arseni Mourzenko
fuente
11
"Tal vez fue solo una copia de un sitio web". Entonces la persona que lo copió debería haber captado el problema y solucionarlo. Copiarlo textualmente y dejar errores es tan malo o peor que escribirlo ellos mismos y crear los errores. "Conozco a varias personas que se sienten realmente heridas si les cuentas sobre los errores gramaticales que cometen". En los negocios, todos debemos comportarnos como adultos y compañeros de trabajo que se están uniendo para lograr un objetivo común. La persona que plantea el problema debe usar el tacto, y la persona que recibe la crítica debe aceptarlo y crecer a partir de él.
The Tin Man
3
Estoy 100% de acuerdo en que, como profesionales, debemos comportarnos como adultos y no tomar esto como algo personal. Pero es absolutamente necesario señalarlo y corregirlo. Sí, se debe usar el tacto y se debe abordar según sea necesario, dependiendo del individuo. Pero si se encuentra en un entorno en el que se recomienda evitar el problema por completo, tal vez sea hora de irse. Esto apuntaría a un ambiente envenenado.
Mark Freedman
Cualquier error de ortografía se puede verificar con una simple búsqueda en Google
JoelFan
2

Recomendaría usar un IDE con un corrector ortográfico incorporado. IntelliJ Idea hace un trabajo maravilloso para los programas Java. Hay muchos errores tipográficos embarazosos que detecta, no solo en los nombres de las funciones, sino también, por ejemplo, en los mensajes de excepción que el usuario puede ver. Un programa que produce mensajes llenos de errores tipográficos no inspira mucha confianza.

Roman Zenka
fuente
0

Lo hago solo si

  • afecta el uso del programa
  • afecta la precisión del programa
  • Sé explícitamente que el autor quiere ser corregido.

Como nota al margen, si los nombres de sus funciones son lo suficientemente largos como para tener gramática, probablemente sean demasiado largos. En el ejemplo dado, llamaría a la función userHasPermission y movería la "gramática" a su código, algo como esto:

if userHasPermission() ...
Mark Harrison
fuente
1
Sin embargo, todavía hay el mismo potencial para errores gramaticales, ya que en este caso userHavePermission()estaría mal.
Dean Harding
¡Pero ese es exactamente el punto! userHasPermission()implica que devuelve un bool debido a la gramática ~ O ~ podría significar que establece el permiso del usuario. (El oficial tiene el puente :: el usuario tiene permiso). Todavía es vago.
Stephen Furlani
Si bien estoy de acuerdo en que los nombres de ejemplo en la Q son innecesariamente largos, advierto sobre la generalización "demasiado larga". En este caso, el concepto puede expresarse en menos palabras, por lo que debería ser más corto. Sin embargo, ¿qué es "demasiado largo"? ¿Hay un límite de caracteres o palabras?
LS
0

Esto también sucede MUCHO en mi proyecto (poblado por personas nativas de habla hebrea, rusa o árabe), pero incluso a un nivel superior, a menudo veo un código que usa una terminología oscura que es lo que el diccionario produjo como traducción para lo que el autor tenía en mente, y no tiene nada que ver con lo que querían decir ...

Personalmente, cuando sucede con tanta frecuencia y por tantos miembros del equipo que podrían haber escrito el código incluso antes de unirme al proyecto, tiendo a ignorarlo, porque simplemente no importará.

Sin embargo, si estoy cometiendo algo de trabajo en el mismo archivo que el código o los comentarios que se escribieron hace mucho tiempo y tienen errores tipográficos, los corregiré solo porque no es demasiado trabajo.

Daniel Hershcovich
fuente
0

Aplica la regla de oro

Haz a los demás como te gustaría que te hicieran a ti.

Quiero que otros me respalden en este tipo de cosas, así que ayudo a otros. Ser amable y solidario puede ser de gran ayuda a su favor.

kevpie
fuente
2
-1 por vaguedad: no tengo idea de lo que le aconsejas al interrogador que haga.
HedgeMage
@HedgeMage, le aconsejo al OP que aplique en.wikipedia.org/wiki/The_Golden_Rule
kevpie
2
Estoy familiarizado con eso. Además de ser patentemente tonto (no hay razón para creer que la forma en que Alice quiere ser tratada es la forma en que Bob quiere ser tratado), distrae del problema real: crear un buen código. Claro, no voy a ser un imbécil al respecto, ¡pero no estoy basando si plantear o no un problema técnico sobre si la persona que escribe un código incorrecto quiere o no que se plantee!
HedgeMage
Creo que la queja de @ HedgeMage puede ilustrarse así: quiero que el código sea de la más alta calidad permitida por el tiempo y los recursos disponibles, porque me importa el proyecto y mi futuro trabajo en él. Bob quiere evitar las críticas por errores corregibles, porque no toma bien las críticas. Implementaremos la "regla de oro" de manera muy diferente.
párpado
El consejo significa que el OP opera como le gustaría que lo trataran. No tratar a Bob como Bob querría ser tratado. Estaba alentando al OP a corregir a Bob ya que él (el OP) querría ser corregido por los mismos errores, específicamente en el contexto que el OP ha compartido.
kevpie
0

Al igual que con muchas otras buenas prácticas de programación, la única forma objetiva, no política y efectiva de implementar una política sobre ortografía en los programas es automatizarla como parte del proceso de precompromiso. La automatización lo salvará de enormes cantidades de quejas, incluso si tiene que escribir su propia herramienta para ese propósito.

Apalala
fuente
3
Muchos de los errores más importantes no pueden detectarse automáticamente. Esto también se aplica a la ortografía y la gramática. Podría hacer una verificación automática, pero los resultados tendrían que ser equivalentes a las advertencias. Esto se debe a que los correctores ortográficos producen falsos positivos (por ejemplo, nombres propios) y falsos negativos (dos, también, a). Entonces la intervención manual es necesaria.
Matthew Flaschen
Ese tipo de automatización no resuelve estos problemas, solo detecta algunos de los errores que comete la gente.
superado el
Autocorrección ??? Hay muchos ejemplos de autocorrección "falla" en Internet. Eso definitivamente no es bueno.
Florian F
0

Este es un error menor en el código, pero es un error. Trátelo como cualquier otro error que encuentre. Mi política es siempre asumir que mis compañeros de trabajo son competentes y tratarlos de esa manera hasta que demuestren lo contrario.

Si se trata de un solo error, podría solucionarlo y comprobarlo. Si se trata de un patrón, podría comenzar a hacer que ese compañero de trabajo revise esas correcciones. Hágales saber que cree que son un buen programador, pero que esto es algo que sería bueno mejorar. Sin embargo, creo que nunca haría un gran problema con algo como esto.

Mientras no lo trates como si fuera un gran problema, debería ser fácil poner a ese compañero de trabajo en una posición en la que pueda mejorar sin poner el ego en juego.

entendido
fuente
-1

userPermission () quizás? -

El último que encontré fue un problema global de resultados de búsqueda que no se resaltan porque el nombre de la clase se deletrea resaltado. Error muy oscuro para detectar.

mplungjan
fuente
Votar sin hacer comentarios es una abominación.
mplungjan
-1

Claro que sí, pero no pierdas el tiempo buscando errores ortográficos. Use una herramienta para automatizar esto en su CI. En .net fxCop puede hacer esto ...

khebbie
fuente
-2

Depende en gran medida de cuáles son los errores, qué tan comunes y qué tan graves son, y si en realidad es un error de buena fe o no, simplemente, cómo lo diría.

Personalmente, no puedo soportarlo cuando un idiota arrastra una revisión de código de 5 minutos a media hora porque quiere que todo cambie de nombre a cómo lo haría y todos los comentarios vuelvan a redactarse solo porque le gusta pegar su remo. Una línea de registro que dice "Cargar objetos de datos" no necesita cambiarse a "El componente del cargador de objetos de datos ahora cargará los objetos de datos relevantes del componente de almacenamiento de objetos de datos".

/ rant :)

JohnL
fuente
2
Insistir en las cosas a mi manera es una cosa. Insistir en que las cosas usan la ortografía y la gramática adecuadas es otra cosa completamente distinta.
David Thornley
No estoy completamente seguro de por qué mi respuesta merece un voto negativo, pero no importa ... Además, ¿a dónde fue mi respuesta al comentario de David? De todos modos, la gramática inglesa 100% correcta no siempre es deseable en el desarrollo. En mi ejemplo anterior, "Cargar objetos de datos" no es una oración completa, pero es la redacción más preferible de los dos: conciso, fácil de localizar y no ocupa mucho espacio.
JohnL