Dos casos generales:

De un proyecto a otro:

La mayoría de los programadores cortan y pegan código en esta capacidad. Pueden encontrar un proyecto anterior o algo en línea y copiarlo / pegarlo exactamente o copiarlo / pegarlo y hacer cambios en él. Creo que esta práctica suele ser buena. Esto es especialmente bueno cuando está probado el código. (Ejemplos: algún tipo de objeto de utilidad de un proyecto pasado que funcionó bien, o posiblemente de un blog con pocos cambios necesarios). Donde esto puede ser malo, es cuando estás copiando un código que no entiendes, o cuando el código es deficiente, o cuando hay una solución alternativa mucho mejor que el código que estás pegando.

Dentro del mismo proyecto: Copiar y pegar en el mismo proyecto no suele ser una buena idea. Este es un mal olor que indica que el código que se está copiando debería estar en un método / clase en algún lugar y ser llamado repetidamente. Hay algunas excepciones a esto, pero en general el programador debería estar pensando: " ¿Hay alguna forma en que pueda parametrizar este código que estoy copiando? ".

La mayoría de los programadores lo hacen, pero eso no significa que debas

Uno de mis mantras de programación es: "Si estoy copiando y pegando código, estoy haciendo algo mal" . Esencialmente, DRY .

Creo que debería ser obvio que reutilizar el código significa usar el código como recurso, no repetir el código. A veces he copiado y pegado mi propio código, en la mayoría de los casos termino con código de placa de caldera o cosas que parecen realmente similares.

Después de invertir más tiempo con ese código, acabo con lo siguiente:

• Un componente (vea también: separation de preocupaciones )
• Puedo recurrir a reflexión para hacer las cosas más simples, limpias y más fácil de repetir en el futuro.
• Un diseño mejor , porque incluso si funciona, ¿por qué no hacerlo de nuevo después de haber aprendido las lecciones?
• Un patrón que puedo abstraer, convertir en un componente de biblioteca y eliminar el código duplicado.

Puede ser discutible si debemos o no copiar & pegue el código ya que al cliente / jefe no le importa (al menos directamente y a corto plazo) y podría terminar con los mismos resultados, pero el problema realmente surge cuando se producen errores, pérdida de modularidad y, en última instancia, un infierno de mantenimiento. .

Lo que debes hacer: refactorizar lo antes posible

Nadie escribe el código perfecto, incluso si funciona, incluso cuando no estás copiando & pegar y es su propio código, si no está del todo satisfecho, simplemente escriba una nota en los comentarios (por ejemplo, un bloque de documentos "@todo") para recordarse qué debe refactorizar y por qué ... incluso si no lo refactoriza usted mismo, podría convertirse en la diferencia entre la felicidad y la frustración total para el mantenedor.

Al final, terminarás con un buen código al final, incluso si lo copia y pega.

atravésde XKCD

Cuando estoy atascado y busco cosas para resolver mi problema y encuentro un fragmento de código útil que hace lo que quiero, naturalmente lo copio. A veces es solo lo esencial. Entonces lo cambio para satisfacer mis necesidades. Esto sucede más a menudo cuando me meto en cosas de las que no soy un experto (actualmente, Objective-C).

Siempre me tomo el tiempo para aprender algo del código, así que para mí es una excelente manera de aprender y evitar reinventar la rueda.

Voy a hablar sobre copiar / pegar el código de otras personas aquí. Tomar partes de mi propio trabajo de mi biblioteca personal es un juego justo. Los conozco y los entiendo por definición.

Encuentro que la situación más frecuente en la que "corté y pegué" el código es cuando tengo un problema particular y me encuentro con una publicación de blog que lo resuelve. La mayoría de las veces vuelvo a escribir la solución en mi proyecto (después de todo, es probable que esté escrito en el estilo del autor del blog, por lo menos). Realmente no es el código mi , pero no me siento mal por usarlo en ese escenario.

Salir y tomar métodos o sistemas completos para pegarlos en mi proyecto tal como está y terminarlo es algo que no entiendo. Hubo una pregunta en StackOverflow el otro día que ilustra perfectamente el problema con hacer algo así.

Coger juntos a un monstruo Frankenstein de diferentes partes de código simplemente no puede ser tan eficiente. Quiero decir, si lo haces bien, eso significa que estás replicando la misma solución una y otra vez o que has comprendido lo suficiente el código de otras personas para que ya no sea necesario el mismo nivel de copiar / pegar y tu la productividad mejoraría al no tener que resolver problemas entre ejemplos de código incompatibles.

Yo personalmente no he conocido a muchos programadores que copian / pegan a gran escala. He visto muchos que se codifican en los rincones más profundos y oscuros, pero esa es una historia diferente. Según mis anecdatos personales, diría que la mayoría de los programadores no copian / pegan aplicaciones enteras juntas, pero es muy difícil decirlo con seguridad.

Malo: copiar y pegar el mismo bloque de código una y otra vez

Si te encuentras haciendo esto, probablemente deberías tomarte un segundo para pensar qué se puede abstraer del código que se está copiando y crear una función / método para manejarlo. Aquí es donde el principio DRY (Don't Repeat Yourself) cuenta.

Bien: copiar un bloque de código que se sabe que funciona

DRY (Don't Repeat Yourself) también se aplica aquí, solo que en un sentido diferente. IE, no repita el trabajo que ya ha hecho en el pasado. Si se ha tomado el tiempo de escribir una sección de código, depurar, probarla y se ha comprobado que funciona en una base de código de producción; Serías tonto si no lo reutilizas.

La mayoría de las personas le dan una mala reputación al copiar y pegar porque muchos programadores principiantes pasan su tiempo recorriendo la red y copiando / pegando una mezcla de código de otras personas sin entender lo que realmente hace.

Escribir todo desde cero cada vez no es mejor. Sé que hay muchos programadores puristas de la vieja escuela que deberían escribir todo desde cero y espero no quedarme atascado trabajando con ellos. Si tiene 5 años de experiencia en programación, debe tener una biblioteca de código bastante importante que sea primordial para su reutilización. Es uno de los mejores activos que un programador experimentado puede traer a la mesa porque potencialmente ahorrará mucho tiempo de desarrollo.

Si no entiendes el código anterior, tómate un momento para leer los comentarios y volver a familiarizarte. Si tus comentarios apestan ... bueno, ese es otro problema.

Después de 25 años de escribir el código, ha habido ocasiones en que (sin acceso al código que escribí para un empleador anterior) deseaba poder cortar y pegar. SIN EMBARGO esto ha sido muy raro (y sigue leyendo).

Quizás el mejor ejemplo es un analizador de línea de comandos realmente simple que encontré hace años para los sistemas operativos Unix. Un simple bucle que comprime los argumentos y procesa las opciones. Fue extremadamente simple y elegante, y lo he usado (más como un patrón que como un corte y pegado literal) muchas veces desde entonces. Esta es la excepción y no la regla.

Por lo general, un simple corte y pegado oleoso es completamente inapropiado, es más importante cortar y pegar el concepto o algoritmo, que ha sido importante.

No estoy muy orgulloso. Buscaré un algoritmo de verificación de paridad o código Hamming realmente rápido o algo así de exótico. Luego, dedique algunas horas a comprenderlo para ver si realmente es lo que buscaba de forma súper rápida o una pila de basura ingenua.

Me preocupa cada vez que alguien simplemente copia el código sin detenerse para entenderlo. Son un genio (entiéndelo y todas sus sutilezas de un vistazo), o un tonto. No hay mucho espacio para nada en el medio. Ah, y tampoco hay muchos genios verdaderos.

Sin comprender, realmente no tiene idea de lo que acaba de lanzar REALMENTE, no solo en las circunstancias felices, sino también en las infelices o en las condiciones de entrada. A veces esto no importa porque tienes suerte. Y a veces esto produce mucho dolor a largo plazo.

Hay una situación común en la que básicamente NECESITAS hacerlo para ser productivo.

Cualquier tecnología que no conozcas es difícil de aprender a menos que tengas un ejemplo práctico para empezar. Por lo tanto, copie y pegue eso para tener algo que realmente ejecute , y luego comience a jugar con él.

Como nuevo programador (4 meses después de mi primer trabajo), confío mucho en la ayuda (ya sea de SO u otros lugares). Me refiero a NO copiar y pegar ciegamente el código de otros. Incluso si el código provisto es lo que usaré, lo escribiré en mi programa y luego pasaré un poco de tiempo asegurándome de que entiendo completamente lo que hace y las razones para ello.

Quiero asegurarme de que estoy aprendiendo constantemente y no simplemente un experto en cortar y pegar

Tengo muchos sentimientos sobre este tema, y honestamente no puedo decir que ninguno de ellos sea completamente objetivo.

Hay muchos argumentos para cortar y pegar el código de otras personas en su aplicación. Algunos de ellos pueden tener sentido, otros no. Por ejemplo, si tiene un método del blog de alguien que toma una entrada y ejecuta un algoritmo matemático complicado que está fuera de su capacidad matemática y arroja un resultado (ese es un argumento para cortar y pegar), obtenga el permiso del autor para usar su codifíquelos y acredítelos cuando sea debido, es algo honorable.

Hay argumentos para no reinventar la rueda: de nuevo, esto tiene sentido, en teoría. Pero si no te tomas el tiempo para familiarizarte íntimamente con el código que estás cortando y pegando, no sabes si hay una mejor manera de resolver este problema, no sabes si hay errores en el código. . ¿Qué pasa si la rueda que está pegando está rota?

Hay argumentos para la velocidad y la eficiencia: usted construye una biblioteca con el código de otras personas que ha robado, robado, plagiado o de otra manera. Ahora que lo pienso, es posible que nunca necesite saber cómo programar más allá. Frankensteining algunas aplicaciones juntas de partes reclamadas.

Hay momentos y lugares donde considero que este comportamiento es completamente aceptable. Para piratear juntos las herramientas de eliminación rápida que no están diseñadas para la longevidad, sino para realizar una tarea, ahora mismo por gancho o por ladrón. Con el propósito de hacer prototipos y estudiar concentos, para aprender y avanzar en un contexto teórico, creo que este es un juego completamente justo.

Cortar y pegar el código de otras personas es plagio: si tienes su bendición y entiendes el código que estás pegando y encaja dentro de la construcción de los estándares de codificación para tu aplicación, bien, admitiré que es un juego justo.

Como ingeniero de software profesional, me pagan para mantener un estándar y un código de ética. No me pagan por robar, plagiar o infringir los derechos de autor de otras personas que ponen a mi cliente en riesgo de ser procesado. Aparte de esto, existe un riesgo muy real de que al ejecutar dicho código cortado / pegado tenga efectos secundarios catastróficos.

No te estoy dirigiendo esta respuesta a ti, John, sé que tienes una inclinación ética en temas como este, por lo que esto es realmente una perorata general en la dirección de la pregunta en sí.

Addendum : Dicho esto, creo que cortar y pegar su propio código entre proyectos es bastante aceptable, a menos que se haya escrito como trabajo por cuenta ajena para otra persona, en cuyo caso no lo hace. t posee los derechos de autor y usted debe obtener el permiso de la persona para la que lo codificó. Descubrí que a menos que el código sea pertinente a los conceptos funcionales de propiedad, la mayoría de los empleadores están de acuerdo con que reutilice sus propias ideas para otros clientes.

Dado que, en un repositorio de código abierto, el 15% de todos los métodos se copian de uno proyecto a otro (pdf), la respuesta parece ser un claro sí.

Si el código es bueno, en lugar de copiar y pegar, debe hacerse en una biblioteca común. Pero a las personas no les puede molestar la refactorización y prefieren tener la misma funcionalidad distribuida por copia y método.

En lugar de tener una ley absoluta universal de copiar y pegar es bueno o malo, uno debería ver cuándo usarlo.

Los pros para copiar y pegar son: Te ayuda a ir rápido Los contras son: el mismo código se distribuye en varios lugares y cualquier problema encontrado / resuelto debe resolverse en todas partes, si en lugar de copiar y pegar uno lo usó como una biblioteca común, la actualización se propagará en todas partes. Para una pequeña inversión inicial de usar una biblioteca en lugar de difundir el mismo código en todas partes.

La opción es si ahorrar un poco de tiempo inicialmente en comparación con mucho más tarde, luego copiar y pegar es el camino a seguir, de lo contrario, refáctalo y ponlo en una biblioteca común.

En la mayoría de los casos, el código que encontrarás en la red no se ajustará a tus propósitos exactos.

Lo que se ve a mí mismo haciendo mucho es copiar el código de alguien, eliminarlo hasta la esencia y luego agregar el código hasta que cumpla con mis requisitos. Siempre lo refactorizaré para que coincida con mis convenciones de nomenclatura y estilo de codificación.

Personalmente, lo odio cuando leo un tutorial y comienzan mostrando un código para un caso complicado. Comience con la esencia y muestre los bloques de construcción para ampliar el código. Si alguna vez empiezo un blog propio, le daré a las personas un ejemplo de código comentado que muestra la esencia de lo que quiero hacer, cómo puede agregar funciones / casos especiales y un ejemplo completamente funcional de la característica básica.

¿Por qué reinventar la rueda si entiendes lo que está haciendo el código, tienes permiso para reutilizarlo (o está abierto) y no necesariamente necesitas todo el código que escribió la otra persona? Con frecuencia copio una implementación de algoritmo y la modifico según mis propias necesidades. Por lo general, aunque solo lo corte y pego es porque no necesito todo lo que estaba en el ejemplo, por lo que agregar otro archivo sería simplemente un desperdicio (o es algo dentro de una función). Estoy de acuerdo con jzd si está cortando y pegando su propio código dentro del mismo proyecto, entonces hay algo incorrecto y probablemente debería encontrar una manera económica de liberarlo o compartir la función.

Encuentro que los miembros del equipo " integración " o aquellos que no tienen tanta experiencia con el código o en la programación tienden a copiar & pegue más a menudo y no entienda lo que hicieron (abordando los problemas mencionados en su pregunta).

También encuentro que los programadores a menudo se mantienen alejados de cortar & pegar a su propio disgusto porque les encanta el código y, a menudo, reinventar la rueda, simplemente porque quieren hacerlo mejor o aprender más.