Registro de código "comentado" [cerrado]

Ok, aquí hay algo que ha causado cierta fricción en mi trabajo actual y realmente no esperaba que lo hiciera. El desarrollo de software organizado en casa es un concepto nuevo aquí y he elaborado un primer borrador de algunas pautas de codificación.

He propuesto que el código "comentado" nunca debería registrarse en el repositorio. La razón por la que he dicho esto es que el repositorio mantiene un historial completo de los archivos. Si está eliminando el código funcional, elimínelo por completo. El repositorio conserva sus cambios para que sea fácil ver qué se cambió.

Esto ha causado cierta fricción en el sentido de que otro desarrollador cree que tomar esta ruta es demasiado restrictivo. A este desarrollador le gustaría poder comentar algún código en el que está trabajando pero que está incompleto. Este código nunca se habría registrado antes y luego no se habría guardado en ningún lugar. Vamos a utilizar TFS, por lo que sugerí que dejar de lado los cambios sería la solución más correcta. Sin embargo, no se aceptó porque le gustaría poder registrar los cambios parciales que pueden implementarse o no.

Queremos llegar eventualmente a un punto en el que estemos aprovechando al máximo la integración continua y la implementación automática en un servidor web de desarrollo. Actualmente no hay una versión de desarrollo de servidores web o servidores de bases de datos, pero todo eso cambiará pronto.

De todos modos, ¿qué piensas? ¿Cree que es útil tener código "comentado" en el repositorio?

Estoy muy interesado en escuchar a otros sobre este tema.

Editar: en aras de la claridad, no usamos ramas privadas. Si lo hiciéramos, entonces diría que haga lo que quiera con su rama privada, pero nunca fusione el código comentado con el tronco o cualquier rama compartida.

Editar: No hay ninguna razón válida por la que no usemos ramas privadas o por usuario. No es un concepto con el que no esté de acuerdo. Simplemente no lo hemos configurado de esa manera todavía. Quizás ese sea el término medio eventual. Por ahora usamos estanterías TFS.

Puede haber otros con diferentes experiencias, pero en la mía, verificar el código a medio terminar es una idea horrible, punto.

Estos son los principios que he aprendido y trato de seguir:

• Regístrese con frecuencia, al menos una vez, pero preferiblemente muchas veces al día
• Solo verifique la funcionalidad completa
• Si el primer y el segundo conflicto (por ejemplo, lleva más de un día hacer que la funcionalidad funcione) entonces la tarea es demasiado grande, divídala en tareas más pequeñas que se puedan completar.

Esto significa:

• El código comentado nunca debe registrarse ya que no es funcional
• Comentar no es una estrategia de archivo válida, por lo que si se trata de un código aún por terminar o un código que se está retirando, comentar y registrar no tiene ningún sentido.

Entonces, en resumen, ¡NO! Si el código no está listo para pasar a la siguiente etapa (lo que sea para usted: IntTest / QA / UAT / PreProd / Prod), no debe estar comprometido con una rama troncal o de múltiples desarrolladores. Período.

Editar: Después de leer las otras respuestas y comentarios, agregaré que no creo que sea necesariamente una buena idea prohibir el código comentado (no estoy seguro de cómo lo harías cumplir). Lo que diré es que debes hacer que todos en tu equipo acepten la filosofía que describí anteriormente. El equipo en el que trabajo lo acepta de todo corazón. Como resultado, el control de fuente es un miembro del equipo sin problemas, uno que nos ayuda a hacer nuestro trabajo.

Las personas que no adoptan esa filosofía suelen provocar la rotura de ventanas y, a menudo, se sienten frustradas por el control de fuentes. Lo ven como un mal necesario en el mejor de los casos, y algo que evitar en el peor; lo que lleva a registros poco frecuentes, lo que significa que los conjuntos de cambios son enormes y difíciles de fusionar, lo que agrava la frustración, hace que los registros sean algo que se debe evitar aún más, etc. Esto es, en última instancia, una cuestión de actitud, no realmente una cuestión de proceso. Es fácil poner barreras mentales en su contra; es fácil encontrar razones por las que no funcionará, al igual que es fácil encontrar razones para no hacer dieta si realmente no lo desea. Pero cuando las personas no quieren hacerlo y se comprometen a cambiar sus hábitos, los resultados son dramáticos. La carga recae en usted para venderlo de manera efectiva.

"Nunca" rara vez es una buena palabra para usar en las pautas.

Su colega tiene un gran ejemplo de cuándo podría ser apropiado registrar el código que está comentado: cuando está incompleto y podría romper la aplicación si se registra mientras está activo.

En su mayor parte, comentar el código muerto es innecesario en un sistema bien administrado y controlado por cambios. Pero no todo el código comentado está "muerto".

El código comentado nunca debe registrarse con el fin de mantener el historial. Ese es el punto del control de la fuente.

La gente habla de muchos ideales aquí. Quizás a diferencia de todos los demás, tengo que trabajar en múltiples proyectos con múltiples interrupciones con el "mundo real" que ocasionalmente interrumpe mi jornada laboral.

A veces, la realidad es que tengo que registrar el código parcialmente completo. Existe el riesgo de perder el código o de registrar un código incompleto. No siempre puedo permitirme "terminar" una tarea, por pequeña que sea. Pero no desconectaré mi computadora portátil de la red sin registrar todo el código.

Si es necesario, crearé mi propia rama de trabajo para realizar cambios parciales.

Un caso en el que dejo el código comentado:

// This approach doesn't work
// Blah, blah, blah

cuando ese es el enfoque obvio del problema pero contiene algún defecto sutil. Claro, el repositorio lo tendría, pero el repositorio no advertiría a nadie en el futuro que no siguiera ese camino.

Ciertamente, desaconsejaría, enérgicamente, verificar el código comentado. Sin embargo, no lo prohibiría absolutamente. A veces (aunque raras veces) es apropiado verificar el código comentado en el control de fuente. Decir "nunca hagas eso" es demasiado restrictivo.

Creo que todos estamos de acuerdo con estos puntos:

• Nunca verifique el código muerto en el control de fuente
• Nunca verifique el código roto (que no funciona) en el control de fuente, al menos nunca en el tronco y muy raramente en una sucursal privada, YMMV
• Si ha comentado algo temporalmente o ha roto algo con fines de depuración, no verifique el código hasta que lo restaure a su forma correcta.

Algunos dicen que hay otras categorías, como el código eliminado temporalmente o una mejora incremental pero incompleta que incluye una pequeña cantidad de código comentado como documentación de lo que viene a continuación, o un fragmento muy corto (idealmente de 1 línea) de comentario código que muestra algo que nunca debería volver a agregarse. El código comentado SIEMPRE debe ir acompañado de un comentario que diga por qué está comentado (y no solo eliminado) y da la vida útil esperada del código comentado. Por ejemplo, "El siguiente código hace más daño que bien, por lo que está comentado, pero debe ser reemplazado antes del lanzamiento XXX".

Un comentario como el anterior es apropiado si está entregando una revisión para detener el sangrado de un cliente y no tiene la oportunidad inmediata de encontrar la solución definitiva. Después de entregar la revisión, el código comentado es un recordatorio de que todavía tiene algo que debe ser arreglado.

¿Cuándo registro el código comentado? Un ejemplo es cuando estoy eliminando provisionalmente algo que creo que hay una alta probabilidad de que deba volver a agregarse en el futuro cercano, de alguna forma. El código comentado está ahí para servir como un recordatorio directo de que está incompleto. Claro, la versión anterior está en control de fuente y podría usar un comentario FIXME como una señal de que se necesita algo más. Sin embargo, a veces (si no a menudo) el código es el mejor comentario.

Además, cuando se soluciona un error eliminando una línea (o más raramente, dos líneas) de código, a veces simplemente comentaré la línea con un comentario para nunca volver a habilitar ese código con una razón. Este tipo de comentario es claro, directo y conciso.

Rex M dijo: 1) Solo verifique la funcionalidad completa, 2) [Si] la tarea es demasiado grande, divídala en tareas más pequeñas que se puedan completar.

En respuesta: Sí, este es el ideal. A veces, ninguna de las opciones se puede lograr cuando está trabajando en el código de producción y tiene un problema crítico inmediato que solucionar. A veces, para completar una tarea, es necesario poner una versión del código en el campo durante un tiempo. Esto es especialmente cierto para los cambios en el código de recopilación de datos cuando intenta encontrar la causa raíz de un problema.

Para la instancia específica sobre la que se pregunta en la pregunta más general ... siempre que el desarrollador esté verificando el código comentado en una rama privada que nadie verá más que ese desarrollador (y quizás alguien con quien el desarrollador esté colaborando), hace poco daño. Pero ese desarrollador (casi) nunca debería entregar dicho código en el tronco o equivalente. Trunk siempre debería construirse y debería funcionar siempre. Entregar código sin terminar al tronco es casi siempre una muy mala idea. Si permite que un desarrollador verifique el código temporal o sin terminar en una rama privada, entonces debe confiar en que el desarrollador no se olvide de limpiar el código antes de entregarlo en el tronco.

Para aclarar en respuesta a los comentarios de otras respuestas, si el código está comentado y registrado, mi expectativa de que el código funcione si no se comenta cae con el tiempo que el código ha sido comentado. Obviamente, las herramientas de refactorización no siempre incluirán comentarios en su refactorización. Casi siempre, si pongo código comentado en producción, el código está ahí para servir como un comentario refinado, algo más específico que la prosa, de que hay que hacer algo allí. No es algo que deba tener una larga vida.

Por último, si puede encontrar código comentado en cada archivo fuente, entonces algo anda mal. La entrega de código comentado en el tronco por cualquier motivo debería ser un evento poco común. Si esto ocurre con frecuencia, se vuelve desordenado y pierde su valor.

Creo que nunca es una condición demasiado fuerte.

Tiendo a comentar, registrar, ejecutar las pruebas, pensar y luego eliminar comentarios después de la próxima versión.

En general, registrar el código comentado es incorrecto, ya que crea confusión entre quienes no son el autor original y necesitan leer o modificar el código. En cualquier caso, el autor original a menudo termina confundido acerca del código después de 3 meses.

Defiendo la creencia de que el código pertenece a la empresa o al equipo y que es su responsabilidad facilitar las cosas a sus compañeros. Registrar el código comentado sin agregar también un comentario sobre por qué se retiene es equivalente a decir:

No me importa si terminas confundido sobre por qué estas cosas están aquí. Mis necesidades son más importantes que las tuyas y por eso he hecho esto. No siento la necesidad de justificar ante usted ni ante nadie más por qué he hecho esto.

Para mí, el código comentado normalmente se ve como una falta de respeto por parte de un compañero de trabajo menos reflexivo.

Estoy ampliamente de acuerdo con el principio de que el código comentado no debe registrarse. El sistema de control de fuentes es un recurso compartido y su colega, hasta cierto punto, lo está utilizando como su bloc de notas personal. Esto no es muy considerado con los otros usuarios, especialmente si se suscribe a la idea de propiedad compartida del código base.

El próximo desarrollador que vea ese código comentado no tendrá idea de que es un trabajo en progreso. ¿Es libre de cambiarlo? ¿Es un código muerto? No lo sabe.

Si el cambio de su colega no está en un estado en el que se pueda registrar, debe terminarlo y / o aprender a hacer cambios incrementales más pequeños.

"Verificar cambios parciales que pueden implementarse o no": ¿presumiblemente eso también significa que pueden o no probarse? Esa es una pendiente resbaladiza para una base de código muy complicada.

Cuando necesite agregar una pequeña característica o corregir un error como AHORA, dentro de los próximos 3 minutos y tenga que arreglar un archivo en el que tiene un código medio desarrollado, diría que está bien, las necesidades prácticas gobiernan los ideales pragmáticos en el campo de batalla.

Esto muestra una diferencia fundamental en dos escuelas de pensamiento: Aquellos que solo verifican el código de trabajo con el que están satisfechos y creen que es digno de guardar, y aquellos que verifican su trabajo para que el control de revisión esté ahí para respaldarlos contra la pérdida de datos.

Caracterizaría a estos últimos como "aquellos a los que les gusta usar su sistema de control de revisiones como una copia de seguridad en cinta de los pobres", pero eso sería una revelación en cuanto a en qué campo estoy. :-)

Supongo que usted es del campo del "buen código" y él del campo del "código de trabajo".

[EDITAR]

Por los comentarios, sí, acerté.

Como dije, estoy con ustedes, pero por lo que puedo decir, esta es una opinión minoritaria, tanto aquí en stackoverflow como en donde trabajo. Como tal, no creo que realmente pueda consagrarlo en sus estándares de desarrollo como la única forma de operar. No si quieres que se sigan los estándares de todos modos. Una cosa que un buen líder sabe es que nunca debe dar una orden que sabe que no se seguirá.

Por cierto: los buenos editores ayudarán a mantener las versiones antiguas. Por ejemplo, en Emacs configuré las versiones antiguas conservadas y las versiones antiguas mantenidas en 10, lo que hace que se mantengan alrededor de las últimas 10 guardadas de mis archivos. Puede considerar eso como una forma de ayudar en su argumento contra la multitud de control de revisiones como respaldo. Sin embargo, nunca ganarás la discusión.

En mi experiencia, los cambios de desarrollador son código comentado.

A veces, los nuevos back-end se construyen en paralelo, con los interruptores de activación comentados en el control de fuente.

Alguna característica extraña que necesitamos una vez en una luna azul, pero que ningún cliente necesitará nunca, a menudo se implementa de esa manera. Estas cosas generalmente conllevan un alto riesgo de omisión de seguridad o integridad de los datos, por lo que no las queremos activas fuera del desarrollo. Exigir a un desarrollador que lo usaría para descomentar el código primero parece ser la forma más fácil de obtenerlo.

Otra razón para registrar el código comentado:

Está modificando el código existente y encontró un error sutil, uno que es fácil de pasar por alto y que quizás incluso parezca correcto a primera vista. Comente, coloque la corrección en su lugar y agregue comentarios sobre lo que está sucediendo y por qué se modificó. Compruébelo para que sus comentarios sobre la corrección estén en el repositorio.

Quizás la pregunta real aquí es si los desarrolladores deberían poder verificar el código incompleto.

Esta práctica parecería contradecir su objetivo declarado de implementar la integración continua.

Depende. Si se deja allí con fines ilustrativos, tal vez. Posiblemente podría ser útil durante la refactorización. De lo contrario, y en general, no. Además, comentar el código inacabado está destinado a ser propenso a fallas y a perder tiempo. Mejor que rompa el código en partes más pequeñas y las revise cuando funcionen.

Mi punto de vista: si los desarrolladores están trabajando en sus propias sucursales, o en su propia zona de pruebas, deberían poder registrar lo que quieran. Es cuando verifican el código en una rama compartida (una rama de funciones, o la rama de un equipo, o por supuesto MAIN / trunk) que el código debe ser lo más prístino posible (sin código comentado, no más FIXMEs, etc.).

Creo que "Nunca" es una regla demasiado fuerte. Votaría para dejar un margen de maniobra personal sobre si las personas verifican el código comentado en el repositorio. El objetivo final debería ser la productividad del codificador, no "un repositorio prístino".

Para equilibrar esa laxitud, asegúrese de que todos sepan que el código comentado tiene una fecha de vencimiento. Cualquiera puede eliminar el código comentado si ha existido durante una semana completa y nunca ha estado activo. (Reemplace "una semana" con lo que le parezca adecuado.) De esa manera, se reserva el derecho de eliminar el desorden cuando lo vea, sin interferir demasiado directamente con los estilos personales de las personas.

Estoy absolutamente de acuerdo en que el código comentado no debe registrarse en el repositorio, para eso está el control del código fuente.

En mi experiencia, cuando un programador verifica el código comentado, es porque no está seguro de cuál es la solución correcta y está más feliz de dejar la solución alternativa en la fuente con la esperanza de que alguien más tome esa decisión.

Encuentro que complica el código y dificulta su lectura.

No tengo ningún problema con verificar el código a medio terminar (para que obtenga el beneficio del control de fuente) que no es llamado por el sistema en vivo. Mi problema es encontrar secciones de código comentado sin explicación, el dilema fue que resultó en la exclusión del código.

Creo que la verificación del código comentado en un sistema de control de código fuente debe realizarse con extrema precaución, especialmente si las etiquetas de idioma utilizadas para comentar el código están escritas por bloques, es decir:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

En lugar de una línea individual, como:

// My commented code start here
// My commented code line 1
// My commented code line 2

(entiendes la idea)

La razón por la que usaría extrema precaución es que, dependiendo de la tecnología, debe tener mucho cuidado con la herramienta de diferenciación / combinación que está utilizando. Con cierto sistema de control de código fuente y cierto lenguaje, la herramienta diff / merge puede confundirse fácilmente. El diferencial / fusión estándar de ClearCase, por ejemplo, es notoriamente malo para fusionar archivos .xml.

Si sucede que las líneas de los bloques de comentarios no se combinan correctamente, su código se activará en el sistema cuando no debería. Si el código está incompleto y rompe la compilación, probablemente sea el menos malo, ya que lo detectará de inmediato.

Pero si el código pasa la compilación, puede activarse cuando no debería estar allí, y desde una perspectiva de CM, ese podría ser un escenario de pesadilla. El control de calidad generalmente prueba lo que debería estar allí, no prueba el código que se supone que no debe estar allí, por lo que su código puede terminar en producción antes de que usted se dé cuenta, y para cuando se dé cuenta de que el código está allí cuando no debería, el costo de mantenimiento se ha multiplicado muchas veces (ya que el "error" será descubierto en la producción o por el cliente, en el peor lugar o momento).

La idea de permitir que el historial de control de fuentes ilustre la "forma antigua" de hacer algo en lugar de comentarlo y verificar el comentario junto con una explicación es una buena idea en teoría.

En el mundo real, sin embargo, nadie mira el historial de control de código fuente de los archivos en los que está trabajando, a menos que sea parte de un proceso de revisión oficial de algún tipo (hecho solo periódicamente), o si algo no funciona, y el desarrollador no puedo entender por qué.

Incluso entonces, mirar hacia atrás más de aproximadamente 3 versiones básicamente nunca sucede.

En parte, esto se debe a que los sistemas de control de fuentes no facilitan este tipo de revisión casual. Por lo general, debe comparar una versión anterior o una diferencia con una versión anterior, solo ve dos versiones y no hay una buena vista concisa de lo que cambió que pueda darle una idea de un vistazo de lo que cambió.

En parte, es la combinación de la naturaleza humana y las necesidades del equipo. Si tengo que arreglar algo y puedo arreglarlo en unas pocas horas, no es probable que dedique una hora a investigar versiones antiguas del código que no han estado "activas" en un mes (lo cual, con cada desarrollador comprobando a menudo, significa retroceder muchas revisiones), a menos que sepa que hay algo allí (como si recuerdo una discusión sobre cambiar algo relacionado con lo que estoy haciendo ahora).

Si el código se elimina y se vuelve a registrar, entonces, para todos los efectos (excepto para el propósito limitado de una reversión completa) deja de existir. Sí, está ahí para realizar copias de seguridad, pero sin una persona en el papel de bibliotecario de código, se perderá.

Mi árbol de control de código fuente en mi proyecto actual tiene alrededor de 10 semanas, en un equipo de solo alrededor de 4 ingenieros, y hay alrededor de 200 listas de cambios comprometidas. Sé que mi equipo no hace un trabajo tan bueno como debería de registrarse tan pronto como hay algo sólido y listo para comenzar. Eso hace que sea bastante difícil confiar en la lectura del historial del código de cada parte del código para detectar cada cambio importante.

En este momento, estoy trabajando en un proyecto en modo de desarrollo inicial, que es muy diferente de un proyecto en modo de mantenimiento. Muchas de las mismas herramientas se utilizan en ambos entornos, pero las necesidades difieren bastante. Por ejemplo, a menudo hay una tarea que requiere que dos o más ingenieros trabajen en estrecha colaboración para construir algo (digamos un cliente y un servidor de algún tipo).

Si estoy escribiendo el servidor, podría escribir el código para el borrador de la interfaz que usará el cliente y verificar que no sea funcional, para que el ingeniero que escribe el cliente pueda actualizar. Esto se debe a que tenemos la política que dice que la única forma de enviar código de un ingeniero a otro es a través del sistema de control de fuente.

Si la tarea va a tardar lo suficiente, valdría la pena crear una rama para que trabajemos los dos (aunque eso va en contra de la política de mi organización: los ingenieros y los líderes de equipos individuales no tienen los permisos necesarios en el servidor de control de fuente). En última instancia, es una compensación, por lo que tratamos de no instituir demasiadas políticas de "siempre" o "nunca".

Probablemente respondería a una política de no comentar código nunca diciendo que fue un poco ingenua. Bien intencionado, quizás, pero en última instancia, es poco probable que logre su propósito.

Aunque ver esta publicación hará que vuelva a revisar el código que verifiqué la semana pasada y eliminar la parte comentada que nunca fue definitiva (aunque funcionó) y que probablemente nunca volverá a ser deseada.

Creo que el código comentado se considera "desperdicio".

Supongo que está trabajando en un entorno de equipo. Si está trabajando por su cuenta y comenta el código con un 'todo' y volverá a él, entonces eso es diferente. Pero en un entorno de equipo, puede asumir con seguridad que una vez que se comprueba el código comentado, está ahí para quedarse y lo más probable es que cause más dolor que satisfacción.

Si está haciendo revisiones de código entre pares, entonces podría responder a su pregunta. Si otro desarrollador revisa su código y dice "¿por qué hay este código comentado que está tratando de hacer 'blah'", entonces su código no pasó la revisión del código y no debería verificarlo de todos modos?

El código comentado solo generará preguntas con otros desarrolladores, por lo que perderá tiempo y energía.

Debe hacer la pregunta " por qué " el código está comentado. Algunas sugerencias:

Si está comentando el código porque "no está seguro de las reglas de negocio", entonces probablemente tenga un problema con el "alcance progresivo". Es mejor no ensuciar su base de código con requisitos que "sería bueno tener pero no tenemos tiempo. to implement "- manténgalo limpio con código claro y pruebas sobre lo que realmente está allí.

Si está comentando el código porque "no está seguro de si es la mejor manera de hacerlo", ¡haga que revisen su código por pares! Los tiempos están cambiando, verás el código que escribes hoy en 2 años y pensarás que es horrible. Pero no puedes andar comentando partes que "sabes" que se pueden hacer mejor, pero simplemente no puedes encontrar la manera en este momento. Deje que quien mantenga el código base a largo plazo determine si hay una mejor manera: simplemente escriba, pruebe y funcione el código y continúe.

Si está comentando el código porque "algo no funciona", ¡ ARREGLO ! Un escenario común es "pruebas rotas" o "tareas pendientes" . Si tiene estos, se ahorrará mucho tiempo ya sea reparándolos o simplemente eliminándolos. Si se pueden "romper" durante un período de tiempo, lo más probable es que se rompan para siempre.

Todos estos escenarios potenciales (y los que no he mencionado aquí) son una pérdida de tiempo y esfuerzo. El código comentado puede parecer un problema pequeño, pero podría ser un indicador de un problema mayor en su equipo.

Los repositorios son una copia de seguridad del código. Si estoy trabajando en el código pero no está completo, ¿por qué no comentarlo y revisarlo al final del día? De esa forma, si mi disco duro muere de la noche a la mañana, no habré perdido ningún trabajo. Puedo revisar el código por la mañana, descomentarlo y continuar.

La única razón por la que lo comentaría es porque no quisiera romper la construcción de la noche a la mañana.

Es evidente que existe una tensión entre 1) realizar el check-in temprano y 2) mantener siempre el repositorio en un estado de funcionamiento. Si tiene más de unos pocos desarrolladores, este último tendrá una prioridad cada vez mayor, porque no puede tener un desarrollador cagando sobre todos los demás para su propio flujo de trabajo personal. Dicho esto , no debe subestimar el valor de la primera pauta. Los desarrolladores utilizan todo tipo de vallas mentales, y los flujos de trabajo individualizados son una forma en que los grandes desarrolladores exprimen esas X adicionales. Como gerente, su trabajo no es tratar de comprender todos estos matices, en los que fallará a menos que sea un genio y todos sus desarrolladores sean idiotas, sino más bien permitir que sus desarrolladores sean lo mejor que puedan a través de su propia toma de decisiones.

Mencionas en el comentario que no usas ramas privadas. Mi pregunta para ti es ¿por qué no? Bien, no sé nada sobre TFS, así que tal vez haya buenas razones. Sin embargo, después de usar git durante un año, debo decir que un buen DVCS disipa totalmente esta tensión. Hay casos en los que me parece útil comentar el código mientras estoy construyendo un reemplazo, pero perderé el sueño si se lo estoy aplicando a otros. Ser capaz de bifurcar localmente significa que puedo mantener confirmaciones significativas para mi proceso individual sin tener que preocuparme (o incluso notificar) a los desarrolladores posteriores de los problemas temporales.

Haciendo eco del coro. Desaliente esto a toda costa. Hace que el código sea más difícil de leer y deja a la gente preguntándose qué hay de bueno / malo en ese código que ni siquiera forma parte de la aplicación en este momento. Siempre puede encontrar cambios comparando revisiones. Si hubo alguna cirugía mayor y el código fue comentado en masa, el desarrollador debería haberlo anotado en las notas de revisión sobre checkin / merge.

El código incompleto / experimental debe estar en una rama para ser desarrollado hasta su finalización. el encabezado / tronco debe ser la línea principal que siempre compila y es lo que se envía. una vez que la rama experimental esté completa / aceptada, debe fusionarse en la línea principal / principal. Incluso hay un estándar IEEE (IEEE 1042) que describe esto si necesita documentación de soporte.

Preferiría ver un código accesible, posiblemente roto, que no se esté utilizando aún y que el mismo código no esté completamente disponible. Dado que todo el software de control de versiones permite algún tipo de "copia de trabajo" separada del tronco, es realmente una idea mucho mejor utilizar esas funciones.

El código nuevo y no funcional está bien en el maletero, porque es nuevo. Probablemente no rompa nada que ya funcione. Si rompe el código de trabajo, entonces debería ir en una rama, para que otros desarrolladores puedan (si es necesario) verificar esa rama y ver qué está roto.

" Scar Tissue " es lo que yo llamo código comentado. En los días previos al uso generalizado de los sistemas de control de versiones, Code Monkeys dejaba el código comentado en el archivo en caso de que necesitaran revertir la funcionalidad.

El único momento en que es aceptable registrar el "tejido cicatricial" es

1. Si tiene una sucursal privada y
2. No tiene tiempo para compilar el código sin errores y
3. Te vas de vacaciones largas y
4. No confía en su VCS, como si usa Visual Source Safe OR .
   [EDITAR]
5. Tiene un error sutil que podría reintroducirse si no se deja el código incorrecto como recordatorio. (buen punto de otras respuestas).

Casi no hay excusa para el n. ° 4 porque hay muchos sistemas VCS robustos y disponibles gratuitamente, siendo Git el mejor ejemplo .

De lo contrario, deje que VCS sea su archivo y distribuidor de código. Si otro desarrollador quiere ver tu código, envíale un correo electrónico con las diferencias y deja que aplique lo que quiera directamente. En cualquier caso, a la fusión no le importa por qué o cómo divergió la codificación de dos archivos.

Debido a que es un código, el tejido cicatricial puede distraer más incluso que un comentario bien escrito. Por su propia naturaleza como código, usted hace que el programador de mantenimiento gaste ciclos mentales de la CPU averiguando si el tejido cicatricial tiene algo que ver con sus cambios. No importa si la cicatriz tiene una semana o 10 años, dejar tejido cicatricial en el código impone una carga a quienes deben descifrar las palabras posteriores del código.

[EDITAR] Agregaría que hay dos escenarios principales que deben distinguirse:

• desarrollo privado, ya sea codificando un proyecto personal o registrándose en una sucursal privada
• Desarrollo de mantenimiento, donde se pretende poner en producción el código que se está registrando.

¡Solo di "NO" al tejido cicatricial!

No lo sé, siempre comento las líneas originales antes de hacer cambios, me ayuda a revertirlas si cambio de opinión. Y sí, los registro.

Sin embargo, elimino cualquier código antiguo comentado del registro anterior.

Sé que podría mirar los registros de diferencias para ver qué ha cambiado, pero es una molestia, es bueno ver los últimos cambios allí mismo en el código.

Un buen compromiso es escribir una pequeña herramienta que vuelque sus archivos extraídos / modificados en una unidad de respaldo de red. De esa manera, puede modificar hasta el contenido de su corazón y hacer una copia de seguridad de su trabajo, pero nunca tendrá que verificar el código experimental o sin terminar.

Creo que registrar el código comentado debería ser válido ya que, solo porque el nuevo cambio pasó las pruebas, puede ser más útil ver qué había antes y ver si el nuevo cambio es realmente una mejora.

Si tengo que retroceder varias versiones para ver un cambio anterior que ahora conduce a un impacto en el rendimiento, sería muy molesto.

A veces, el código comentado es un buen historial, pero ponga fechas en cuanto a cuándo se comentó el código. Más tarde, alguien que esté trabajando cerca de allí puede simplemente eliminar el código comentado, ya que se ha demostrado que no es necesario.

También sería bueno saber quién comentó ese código para que, si se necesita alguna justificación, se les pueda preguntar.

Prefiero escribir una nueva funcionalidad, asegurarme de que las pruebas unitarias pasen, verificarlo, luego permitir que otros lo usen y ver cómo funciona.

Si el desarrollador ha comentado algún código porque aún no está completo, entonces la forma correcta de "control de código fuente" para lidiar con esto sería que ese desarrollador lo mantenga en una rama separada de él, hasta que ese código esté listo para verificar. en.

Con un DVCS (como git, bazaar o mercurial) esto es muy fácil ya que no requiere cambios en el repositorio central. De lo contrario, quizás podría hablar de darles a los desarrolladores sus propias ramas en el servidor si están trabajando en funciones específicas que les llevarán bastante tiempo (es decir, días).

No hay nada de malo en registrar el código comentado en algunas situaciones, es solo que esta es una situación en la que puede haber una mejor manera de hacerlo, por lo que el desarrollador puede rastrear los cambios en su fuente aunque no esté listo para ser registrado en el repositorio principal.

Claramente, el desarrollador que está registrando el código comentado debería estar trabajando en una rama separada, fusionando los cambios de la rama troncal según sea necesario.

Depende del sistema VCS ayudar al desarrollador en este flujo de trabajo (git es un excelente sistema VCS que funciona muy bien con esto).