Aprendí muy temprano que cortar y pegar el código de otra persona lleva más tiempo a largo plazo que escribirlo usted mismo. En mi opinión, a menos que realmente lo entiendas, el código de cortar y pegar probablemente tendrá problemas que serán una pesadilla para resolver.

No me malinterpreten, quiero decir que es esencial encontrar el código de otras personas y aprender de él, pero no solo lo pegamos en nuestra aplicación. Nos reescribir los conceptos en nuestra aplicación.

Pero constantemente escucho sobre personas que cortan y pegan, y hablan de eso como si fuera una práctica común. También veo comentarios de otros que indican que es una práctica común.

Entonces, ¿la mayoría de los programadores cortan y pegan el código?

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 hacerle cambios. Creo que esta práctica suele estar bien. Esto es especialmente bueno cuando es un código probado. (Ejemplos: algún tipo de objeto de utilidad de un proyecto anterior que funcionó bien, o posiblemente de un blog con pocos cambios necesarios). Donde esto puede ser malo, es cuando está copiando código que no entiende, o donde el código es deficiente, o donde hay una solución alternativa mucho mejor que el código que está pegando.

Dentro del mismo proyecto: Copiar y pegar en el mismo proyecto generalmente no es una buena idea. Es un mal olor que el código que se está copiando solo debe estar en un método / clase en algún lugar y llamado repetidamente. Hay algunas excepciones a esto, pero generalmente el programador debería pensar: " ¿Hay alguna forma de 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, SECO .

Creo que debería ser obvio que la reutilización del código significa usar el código como un 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 un código de placa de caldera o cosas que se parecen mucho.

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

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

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

Lo que debe hacer: refactorizar lo antes posible

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

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

a través de XKCD

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

Siempre me tomo el tiempo para aprender algo del código, por lo 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í. Agarrar 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 "corto y pego" 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, probablemente esté escrito en el estilo del autor del blog, por lo menos). No es realmente mi código, pero no me siento mal por usarlo en ese escenario.

Salir y tomar métodos o sistemas completos para pegarlos en mi proyecto tal cual y llamarlo hecho es algo que no entiendo. Hubo una pregunta en StackOverflow el otro día que ilustraba perfectamente el problema de hacer algo así.

Reunir un monstruo de Frankenstein con diferentes partes del código no puede ser tan eficiente. Quiero decir, si eres bueno en eso, eso significa que estás replicando la misma solución una y otra vez o has obtenido suficiente comprensión del código de otras personas para que el mismo nivel de copia / pegado ya no sea necesario y tu la productividad mejoraría al no tener que resolver problemas entre muestras de código incompatibles.

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. Basado en mis datos personales, diría que la mayoría de los programadores no copian / pegan aplicaciones completas juntas, pero es realmente difícil decirlo con certeza.

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

Si se encuentra haciendo esto, probablemente debería tomarse un segundo para pensar en lo que se puede extraer del código que se está copiando y crear una función / método para manejarlo. Aquí es donde cuenta el principio SECO (no repetir).

Bien: copiar un bloque de código que funciona

DRY (Don't Repeat Yourself) también se aplica aquí, solo que en un sentido diferente. Es decir, no repitas el trabajo que ya has hecho en el pasado. Si se ha tomado el tiempo de escribir una sección de código, depurarla, probarla y se ha comprobado que funciona en una base de código de producción; Sería tonto no volver a usarlo.

La mayoría de las personas consideran que copiar y pegar es un mal golpe porque muchos programadores principiantes pasan su tiempo recorriendo la red y copiando / pegando una mezcla de códigos 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 creen que todo debería estar escrito 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 sustancial que sea excelente para su reutilización. Es uno de los mejores activos que un programador experimentado puede aportar a la mesa porque potencialmente ahorrará mucho tiempo de desarrollo.

Si al principio no entiende con su antiguo código, tómese un momento para leer los comentarios y volver a familiarizarse. Si sus comentarios apestan ... bueno, ese es otro problema por completo.

Después de 25 años de escribir código, ha habido ocasiones en que (sin acceso al código que escribí para un empleador anterior) he deseado 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 sistemas operativos Unix. Un bucle simple que atraviesa los argumentos y procesa las opciones. Era divinamente simple y elegante, y lo he usado (más como un patrón que como un literal cortar y pegar) muchas veces desde entonces. Esta es la excepción más que la regla.

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

No estoy demasiado orgulloso: buscaré felizmente para encontrar una paridad realmente rápida o un algoritmo de verificación de código de hamming o algo exótico como ese. Luego, pasa unas horas entendiéndolo para ver si realmente es lo masivamente súper rápido que buscaba, o un ingenuo montón de basura.

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 entender, realmente no tienes idea de lo que acabas de lanzar REALMENTE, no solo bajo las circunstancias felices o infelices o las condiciones de entrada. A veces esto no importa porque tienes suerte. Y a veces esto provoca 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 le resulte familiar es difícil de aprender a menos que tenga un ejemplo práctico para comenzar. Por lo tanto, copie y pegue eso para tener algo que realmente se 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 propongo 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 entender 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.

Existen 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á muy por encima de sus habilidades matemáticas y escupe un resultado, ese es un argumento para cortar y pegar, obtenga el permiso del autor para usar su codifíquelos y acéptelos cuando sea debido, es lo más honorable que puede hacer.

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

Hay argumentos a favor de la velocidad y la eficiencia: construye una biblioteca de código de otras personas que ha robado, robado, plagiado o de lo contrario, pensándolo bien, es posible que nunca necesite saber cómo programar más allá de Frankensteining alguna aplicación juntos de partes recuperadas.

Hay momentos y lugares donde considero que este comportamiento es completamente aceptable. Para hackear herramientas rápidas desechables que no están diseñadas para la longevidad, sino para realizar una tarea, ahora mismo por las buenas o por las malas. Con el propósito de crear prototipos y estudiar conceptos, 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 se ajusta a la construcción de los estándares de codificación para tu aplicación, entonces, 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 se me paga para robar, plagiar o infringir los derechos de autor de otras personas, lo que pone a mi cliente en riesgo de enjuiciamiento. Aparte de esto, existe un riesgo muy real de que cuando ejecute dicho código cortado / pegado tenga efectos secundarios catastróficos.

Sin apuntarle a usted esta respuesta, John, sé que está muy inclinado éticamente cuando se trata de temas como este, por lo que esto es realmente solo una queja general en la dirección de la pregunta en sí.

Anexo : Dicho esto, creo que cortar y pegar su propio código entre proyectos es bastante aceptable, a menos que haya sido escrito como trabajo por encargo para otra persona, en cuyo caso no posee los derechos de autor y debe obtener el permiso de la persona para la que lo codificó. He descubierto que, a menos que el código sea pertinente para 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 un proyecto a otro (pdf), la respuesta parece ser un sí claro.

Si el código es bueno, en lugar de copiar y pegar, se debe convertir en una biblioteca común. Pero las personas no pueden molestarse con la refactorización y prefieren tener la misma funcionalidad extendida por copia y método.

En lugar de tener una ley absoluta universal de copiar y pegar es buena o mala, uno debería ver cuándo usarla.

Las ventajas de copiar y pegar son: Le permite avanzar rápidamente Contras: 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 biblioteca común, la actualización será propagarse por 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 elecció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, refactorizar y colocarlo en una biblioteca común.

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

Lo que me veo haciendo mucho es copiar el código de alguien, desglosarlo hasta la esencia misma y luego agregar código hasta que cumpla con mis requisitos. Siempre lo refactorizaré para que coincida con mis convenciones de nombres y estilo de codificación.

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

¿Por qué reinventar la rueda si comprende lo que hace el código, tiene permiso para reutilizar el código (o está abierto) y no necesita necesariamente todo el código que escribió la otra persona? Con frecuencia copio la implementación de un algoritmo y la modifico según mis propias necesidades. Por lo general, cuando acabo de cortar y pegar es porque no necesito todo lo que estaba en el ejemplo, por lo que agregar otro archivo sería 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 mal y probablemente debería encontrar una forma económica de liberarlo o compartir la función.

Me parece que los miembros del equipo de " integración " o aquellos que no tienen tanta experiencia con el código o la programación tienden a copiar y pegar con más frecuencia y no entienden lo que hicieron (meterse en los problemas mencionados en su pregunta).

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