Si encuentro un error tipográfico no crítico en el código (por ejemplo, un apóstrofe errante en una declaración de impresión), ¿vale la pena hacer un compromiso para resolver ese error, o simplemente debería dejarse solo?
Específicamente, tengo curiosidad por sopesar el engaño del registro de confirmación contra el valor de resolver estos errores tipográficos no críticos. Me estoy inclinando por resolverlos. ¿Estoy siendo pedante?
Mi opinión personal es que mejorar la calidad vale la pena el inconveniente menor 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 toma en cuenta el efecto de ventana rota .
Es posible que desee prefijarlo con una etiqueta TRIVIAL: , 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 quieres que se mezclen las correcciones de errores que se estrellan con 500 cambios de comentarios / errores tipográficos.
Siempre vale la pena para aumentar la capacidad de mantenimiento de tu software.
Solo ve por ello.
... y si no eres el líder del equipo, entonces consulta con él / ella .
Estoy de acuerdo con los demás en que, al menos, debes escribir algo que sea distinto de los compromisos relacionados con "características", si solo se trata de corregir un error tipográfico aislado.
Una práctica común es tener algunas tareas interminables en su rastreador de problemas para realizar un seguimiento de cambios eternos e interminables. Por ejemplo, no es raro tener una tarea para:
Solo tenga cuidado de que estos no se utilicen como identificadores de tareas desechables para casi nada cuando las personas se vuelven perezosas sobre la creación de tickets documentados correctamente. Especialmente si rechaza las confirmaciones que no están vinculadas a una ID (lo que es bueno, pero las grandes tareas como éstas serán aún más atractivas para los desarrolladores perezosos).
Los errores tipográficos deben agregarse como una confirmación. La corrección de 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 corregido" o "Error tipográfico reparado en archivo.c" le ayudará a distinguir estas confirmaciones de otras confirmaciones de código importantes.
Sí, absolutamente debería hacer esto, especialmente al principio de un proyecto.
¿Por qué? Dos puntos:
Es probable que no sepa si un error tipográfico es "crítico" o no hasta que sea demasiado tarde. Algunas correcciones probablemente no se solucionan porque todos piensan que no será un gran problema. Hasta que esté.
Solucionar un error tipográfico temprano y deliberadamente será mucho más fácil que corregirlo después de que se hayan realizado varios cientos de líneas de llamadas de código / función con él. Una vez más, los hacks temporales pueden convertirse en semipermanentes sorprendentemente rápido. Esta es la razón por la que tengo que tratar con objetos que tienen los métodos "Contraer todo" y "ColapseAll".
Para los errores gramaticales que pueden ser vistos por un usuario final, entonces sí, por todos los medios, vale la pena cometerlo, ya que es totalmente posible que un usuario o control de calidad pueda aparecer e informar del error y debería ser seguido Si ya está solucionado, podría acelerar el tiempo necesario para resolver el problema.
Sin embargo, si se trata de un error gramatical en los comentarios sobre el código, no haría nada al respecto a menos que sea parte de los cambios en el código real, en cuyo caso está actualizando la documentación del código.
Si te preocupa que no se cumpla el registro de confirmación, estarás haciendo algo mal. :-) Los cometidos frecuentes son una buena cosa! Cometo errores tipográficos todo el tiempo. ¡Consígalos en el código base lo antes posible y acelera el ciclo de desarrollo!
Voto que sí. Registrarlos. Trabajé para una empresa que odiaba a las personas que registraban cosas. Me refiero a casi cualquier cosa. Las revisiones de los códigos eran extensas y, por lo tanto, si verificaba un cambio que solo corrigiera un error tipográfico del que había quejado. 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.
¿El proceso de gestión de cambios lo permite?
En mi entorno, cada compromiso que realice debe estar vinculado a una solicitud de cambio que haya sido solicitada por los usuarios empresariales 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á como ninguno de esos (he encontrado errores tipográficos y errores gramaticales en una de mis aplicaciones que existió durante más de 4 años sin que nadie se diera cuenta), así que si / cuando los auditores Llegué a llamar. Me costaría mucho explicarme.
Guardaría un cambio como lo está describiendo (y de hecho tengo uno, de hecho, el nombre de un método está mal escrito y lo acabo de descubrir) por un tiempo en el que tengo un cambio "real" que debe hacerse también y poner "errores tipográficos corregidos" en el registro.
Si le preocupa un historial de confirmación limpio, considere realizar su trabajo principal en ramas de características . Si trabajas con un VCS distribuido , puedes editar fácilmente tu historial de confirmación antes de enviarlo a la rama principal. Si estás en SVN, prueba Git: puede interactuar bidireccionalmente con Subversion, y también puedes editar el historial antes comprometiéndose realmente con Subversion.
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 a las pruebas automáticas ni a la compilación . En estos casos, en mi opinión, mantener limpio el historial de cometer debería ser más importante que hacer comillas realmente atómicas. La combinación de una o dos correcciones tipográficas con una modificación "regular" no perjudicará ningún posible proceso de revisión. Sin embargo, es posible que desee agrupar varias correcciones triviales en un solo compromiso, 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 "cometer todo rápido" incluso para errores tipográficos menores. Tiendo a estar en desacuerdo y doy la bienvenida a la discusión.
Lea otras preguntas en las etiquetas version-control grammar
Además, ¿sabemos cómo se ve antes y después? Haga buenos comentarios sobre qué cambios de formulario presentará a las personas buenas para mejorar: Por cierto, realmente limpié los niveles en //donate.org/menlcos/2012, así que realmente me gusta lo que veo, especialmente con el manejo de las piezas grandes como la abominación de guardián que te advierte dos veces en medio de una fase de auto-traducción no sirve para introducciones awwyeah @ 2pacuil @, (modificó npcs ') No creo haber entendido eso, aunque.... Lee mas