Comprobación del código "comentado"

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 nuevo concepto aquí y he elaborado un primer borrador de algunas pautas de encoding.

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

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

Queremos llegar a un punto en el que aprovechemos al máximo la continuous integration y la implementación automática de un server web de desarrollo. Actualmente no hay una versión de desarrollo de serveres web o serveres de bases de datos, pero eso se cambiará pronto.

De todos modos, ¿cuáles son tus pensamientos? ¿Crees que el código "comentado" es útil para tener en el repository?

Estoy muy interesado en escuchar a otros sobre este tema.

Editar: para mayor claridad, no usamos twigs privadas. Si lo hiciéramos, diría que hagas lo que quieras con tu sucursal privada, pero nunca fusiones el código comentado con el tronco o las twigs compartidas.

Editar: no existe una razón válida por la que no usemos twigs privadas o por usuario. No es un concepto con el que no estoy de acuerdo. Simplemente no lo hemos configurado de esa manera todavía. Quizás ese sea el punto medio eventual. Por ahora usamos estanterías TFS.

Puede haber otros con diferentes experiencias, pero en la comprobación de minas en código a medio terminar es una idea horrible, punto.

Aquí están los principios que he aprendido y trato de seguir:

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

Esto significa:

  • El código comentado no se debe registrar nunca porque no es funcional
  • Comentar no es una estrategia de file válida, por lo tanto, si el código aún no se ha terminado o el código que se va a eliminar, comentar y realizar el check-in 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 enviarse a una sucursal 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 de todos modos). Lo que diré es que debe hacer que todos en su equipo acepten la filosofía que describí anteriormente. El equipo en el que trabajo lo abraza de todo corazón. Como resultado, el control de fuente es un miembro del equipo sin errores, uno que nos ayuda a hacer nuestro trabajo.

Las personas que no adoptan esa filosofía generalmente causan windows rotas y, a menudo, se sienten frustradas por el control de la fuente. Ellos lo ven como un mal necesario en el mejor de los casos, y algo para evitar en el peor; lo que conduce a checkins poco frecuentes, lo que significa que los sets de cambios son enormes y difíciles de fusionar, lo que aumenta la frustración, hace que los checkins sean algo para evitar aún más, etc. Esto es en última instancia una actitud, en realidad no es un process. Es fácil poner barreras mentales contra eso; 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 la gente quiere hacerlo y se compromete a cambiar sus hábitos, los resultados son dramáticos. La carga está en ti 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 marcar el código que está comentado: cuando está incompleto y puede interrumpir la aplicación si está registrado mientras está activo.

En su mayor parte, comentar un código muerto es innecesario en un sistema controlado por cambios bien administrado. Pero, no todos los códigos comentados están "muertos".

Un caso donde dejo 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 repository lo tendría pero el repository no advertiría a nadie en el futuro que no siga por ese path.

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

La gente está hablando muchos ideales aquí. Tal vez a diferencia de todos los demás, tengo que trabajar en múltiples proyectos con múltiples interrupciones con el "mundo real" que ocasionalmente interrumpió mi jornada laboral.

A veces, la realidad es que tengo que registrar el código parcialmente completo. Se corre el riesgo de perder el código o de registrarse en el código incompleto. No siempre puedo permitirme "terminar" una tarea, sin importar cuán pequeña sea. Pero no desconectaré mi computadora portátil de la networking sin registrar todo el código.

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

Ciertamente, desalentaría, enérgicamente, revisar código comentado. Sin embargo, no lo prohibiría del todo. Algunas veces (si es raro) es apropiado verificar el código comentado en el control de la 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 la fuente
  • Nunca verifique el código roto (que no funciona) en el control de fuente, al less nunca en el enlace troncal y solo muy raramente a una sucursal privada, YMMV
  • Si ha comentado temporalmente algo o ha roto algo con fines de debugging, no verifique el código hasta que restablezca el código en 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 documentation de lo que viene después, o un fragment muy corto (idealmente 1 línea) de comentarios. código que muestra algo que nunca debe volver a agregarse. El código comentado debe SIEMPRE ir acompañado de un comentario que diga por qué está comentado (y no solo eliminado) y da la vida 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 mejor solución. Después de entregar la revisión, el código comentado es un recordatorio de que todavía tiene algo que debe solucionar.

¿Cuándo ingreso el código comentado? Un ejemplo es cuando estoy tentativamente eliminando algo que creo que hay una alta probabilidad tendrá que volver a agregarse en el futuro cercano, de alguna forma. El código comentado está ahí para servir como un recordatorio directo de que esto está incompleto. Claro, la versión anterior está en control de fuente y podría usar un comentario de FIXME como indicador 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 solo comento la línea con un comentario para nunca volver a habilitar ese código con una razón por la cual. Este tipo de comentario es claro, directo y conciso.

Rex M dijo: 1) Verificar solo la funcionalidad completa, 2) [Si] la tarea es demasiado grande, dividirla en tareas más pequeñas y completables.

En respuesta: Sí, este es el ideal. Algunas veces, ninguna de las dos opciones se puede lograr cuando trabajas en el código de producción y tienes un problema inmediato y crítico que corregir. A veces, para completar una tarea, necesita poner una versión de código en el campo por un time. Esto es especialmente cierto para los cambios en el código de recostackció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é revisando el código comentado en una twig privada que nadie verá, sino ese desarrollador (y tal vez alguien con quien el desarrollador queuebora), hace poco daño. Pero ese desarrollador debería (casi) nunca entregar dicho código en trunk o un equivalente. El tronco siempre debe build y siempre debe funcionar. Entregar código sin terminar al trunk es casi siempre una muy mala idea. Si permite que un desarrollador verifique código sin terminar o temporal en una sucursal privada, entonces tiene que confiar en que el desarrollador no se olvide de borrar el código antes de entregarlo en el enlace troncal.

Para aclarar en respuesta a los comentarios a otras respuestas, si el código está comentado y registrado, mi expectativa de que el código funcionará si no está comentado se networkinguce con el time que el código ha sido comentado. Obviamente, las herramientas de refactorización no siempre includeá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, que algo debe hacerse allí. No es algo que debería tener una vida larga.

Finalmente, si puede encontrar el código comentado en cada file fuente, entonces algo está mal. Entregar código descompuesto en el enlace por cualquier motivo debería ser un evento raro. Si esto ocurre a menudo, entonces se convierte en desorder y pierde su valor.

Creo que nunca es una condición demasiado fuerte.

Tiendo a comentar, registrar, ejecutar las testings, pensar y luego eliminar los comentarios después del próximo lanzamiento.

En general, verificar el código comentado es incorrecto ya que crea confusión entre aquellos que no son el autor original y necesitan leer o modificar el código. En cualquier caso, el autor original a menudo termina confundido sobre el 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. Verificar el código comentado sin agregar un comentario sobre por qué se conserva 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 es por eso que he hecho esto. No siento ninguna necesidad de justificarte a ti, ni a nadie más, por qué he hecho esto.

Para mí, el código comentado se considera normalmente como un signo de falta de respeto por parte de un compañero de trabajo less considerado.

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

El próximo desarrollador que vea el código comentado no tendrá idea de que se trata de un trabajo en progreso. ¿Es libre de cambiarlo? ¿Es un código muerto? Él no 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.

"Verificando cambios parciales que pueden o no implementarse", ¿presumiblemente eso también significa que puede o no ser probado? Esa es una pendiente resbaladiza a una base de código muy sobrio.

Cuando necesites agregar una característica pequeña o corrección de errores como AHORA, dentro de los próximos 3 minutos y tienes que arreglar un file tienes un código medio desarrollado, yo diría que está bien, las necesidades prácticas gobiernan sobre ideales pragmáticos en el campo de batalla.

Esto muestra una diferencia fundamental en dos escuelas de pensamiento: aquellas que solo verifican el código de trabajo con el que están satisdates y sienten que vale la pena ahorrar, y las que controlan su trabajo para que el control de revisión esté allí para respaldarlas contra la pérdida de datos.

Me gustaría calificar a este último como "aquellos a los que les gusta usar su sistema de control de revisión como una copy de security en cinta de un hombre pobre", pero eso me estaría volviendo loco en cuanto a en qué campamento estoy. 🙂

Supongo que eres del campo de "código bueno" y él pertenece al campo de "códigos de trabajo".

[EDITAR]

De los comentarios, sí, lo acerté.

Como dije, estoy contigo, pero por lo que puedo decir, esta es una opinión minoritaria, tanto aquí en stackoverflow como en mi 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 los estándares se sigan de todos modos. Una cosa que un buen líder sabe es nunca dar una order que ellos saben que no se seguirá.

BTW: buenos editores ayudarán a mantener versiones antiguas. Por ejemplo, en Emacs establecí las versiones guardadas antiguas y las versiones antiguas guardadas en 10, lo cual hace que guarde las últimas 10 copys de mis files. Puede considerar esto como una forma de ayudar a su argumento en contra de la multitud de revisión-control-como-respaldo. Sin embargo, nunca ganarás la discusión.

En mi experiencia, los conmutadores de desarrollador tienen un código comentado.

A veces, los back-ends nuevos se crean en paralelo, con los conmutadores de activación comentados en el control de la fuente.

Alguna característica extraña que necesitamos una vez en una luna azul, pero que ningún cliente necesitará, a menudo se implementa de esa manera. Por lo general, estas cosas conllevan un alto riesgo de omisión de security o integridad de datos, por lo que no queremos que estén activas fuera del desarrollo. Requerir que un desarrollador lo use para descomentar el código primero parece ser la forma más fácil de getlo.

Otra razón para código comentado check out:

Está modificando el código existente y encontró un error sutil, uno que es fácil pasar por alto, y que tal vez incluso podría parecer correcto a primera vista. Coméntelo, coloque la corrección en su lugar y agregue comentarios sobre lo que está sucediendo y por qué se modificó. Verifique eso, para que sus comentarios sobre la solución estén en el repository.

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

Esta práctica parece ser contradictoria con su objective declarado de implementar la continuous integration.

Depende. Si se deja allí para fines de ilustración, tal vez. Posiblemente podría ser útil durante la refactorización. De lo contrario, y en general, no. Además, comentar el código sin terminar es propenso a fallas y a un sumidero de time. Mejor rompe el código en pedazos más pequeños y los registra cuando trabajan.

Mi punto de vista: si los desarrolladores están trabajando en sus propias sucursales o en su propia área de espacio aislado, entonces deberían poder verificar lo que quieran. Es cuando verifican el código en una twig compartida (una twig de características, o una twig de un equipo, o por supuesto PRINCIPAL / troncal) que el código debe ser tan prístino como sea posible (sin código comentado, no más FIXME, etc.).

Creo que "Nunca" es una regla demasiado fuerte. Yo votaría para dejar algún margen de acción personal sobre si las personas verifican el código comentado en el repository. El objective final debería ser la productividad del codificador, no "un depósito prístino".

Para equilibrar esa relajación, asegúrese de que todos sepan que el código comentado tiene una date de vencimiento. Cualquiera puede eliminar el código comentado si ha estado presente durante una semana completa y nunca ha estado activo. (Reemplace "a la semana" con lo que sea adecuado para usted.) De esta forma, se reserva el derecho de eliminar el desorder cuando lo ve, sin interferir demasiado directamente con los styles personales de las personas.

Estoy absolutamente de acuerdo con que el código comentado no se debe verificar en el repository, para eso sirve el control del código fuente.

En mi experiencia, cuando un progtwigdor comtesting el código comentado, es porque no está seguro de cuál es la solución correcta y es más feliz dejando 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 hace que sea difícil de leer.

No tengo problemas para verificar el código a medio terminar (para que obtenga el beneficio del control de fuente) que no es invocado 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 el código comentado de comprobación en un sistema de control de código fuente debe hacerse con extrema precaución, especialmente si las tags 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 diff / merge que está utilizando. Con cierto sistema de control de código fuente y cierto lenguaje, la herramienta diff / merge se puede confundir fácilmente. La diferencia / fusión estándar de ClearCase, por ejemplo, es notoriamente mala para fusionar files .xml.

Si sucede que las líneas de bloques de comentarios no se fusionan correctamente, el código se activará en el sistema cuando no debería. Si el código está incompleto y rompe la construcción, probablemente sea el less malo, ya que lo detectarás inmediatamente.

Pero si el código pasa la construcción, puede activarse cuando no debería estar allí, y desde la perspectiva del CM, podría ser un escenario de pesadilla. QA generalmente testing qué debería haber allí, no testing el código que se supone que no está allí, por lo que su código puede terminar en producción antes de que usted lo sepa, y para cuando se realice el código estará allí cuando no debería, el costo de mantenimiento se ha multiplicado por muchos pliegues (ya que el "error" se descubrirá en la producción o por el cliente, el peor lugar o el peor momento).

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

Asumo que estás trabajando en un ambiente de equipo. Si trabajas por tu count, y comentas el código con un 'todo' y volverás a él, entonces eso es diferente. Pero en un entorno de equipo, puede suponer con security que una vez que se ha verificado el código comentado, está allí para quedarse y lo más probable es que cause más dolor que satisfacción.

Si está haciendo revisiones de código de pares, entonces podría responder su pregunta. Si otro desarrollador revisa tu código y dice "¿por qué hay este código comentado que está intentando hacer blah?", Entonces tu código ha fallado en la revisión del código y no deberías registrarlo de todos modos.

El código comentado solo generará preguntas con otros desarrolladores, por lo tanto, perderá time 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 comerciales", entonces probablemente tenga un problema con "scope creep": lo mejor es no ensuciar su código base con requisitos que "sería bueno tener pero no tenemos time". para implementar "- mantenerlo limpio con un código claro y testings de lo que realmente está allí.

Si está comentando el código porque "no está seguro de si es la mejor manera de hacerlo", ¡haga revisar su código por pares! Los times están cambiando, verás el código que escribes hoy en 2 años y ¡piensas que es horrible! Pero no puedes andar comentando cosas que "sabes" que se pueden hacer mejor, pero no puedes encontrar la manera ahora mismo. Deje que quienquiera que mantenga la base de código a largo ploop determine si hay una mejor manera: simplemente obtenga el código escrito, probado y funcionando, y continúe.

Si está comentando el código porque "algo no funciona", ¡ CORREGELO ! Un escenario común es "testings rotas" o "tareas pendientes" . Si tiene estos, ahorrará mucho time a los suyos ya sea corrigiéndolos o librándose de ellos. Si pueden "romperse" por un período de time, lo más probable es que se rompan para siempre.

Todos estos posibles escenarios (y los que no he mencionado aquí) son un desperdicio de time y esfuerzo. El código comentado podría parecer un problema pequeño, pero podría ser un indicador de un problema mayor en su equipo.

Los repositorys son copys de security del código. Si estoy trabajando en el código pero no está completo, ¿por qué no comentarlo y registrarlo al final del día? De esa manera, si mi disco duro muere durante la noche, no habrá perdido ningún trabajo. Puedo ver el código en la mañana descomentarlo y continuar.

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

Claramente, hay una tensión entre 1) registrarme temprano, y 2) mantener siempre el repository en un estado de trabajo. Si tiene más de unos pocos desarrolladores, este último tendrá una mayor prioridad, porque no puede tener un desarrollador que critica a todos los demás por su propio flujo de trabajo personal. Dicho esto , no debe subestimar el valor de la primera directriz. Los desarrolladores usan todos los diferentes types de postes de cercas mentales, y los flujos de trabajo individualizados son una de las forms en que los grandes desarrolladores exprimen esas X adicionales. Como gerente, tu trabajo no es tratar de comprender todos estos matices -al que fallarás a less que seas un genio y todos tus desarrolladores sean idiotas- sino que habilites a tus desarrolladores para que sean lo mejor que puedan a través de su propia toma de decisiones.

Menciona en el comentario que no usa twigs privadas. Mi pregunta para ti es por qué no? De acuerdo, no sé nada sobre TFS, así que tal vez haya buenas razones. Sin embargo, después de usar git por un año, debo decir que un buen DVCS difunde por completo esta tensión. Hay casos en los que encuentro que el código de comentarios es útil ya que estoy creando un reemploop, pero perderé el sueño si lo inflico a otros. Ser capaz de realizar una bifurcación local significa que puedo mantener compromisos significativos para mi process individual sin tener que preocuparme (o incluso notificar) a los desarrolladores posteriores de problemas temporales.

Solo 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é es lo bueno / malo de 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 notado en las notas de revisión sobre checkin / merge.

El código incompleto / experimental debe estar en una twig que se desarrollará hasta su finalización. la cabeza / tronco debe ser la línea principal que siempre se comstack y cuál es el envío. una vez que la twig experimental está completa / aceptada, debe fusionarse en la cabecera / línea principal. Incluso hay un estándar IEEE (IEEE 1042) que describe esto si necesita documentation de soporte.

Preferiría que el código posiblemente interrumpido y accesible que no se está utilizando pero se haya registrado en el mismo código no esté disponible por completo. Dado que todo el software de control de versiones permite algún tipo de 'copy de trabajo' separada del tronco, en realidad es una idea mucho mejor usar esas características.

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

" Scar Tissue " is what I call commented-out code. In the days before the widespread use of version-control systems, Code Monkeys would leave commented out code in the file in case they needed to revert functionality.

The only time it is acceptable to check-in "scar tissue" is

  1. If you have a private branch and
  2. You don't have time to make the code compile without errors and
  3. You are going on a long vacation and
  4. You don't trust your VCS, like if you use Visual Source Safe OR .
    [EDITAR]
  5. You have a subtle bug that might be reintroduced if the incorrect code isn't left in as a reminder. (good point from other answers).

There is almost no excuse for #4 because there are plenty of freely available and robust VCS systems around, Git being the best example .

Otherwise, just let the VCS be your archive and code distributor. If another developer wants to look at your code, email him the diffs and let him apply the stuff he wants directly. In any event, the merge doesn't care why or how the coding of two files diverged.

Because it is code, scar-tissue can be more distracting even than a well-written comment. By its very nature as code, you make the maintenance programmer expend mental cpu-cycles figuring out if the scar-tissue has anything to do with his changes. It doesn't matter whether the scar is a week old or 10 years old, leaving scar-tissue in code imposes a burden upon those who must decypher the code afterwords.

[EDIT] I'd add that there are two major scenarios that need to be distinguished:

  • private development, either coding a personal project or checking in to a private branch
  • Maintenance development, where the code being checked in is intended to be put into production.

Just say "NO" to scar-tissue!

The idea of allowing source-control history to illustrate the "old way" of doing something rather than commenting it out and checking in the commenting-out along with an explanation is a good idea in theory.

In the real world, however, nobody ever looks at source control history on the files they are working on unless it is part of an official review process of some sort (done only periodically), or if something doesn't work, and the developer can't figure out why.

Even then, looking back more than about 3 versions basically never happens.

Partially, this is because source-control systems don't make this sort of casual review easy. Usually you have to check out an old version or diff against an old version, you just see two versions, and there's no good concise view of what changed that can give you an at-a-glance idea of what changed.

Partially, it is the combination of human nature and the needs of the team. If I have to fix something, and I can fix it in a few hours, I'm not likely to spend an hour investigating old versions of the code that haven't been "live" in a month (which, with each developer checking in often, means back many revisions), unless I happen to know that there's something in there (such as if I remember a discussion about changing something related to what I'm doing now).

If the code is deleted and checked back in, then, for all intents and purposes (except for the limited purpose of a complete roll-back) it ceases to exist. Yes, it is there for backup purposes, but without a person in the role of code librarian, it is going to get lost.

My source control tree on my current project is about 10 weeks old, on a team of only about 4 engineers, and there are about 200 committed change lists. I know that my team does not do as good of a job as it should of checking in as soon as there is something solid and ready to go. That makes it pretty rough to rely on reading the code history for every part of the code to catch every important change.

Right now, I'm working on a project in initial development mode, which is very different from a project in a maintenance mode. Many of the same tools are used in both environments, but the needs differ quite a bit. For example, often there is a task that requires two or more engineers to work somewhat closely together to build something (say a client and a server of some sort).

If I'm writing the server, I might write up the code for the draft interface that the client will use and check it in completely non-functional, so that the engineer writing the client can update. This is because we have the policy that says that the only way to send code from one engineer to another is through the source control system.

If the task is going to take long enough, it would be worth creating a branch perhaps for the two of us to work on (though that is against policy in my organization — engineers and individual team leads don't have the necessary permissions on the source-control server). Ultimately, its a trade-off, which is why we try not to institute too many "always" or "never" policies.

I would probably respond to such a no-commented-code-ever policy by saying that it was a bit naive. Well-intentioned, perhaps, but ultimately unlikely to achieve its purpose.

Though seeing this post is going to make be go back through the code I checked in last week and remove the commented-out portion that was both never final (though it worked) and also never likely to be desinetworking again.

I don't know – I always comment out the original lines before I make changes – it helps me revert them back if I change my mind. And yes I do check them in.

I do however strip out any old commented code from the previous check-in.

I know I could look at the diff logs to see what's changed but it's a pain – it's nice to see the last changes right there in the code.

A nice compromise is to write a little tool that dumps your checked out/modified files to a network backup drive. That way, you can modify til your heart's content and have your work backed up, but you never have to check in experimental or unfinished code.

I think that checking in commented out code should be valid as, just because the new change passed tests it may be more helpful to see what was there before and see if the new change is really an improvement.

If I have to go back several versions to see an earlier change that now leads to a performance hit then that would be very annoying.

Sometimes the commented out code is a good history, but, put dates as to when the code was commented out. Later, someone that is working near there can just delete the commented out code as it has been proven not to be needed.

It would also be good to know who commented out that code so that if some rationale is needed then they can be asked.

I prefer to write new functionality, ensure the unit tests pass, check it in, then allow others to use it and see how it works.

If the developer has commented out some code because it is not yet complete, then the correct "source control" way to deal with this would be for that developer to keep it in a separate branch of his own, until that code is ready to check in.

With a DVCS (like git, bazaar, or mercurial) this is dead easy as it requires no changes in the central repository. Otherwise, perhaps you could talk about giving developers their own branches on the server if they are working on specific features that will take them a long enough time (ie, days).

There is nothing wrong with checking in commented out code in some situations, it's just that this is one situation where there may be a better way to do it, so the developer can track changes to his source even though it isn't ready to be checked in to the main repository.

Clearly, the developer who is checking in commented-out code should be working in a separate branch, merging in changes from the trunk branch as neccessary.

It is up to the VCS system to assist the developer in this workflow (git is one excellent VCS system that works with this very nicely).