Si me encuentro con un error tipográfico no crítico en el código (por ejemplo, un apóstrofe errante en una declaración de impresión (error)), ¿vale la pena hacer un compromiso para resolver ese error, o simplemente debería dejarse solo?

Específicamente, tengo curiosidad por sopesar el engomamiento del registro de confirmación con el valor de resolver estos errores tipográficos no críticos. Me inclino por resolverlos. ¿Estoy siendo pedante?

Mi sensación personal es que mejorar la calidad vale la menor molestia de una entrada de registro de confirmación adicional, incluso para pequeñas mejoras. Después de todo, las pequeñas mejoras cuentan mucho cuando se tiene en cuenta el efecto de ventana rota .

Es posible que desee agregar un prefijo con una TRIVIAL:etiqueta, o marcarlo como trivial si su VCS lo admite.

No estás siendo pedante, y es mejor resolverlos individualmente. Cuanto más atómico sea un cambio, mejor: no querrá que una corrección de error se mezcle con 500 comentarios / errores tipográficos.

En el caso general: sí

Es siempre vale la pena para aumentar la capacidad de mantenimiento de su software.

Solo házlo.

Si estás a punto de enviar un lanzamiento ...

... y si no eres el líder del equipo, consulta con él / ella .

En cuanto al contenido del registro de confirmación ...

Estoy de acuerdo con otros en que al menos deberías escribir algo que lo haga diferente de los commits relacionados con "características", si solo se trata de arreglar un error tipográfico aislado.

Una práctica común es tener algunas tareas que nunca mueren en su rastreador de problemas para rastrear cambios eternos e interminables. Por ejemplo, no es raro tener una tarea para:

• grandes limpiezas automáticas e inofensivas (barridos de espacios en blanco),
• juergas de caza de gramática y error tipográfico,
• construir modificaciones del sistema,
• etc ...

Solo tenga cuidado de que estos no se usen como ID de tareas descartables para casi cualquier cosa cuando las personas se vuelven flojas sobre la creación de tickets correctamente documentados. Especialmente si rechaza las confirmaciones que no están vinculadas a una ID (lo cual es bueno, pero las tareas grandes como estas serán aún más atractivas para los desarrolladores perezosos).

Los errores tipográficos deben agregarse como confirmación. Corregir palabras mal escritas o errores gramaticales aumentará la legibilidad de su código.

El uso de un mensaje de confirmación como "Error tipográfico fijo" o "Error tipográfico fijo en el archivo.c" le ayudará a distinguir estas confirmaciones de otras confirmaciones de código principales.

Sí, absolutamente debe hacer esto, especialmente al principio de un proyecto.

¿Por qué? Dos puntos:

1. Es probable que no sepa si un error tipográfico es "crítico" o no hasta que sea demasiado tarde. Algunas soluciones probablemente no se solucionen porque todos piensan que no será un gran problema. Hasta que lo sea.

2. Arreglar un error tipográfico desde el principio y deliberadamente será mucho más fácil que arreglarlo después de que se hayan realizado cientos de líneas de código / llamadas de función con él. Una vez más, los hacks temporales pueden volverse semipermanentes sorprendentemente rápidos. Es por eso que tengo que tratar con objetos que tienen los métodos "CollapseAll" Y "ColapseAll".

Para errores gramaticales que pueden ser vistos por un usuario final, entonces sí, por todos los medios vale la pena realizar el compromiso, ya que es completamente posible que un usuario o QA pueda aparecer y reportar el error y necesitaría ser rastreado. Si ya está solucionado, podría acelerar el tiempo que lleva resolver el problema.

Sin embargo, si es un error gramatical en los comentarios sobre el código, no haría nada al respecto a menos que también sea parte de los cambios en el código real, en cuyo caso está actualizando la documentación del código.

Si te preocupa engrosar el registro de confirmación, entonces estás haciendo algo más mal. :-) ¡Los commits frecuentes son algo bueno! Cometo errores tipográficos todo el tiempo. ¡Consígalos en la base de código lo antes posible y acelere el ciclo de desarrollo!

Yo voto si. Verifíquelos. Trabajé para una compañía que odiaba a las personas que registraban cosas. Me refiero a casi cualquier cosa. Las revisiones de código fueron extensas y, por lo tanto, si registró un cambio que simplemente solucionó un error tipográfico, se le quejó. Puedes imaginar el estado del código. En realidad, el código no era terrible, pero rezumaba como melaza en lugar de fluir como vino.

¿Su proceso de gestión de cambios lo permite?

En mi entorno, cada compromiso que realizo debe estar vinculado a una solicitud de cambio que haya sido solicitada por los usuarios comerciales o un cambio obligatorio a nivel del sistema, completo con los procesos de prueba correspondientes del usuario final. Un error tipográfico simple como el que estás describiendo probablemente no se registraría como ninguno de esos (he encontrado errores tipográficos y gramaticales en una de mis aplicaciones que existieron durante más de 4 años sin que nadie lo notara), así que si / cuando vinieron los auditores llamando me costaría mucho explicarme.

Guardaría un cambio como el que está describiendo (y de hecho tengo uno, de hecho, el nombre de un método está mal escrito y lo acabo de descubrir) para un momento en que tengo un cambio "real" que debe ser hecho también y poner "arreglados varios errores tipográficos" en el registro.

Use DVCS para editar el historial

Si le preocupa un historial de confirmación limpio, considere hacer su trabajo principal en las ramas de características . Si trabaja con un VCS distribuido , puede editar fácilmente su historial de confirmación antes de llevarlo a la rama principal. Si está en SVN, intente con Git: puede interactuar bidireccionalmente con Subversion y también puede editar el historial antes de comprometerse realmente con Subversion.

Mantenga el sentido común de lo contrario

Si no desea o no puede editar el historial de confirmaciones, no hay ninguna razón funcional para realizar una confirmación temprana o atómica para un error tipográfico menor que no afecte las pruebas automáticas o la compilación . En este caso, en mi opinión, mantener limpio el historial de confirmaciones debería ser más importante que realizar confirmaciones realmente atómicas. Mezclar una o dos correcciones tipográficas con una modificación "regular" no dañará ningún proceso de revisión potencial. Sin embargo, es posible que desee agrupar varias correcciones triviales en una confirmación, tal vez al "limpiar" después de una sesión de codificación más grande.

Tenga en cuenta que los errores funcionales aún deben confirmarse lo antes posible en una confirmación atómica.

El tono general de las respuestas aquí parece sugerir una estrategia de "comprometer todo rápido" incluso para errores tipográficos menores. Tiendo a estar en desacuerdo y agradezco la discusión.