version control - tool - Comprobación del código "comentado"

version control team foundation server (30)

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 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 porque el repositorio mantiene un historial completo de los archivos. Si está eliminando el código funcional, elimínelo por completo. El repositorio 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.

Finalmente, queremos llegar a un punto en el que aprovechemos 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 eso se cambiará pronto.

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

Estoy muy interesado en escuchar a otros sobre este tema.

Editar: para mayor claridad, no usamos ramas 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 ramas compartidas.

Editar: no existe una razón válida por la que no usemos ramas 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.

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

Su colega tiene un excelente 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".

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 menos 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 depuración, 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 gradual pero incompleta que incluye una pequeña cantidad de código comentado como documentación de lo que viene después, o un fragmento 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. A veces, ninguna de las dos opciones se puede lograr cuando se trabaja en el código de producción y se soluciona un problema inmediato y crítico. A veces, para completar una tarea, necesita poner una versión de código en el campo por 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é revisando el código comentado en una rama privada que nadie verá, sino ese desarrollador (y tal vez alguien con quien el desarrollador colabora), hace poco daño. Pero ese desarrollador debería (casi) nunca entregar dicho código en trunk o un equivalente. El tronco siempre debe construir 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 reduce 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, 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 archivo 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 desorden y pierde su valor.

Claramente, hay una tensión entre 1) registrarme temprano, y 2) mantener siempre el repositorio 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 tipos de postes de cercas mentales, y los flujos de trabajo individualizados son una de las formas 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 menos 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 ramas 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 reemplazo, 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 proceso individual sin tener que preocuparme (o incluso notificar) a los desarrolladores posteriores de problemas temporales.

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 repositorio. El objetivo 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 fecha 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 desorden cuando lo ve, sin interferir demasiado directamente con los estilos personales de las personas.

Creo que nunca es una condición demasiado fuerte.

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

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 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 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 archivos .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 menos 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 prueba qué debería haber allí, no prueba 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 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 cuenta, 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 seguridad 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á 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 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 tiempo". para implementar "- mantenerlo limpio con un código claro y pruebas 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 tiempos 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 plazo 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 "pruebas rotas" o "tareas pendientes" . Si tiene estos, ahorrará mucho tiempo a los suyos ya sea corrigiéndolos o librándose de ellos. Si pueden "romperse" por un período de tiempo, 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 tiempo 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.

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 archivo 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.

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 inconveniente de tiempo. Mejor rompe el código en pedazos más pequeños y los registra cuando trabajan.

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 red sin registrar todo el código.

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

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 equipo, y que es su responsabilidad facilitar las cosas para 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 menos considerado.

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 seguridad 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 obtenerlo.

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 sienten que vale la pena ahorrar, y aquellos que controlan su trabajo para que el control de revisión esté allí para respaldarlos 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 copia de seguridad 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 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 orden 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 copias de mis archivos. 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.

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

En mi experiencia, cuando un programador comprueba 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.

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.

Los repositorios son copias de seguridad 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.

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 rama compartida (una rama de características, o una rama 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.).

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 repositorio.

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 menos 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 archivo 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 ventanas 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 conjuntos 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 proceso. 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.

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 objetivo declarado de implementar la integración continua.

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 rama que se desarrollará hasta su finalización. la cabeza / tronco debe ser la línea principal que siempre se compila y cuál es el envío. una vez que la rama 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 documentación de soporte.

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 repositorio lo tendría pero el repositorio no advertiría a nadie en el futuro que no siga por ese camino.

" 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

If you have a private branch and
You don''t have time to make the code compile without errors and
You are going on a long vacation and
You don''t trust your VCS, like if you use Visual Source Safe OR .
[EDITAR]
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!

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.

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.

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

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.

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.

I would prefer to see possibly broken, accessible code that isn''t being used yet checked in over the same code being completely unavailable. Since all version control software allows some sort of ''working copy'' separate from the trunk, it''s really a much better idea to use those features instead.

New, non-functional code is fine in the trunk, because it is new. It probably doesn''t break anything that already works. If it does break working code, then it should just go in a branch, so that other developers can (if they need to) check that branch out, and see what''s broken.

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.

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 desired again.