¿Realmente escribes 'código limpio'? [cerrado]

54

He visto a algunos programadores ajustar su código una y otra vez no solo para que funcione bien, sino también para que se vea bien.

En mi opinión, el "código limpio" es en realidad un cumplido que indica que su código es elegante, perfectamente comprensible y fácil de mantener. Y la diferencia surge cuando tienes que elegir entre un código estéticamente atractivo frente a un código estresante de ver.

Entonces, ¿cuántos de ustedes realmente escriben 'código limpio'? ¿Es una buena práctica? ¿Cuáles son los otros beneficios o inconvenientes de esto?

ykombinator
fuente
En todos mis intentos de escribir código "limpio" de acuerdo con principios bien establecidos, nunca encontré que fuera tan fácil mantener más allá de cierta escala basada solo en tal premisa. Mucho más relevante fue su confiabilidad y cuán bien probado y cuán adecuado fue para su propósito (que puede relacionarse tanto con la implementación como con el diseño). Toda la limpieza del mundo no puede compensar la falta de ninguno de estos, y a veces el código más confiable que sigo usando no es el más limpio, mientras que el más limpio no siempre fue el más confiable.
Así que, por encima de todo, por encima de la legibilidad, la belleza, el SÓLIDO, cualquier otra cosa, he encontrado útil priorizar la confiabilidad y la "estabilidad" (la calidad de ser inmutable en mi libro y, además, carecer de la necesidad o el deseo de cambiar promover, adicional). Las cosas confiables y estables son las que han durado la prueba del tiempo para mí, y a veces no son muy limpias en absoluto por los libros de muchas personas (algunos de mis códigos más reutilizados son los códigos C que datan de finales de los 80 y principios de los 90 que aplica cosas como trucos de juguete que casi nadie entiende, todavía funciona de manera tan confiable).

Respuestas:

52

Yo diría que muchos de nosotros no escribimos código limpio . Y en general, ese no es nuestro trabajo . Nuestro trabajo como desarrolladores de software es entregar un producto que funcione a tiempo.

Recuerdo la publicación del blog de Joel Spolsky: The Duct Tape Programmer .

Cita de codificadores en el trabajo :

Al final del día, ¡envía la maldita cosa! Es genial reescribir su código y hacerlo más limpio y, por tercera vez, en realidad será bonito. Pero ese no es el punto: no estás aquí para escribir código; Estás aquí para enviar productos. - Jamie Zawinsky

También recuerdo la respuesta del blog de Robert Martin :

Entonces. Se inteligente. Estar limpio Ser simple. ¡Embarcacion! Y tenga listo un pequeño rollo de cinta adhesiva, y no tenga miedo de usarlo. - Tío Bob

Si el código, un desarrollador escribe pasa a ser limpio Y funciona (es entregable), que así sea, bueno para todos. Pero si un desarrollador está tratando de crear un código limpio y legible a expensas de poder entregarlo a tiempo, entonces eso es malo. Haga que funcione, use cinta adhesiva y envíela. Puede refactorizarlo más tarde y hacerlo súper hermoso y eficiente.

Sí, es una buena práctica escribir código limpio, pero nunca a expensas de poder entregar. El beneficio de entregar un producto con cinta adhesiva a tiempo supera con creces los beneficios del código limpio que nunca se terminó y entregó.

Una buena parte del código que he encontrado no está limpia. Algunos son francamente feos. Pero todos fueron lanzados y utilizados en la producción. Algunos pueden decir que no es profesional escribir código desordenado. Estoy en desacuerdo. Lo profesional es entregar código que funcione, ya sea limpio o desordenado. El desarrollador debe hacer lo mejor que pueda, dado el tiempo asignado antes de la entrega. Luego, vuelve a limpiar, eso es profesional. Con suerte, el código entregado no es cinta adhesiva pura y es "lo suficientemente limpio".

esponja
fuente
45
Mientras su deuda técnica ( en.wikipedia.org/wiki/Technical_debt ) no lo lleve a una "quiebra técnica" (no puede entregar nuevas características, arreglar una parte rompe otra, etc.), y que esté atento en eso, estoy de acuerdo.
Matthieu
3
@HeathLilley estuvo de acuerdo. Simplemente no creo en los desarrolladores que dicen que solo se debe escribir un código limpio. Eso es falso. El código desordenado sucede. La idea de que los desarrolladores solo deben escribir código limpio y correcto desde el principio es una ilusión. Promuevo la idea de que siempre volvemos a visitar y refactorizamos una vez que mejora nuestra comprensión del dominio.
Spong
40
El problema con "solo enviar la maldita cosa ahora" es que la gerencia no comprará sus razones para refactorizar más tarde, pero si lo hace invisiblemente AHORA, todo estará bien.
Trabajo
55
Otra ilusión es pensar que tendrás tiempo para limpiarlo más tarde. Eso no va a suceder. Tendrás otras cosas para enviar. No deberías entregar código desordenado. Y, por cierto, también deberías estar trabajando en los plazos, eres el técnico que sabe cuánto tiempo llevará escribir código limpio. Eso no significa una limpieza excesiva y retoques durante una cantidad de tiempo increíble, sino que debe tenerse en cuenta el tiempo para refactorizar antes de enviar el código.
Steve Chamaillard
3
"Puedes refactorizarlo más tarde" [cita requerida]
Carl Leth
39

Debe asegurarse de que su código sea muy legible, limpio y fácil de mantener. Eso es lo que todos los programadores deben hacer.

Pero usted está hablando over styling(como ese término mejor que el código de niña ) que no sirve más que el ego de su autor.

He visto a muchos desarrolladores en el pasado tan orgullosos de su creación (ya sabes, como en los baños;)), pasaron horas limpiando y puliendo su código. Algunos de ellos fueron tan meticulosos que se aseguraron de que se respetaran los espacios en blanco correctos entre los miembros.

Es demasiado.

Encuentro ese tipo de comportamiento contraproducente. En un contexto profesional , debes ser profesional . Puede obtener su satisfacción escribiendo un código limpio, muy legible y fácil de mantener y hablando con usuarios o colegas felices.

usuario2567
fuente
13
Bueno, pulí hasta que el código sea claramente legible para mí. Si regreso dos semanas después y tengo que averiguar qué hice, probablemente no sea lo suficientemente claro para que otros lo entiendan fácilmente.
Robert Harvey
14
El código elegante es inherentemente más fácil de mantener, y creo que más fácil de leer.
Craige
66
+1, he visto algunos códigos SPAGHETTI perfectamente diseñados en el pasado.
Jas
23
Estoy de acuerdo con el sentimiento, pero escribo mi código con el número correcto de espacios entre los miembros, y estoy irritado por las personas que no lo hacen. Es algo fácil de hacer (hecho aún más fácil con herramientas automatizadas como StyleCop), y la consistencia que brinda vale la pequeña cantidad de esfuerzo requerido.
Robert Harvey
3
@sunpech: escríbelo limpio, y es mucho más fácil mantenerlo limpio.
David Thornley
24

No estoy de acuerdo con la respuesta aceptada sobre esta pregunta.

Obviamente, su responsabilidad es enviar, pero generalmente también tiene la responsabilidad de enviar algo que pueda mantener de la manera más rentable posible para usted y los futuros desarrolladores.

He pasado períodos como ese pobre programador de mantenimiento o consultor en el sitio que tiene que comprender y depurar un gran sistema indocumentado, y puedo decirle que los diseños deficientes y el código confuso y desordenado pueden generar horas o incluso días de esfuerzo desperdiciado. Puedo pensar en muchas situaciones en las que un esfuerzo adicional de N horas por parte del desarrollador inicial podría haber llevado a un ahorro de 5N en términos de mi tiempo.

Sé que hay una estadística flotando sobre esto, pero en mi experiencia en múltiples proyectos, cada línea de código que se escribe se lee 5-20 veces durante la extensión y el mantenimiento.

Entonces diría que limpie el código a una pulgada de su vida útil . Lleva tiempo, pero es probable que ahorre costos netos durante la vida del proyecto.

Benjamin Wootton
fuente
2
No, usted limpia su código cuando hay tiempo y presupuesto, Y el riesgo de hacerlo es menor que el riesgo de no hacerlo. En entornos de producción, eso significa que con bastante frecuencia no va a pulir el código existente para hacerlo más bonito, simplemente no es rentable pero causa el riesgo de introducir nuevos errores.
Jwenting
Esto también depende de en qué rincón del desarrollo de software trabaje. Solía ​​trabajar para una agencia de marketing digital que estaba más que feliz de pasar los cargos a su cliente si la siguiente fase demorara más debido a problemas con la base del código. Nuestro impulso por más tiempo durante el desarrollo para solucionar problemas existentes fue derribado a favor de un tiempo de desarrollo extendido que equivalía a más dinero para el negocio.
Simon Whitehead
1
Estoy de acuerdo con eso, debe entregar el código, pero si no puede arreglar / actualizar / actualizar, lo que entregó no fue código, sino un agujero de dinero. Me parece que las personas que luchan contra esa idea están acostumbradas a trabajar en entornos malos y argumentan un sistema que nunca han experimentado. He mantenido un código limpio y no limpio, y le diré que el código limpio es mucho más barato y más rápido de mantener y desarrollar.
Jdahern
21

¿Alguno de nosotros compraría un automóvil si supiéramos que debajo del capó todo es desordenado y difícil de solucionar, mantener o arreglar y requiere más recursos para funcionar de lo que debería?

¿Por qué debería ser diferente para una pieza de software?

El hecho de que los usuarios finales no puedan mirar debajo del capó no significa que nunca lo sabrán. Tarde o temprano aparecerá.

Respondiendo a la pregunta "¿Realmente escribes 'código limpio'?" -- Oh si.!

Sifar
fuente
No estaría de acuerdo: el software no se oxida (como dice Joel), a diferencia del interior de un automóvil. Podría argumentar que cuando se actualiza un sistema operativo, el software también debe actualizarse, pero eso es algo diferente. Además, me hago un código limpio de escritura, pero no creo que es la característica más importante de mis contribuciones.
K.Steff
18

Si por "código limpio" quieres decir, ¿hago todo lo posible para asegurarme de que el código sea lo más claro posible?

Diablos si.

Cuanto más limpio, más claro sea el código, más fácil será mantenerlo y, por lo tanto, le ahorrará tiempo a largo plazo. No mire el código limpio como vanidad; Míralo como una inversión para ahorrar esfuerzo y tiempo en el futuro.

GrandmasterB
fuente
15

Honestamente depende. Me gusta cómo todos dicen en voz alta sobre cómo "¡nada menos que limpiar un código bien documentado es una pura parodia!", Pero trabajo en un negocio con ciclos de implementación ridículos y cero supervisión: hago lo mejor que puedo, pero lo escribo Para muchos códigos es extremadamente difícil escribir el código limpio perfecto que todos los demás afirman que escriben.

Intento escribir código que pueda ser mantenido fácilmente por alguien que tenga aproximadamente mi capacidad. Comento las partes difíciles, nombro los nombres amigables de los programas, variables y clases, despliego y sigo adelante. No tengo tiempo para hacer otra cosa.

A veces me siento un poco culpable por eso, pero no muy. Deberías ver algunos de los horrores con los que trato a diario. Décadas de código personalizado en idiomas oscuros con cero documentación. Uno de mis compañeros de trabajo se desarrolla exclusivamente en Visual Basic 6.0 e implementa binarios con nombres crípticos en todo el lugar. La mujer que reemplacé programó exclusivamente en RPG .

Es extremadamente difícil para mí creer, por más horrible que haya visto en mis años como programador, que todos solo generan código limpio.

Satanicpuppy
fuente
Convenido. La mayoría de las personas no van a escribir código limpio para enviar / liberar la primera vez. Hay cinta adhesiva involucrada para hacer el trabajo.
Spong
2
¡Suficiente con la cinta adhesiva! Spolsky no es dios. ¡Se pone los pantalones en una pierna al mismo tiempo que nosotros!
Trabajo
55
Parte de la razón por la que escribe código limpio es que es más rápido escribir código limpio que el código sucio en cualquier línea de tiempo más corta (digamos unas horas). Si pensar durante unos segundos en los nombres de variables y métodos va a hacer que se pierda una fecha límite, entonces también lo hará el valioso tiempo que pierde cuando usted y / o sus compañeros de trabajo se confunden con su código. Hace que el código suene casi desechable, como si lo escribiera, se usará durante un tiempo sin mantenimiento y luego se retirará. Quizás en su situación peculiar el código sea desechable. Nunca he visto que eso suceda en una década de experiencia práctica.
PeterAllenWebb
1
@peter: Y en dos décadas, nunca he visto un lugar donde cada pieza de código estuviera limpia. Raramente he visto un lugar donde estaba la mitad . ¿Donde trabajas? NASA?
Satanicpuppy
2
@Satanicpuppy He visto muchos códigos sucios en mi tiempo, y he escrito mi parte, pero casi todo estaba perdiendo mi tiempo o el de otra persona. Estoy de acuerdo con la afirmación de que el código limpio en realidad puede escribirse MÁS RÁPIDO que el código sucio en cualquier escala de tiempo de más de unas pocas horas.
PeterAllenWebb
7

No creo que me guste el término "código de niña" pero código limpio = código mantenible. Cualquier cosa menos no es profesional.

Como regla general, considero el próximo desarrollador que tiene que mirar mi desorden.

Muchas veces soy yo ... varios meses después ... cuando no recuerdo cómo funciona ... y tengo aún menos tiempo para hacer un cambio.

Heath Lilley
fuente
5

Intento escribir "código limpio" en el sentido de Bob Martin (por ejemplo, diseño OO). Hay un gran valor en escribir código limpio. Es mucho más fácil de mantener.

Luego dejo que ReSharper lo convierta en un "código bonito" para mí (por ejemplo, alineación, saltos de línea, etc.). Hay un buen valor en escribir código bonito. Pero hay rendimientos decrecientes. Algunas prettificaciones lo hacen un poco más fácil de mantener debido a la facilidad de lectura.

Si cree que es necesario alinear bloques de código enormes para que sea legible, ¡entonces el problema es su enorme bloque de código! Es muy grande. Veo muchos ejemplos de personas que se esfuerzan mucho para embellecer un código muy mal diseñado.

Si no tuviera ReSharper, todavía tendría un código limpio, pero no sería tan bonito.

No creo que deba dedicar más del ~ 5% de mi tiempo de codificación a la prettificación. Lo que significa que cuanto más potente sea mi editor y más hábil sea con él, más prettificación puedo hacer.

dss539
fuente
4

Parece que nadie plantea el punto de lo que es mejor para su empresa?

A menudo, si no siempre, los programadores son solo empleados, y aunque las decisiones de gestión pueden frustrarnos, a menudo no tenemos todos los datos que tienen.

Por ejemplo, supongamos que la compañía tiene un contrato con una cláusula que dice que si el software no está listo a tiempo, no se le pagará (simplemente nos sucedió, aunque creo que obtuvimos el pago después de todo). Sí, el código limpio es importante, ¡pero lo más importante es que el código funcione antes del día de pago!

Otro ejemplo: la compañía está en una mala situación financiera y necesita recaudar algo de dinero. ¿Adivina a quién le importa la calidad? Puede arreglarlo más tarde, si es necesario, ¡simplemente envíelo!

Un argumento podría ser "¿Por qué debería vender y escribir código malo?". Bueno, ¿por qué su empresa debería pagarle un buen cheque cada mes? Elecciones, mi amigo. Si buscas el idealismo, prueba la Free Software Foundation ; Escuché que están haciendo algunas cosas geniales (me refiero a esta, y respeto FSF y OSS).

Por otro lado, si trabaja en un proyecto donde se espera un crecimiento explosivo en el uso (aunque tales proyecciones casi nunca son precisas), es mejor que establezca una base sólida con la mejor calidad de código requerida, ya que es casi seguro que el mantenimiento Ser el mayor costo para el proyecto.

Los programadores aman el código 'limpio', sea lo que sea que eso signifique. Ni siquiera podemos ponernos de acuerdo sobre lo que está limpio, pero nos encanta. Sin embargo, a veces simplemente no importa tanto como la usabilidad y la corrección. Estos pueden parecer sinónimos, pero no lo son: si ha visto código escrito por un verdadero pirata informático de Perl en 4 horas con la intención de usarse dos veces y desecharse, reconocerá que no está limpio, pero funciona.

Entonces, a veces, dejando de lado el ego, deberíamos hacerlo funcionar. Tenga en cuenta que no recomiendo escribir código incorrecto como un hábito; Solo estoy señalando que podría ser necesario. La perfección lleva tiempo que su empresa podría no tener. Entonces, si a su empleador no le importa, cree software, pero si lo necesita, simplemente escriba el código de trabajo, no importa la 'limpieza'. Simplemente no es una respuesta de 'talla única': debe priorizar.

K.Steff
fuente
3

No estoy seguro de que "verse bien" y ser "elegante, perfectamente comprensible y sostenible" sea equivalente.

Intento escribir código, que es "elegante, perfectamente comprensible y fácil de mantener". Refactorizo ​​mi propio código para que coincida mejor con esos criterios.

No veo ningún inconveniente, excepto el costo resultante en el tiempo.

Para que el código "se vea bien", hay muchas herramientas automatizadas, que sangrarán y espaciarán adecuadamente todo lo que desee.

back2dos
fuente
2
Eso me molesta aún más cuando veo código mal formateado. La persona que lo escribió podría haber utilizado una de esas herramientas para hacerlo por ellos. También ocurre con mayor frecuencia cuando se mezclan pestañas y espacios para crear un desastre impuro.
jsternberg
3

Demasiado de algo nunca es bueno.

Sin embargo, una cosa importante a tener en cuenta con el código "impuro" es que puede conducir fácilmente a " ventanas rotas ". Si el código está muy mal formateado, creo que muchas personas nuevas en la base del código podrían sentirse menos inclinadas a hacer un buen trabajo con el mantenimiento y la evolución, lo que provocaría una espiral descendente que podría afectar las condiciones de funcionamiento del software.

Por lo tanto, mantener un cierto nivel de limpieza en el código es beneficioso para algo más que sus colegas desarrolladores. No gaste demasiado tiempo en ello (se ha mencionado ~ 5%). Aprenda a usar las herramientas de su oficio para automatizar tareas manuales (formato de código en este caso). Asuma la responsabilidad de lo que hace y siempre haga lo que considere más beneficioso para su empresa / clientes / usuarios.

Por Noalt
fuente
3

Esta es una cita de Clean Code, de Bob Martin:

Para llevar este punto a casa, ¿qué pasaría si fuera un médico y tuviera un paciente que le exigiera que dejara de lavarse las manos tontamente en preparación para la cirugía porque estaba tomando demasiado tiempo? Claramente el paciente es el jefe; y, sin embargo, el médico debe negarse absolutamente a cumplir. ¿Por qué? Porque el médico sabe más que el paciente sobre los riesgos de enfermedades e infecciones. Sería poco profesional (no importa lo criminal) que el médico cumpla con el paciente.

Por lo tanto, tampoco es profesional que los programadores se dobleguen a la voluntad de los gerentes que no entienden los riesgos de causar problemas.

Tulains Córdova
fuente
2

Creo que el "código limpio" debería ser tan limpio o más limpio que como solía escribir en sus exámenes de física / ingeniería / matemáticas. Si es demasiado desordenado, el calificador no entenderá su trabajo y probablemente lo marcará mal incluso si es correcto.

chiurox
fuente
2

Me gusta que el código sea legible, pero lo más importante es la coherencia. Para mí eso significa coherencia con las convenciones de nomenclatura y el espaciado entre funciones, paréntesis en la misma línea o la siguiente línea de la declaración if, etc.

Por supuesto, hay momentos en que alguien programa algo con un estilo de código consistente y todavía me vuelve loco. Especialmente código que no "respira". Por ejemplo:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Bueno ... Se ve peor con los métodos Objective-C, y con montones de sentencias if anidadas, y líneas mucho más largas que 80 caracteres. Pero todavía me molesta :)

vedosidad
fuente
2

Hago un gran esfuerzo para limpiar el código. Creo que ayuda mucho a que los errores se destaquen.

No estoy de acuerdo con el concepto de "enviar la maldita cosa ahora", porque el código limpio es una inversión para el futuro. También se envía demasiado software con demasiados errores. Resolver un error en mi opinión es mejor que implementar una nueva característica.

Además, si observa las estimaciones de la productividad del programador , no creo que obtenga una puntuación muy mala. Escribir código limpio es un hábito, y cuanto más experiencia como programador, más eficiente se vuelve. Si uno nunca lo intenta, obviamente, nunca obtendrá experiencia con él.

Otro punto a tener en cuenta es que la mayor parte del tiempo del desarrollador va a leer el código, por lo que el código legible reduce en gran medida el tiempo dedicado a la lectura. Comprender los algoritmos no documentados, por ejemplo, puede ser costoso e invitar a nuevos errores.

Una cosa que definitivamente echo de menos y que me gustaría tener algún día es un formateador de código automático que pueda adaptar a mi estilo, que realmente me ahorrará algo de tiempo, especialmente al leer el código de otras personas.

La codificación limpia tiene un vínculo con el perfeccionismo, que tiene el riesgo de nunca materializarse, pero creo que eso es principalmente un problema cuando comienzas, porque inviertes más tarde y cuando reutilizas tus propios códigos elegantes, combinados con tu experiencia , envejeciendo serás muy productivo y mucho menos perseguido por los errores que los codificadores desordenados.

Este es un fragmento de código que demuestra mi estilo de codificación.

usuario20416
fuente
1

Solo evite el "código de vanidad". Hay muchos desarrolladores que hacen cosas por pura vanidad (o debido a un TOC) y nada más. Mis bragas realmente se tuercen con esas personas.

ElGringoGrande
fuente
¿Te gustan los comentarios de ala o (peor) cuadro, por ejemplo?
David Thornley el
1

Escribo código que intenta resolver el problema dado de la manera más eficiente y teóricamente 'elegante'. En ese sentido solo está limpio. Si resulta que es "bonito" cuando termine, que así sea.

Lo que he encontrado en mis experiencias limitadas es que cuando las personas se quejan de 'código limpio', la fealdad suele ser el resultado de una solución terrible en lugar de una convención de codificación.

Kurtis
fuente
1

Diría que hago un esfuerzo para escribir código más limpio, pero eso puede cambiar debido a limitaciones de tiempo o si estoy trabajando en algo difícil. Tiende a complicarse cuando se enfoca en hacer que funcione. Luego volveré y limpiaré mientras lo reviso. Si vuelve al código y tiene que pasar demasiado tiempo refrescando su memoria, no lo comentó lo suficiente.

El código limpio es bueno, pero como todo lo demás, solo necesita estar lo suficientemente limpio. Sangrar 5 líneas de código 4 espacios y una línea 5 espacios no aumenta la dificultad de lectura.

JeffO
fuente
1

Creo que depende de lo que estés haciendo. Si estoy escribiendo una solicitud de prueba de concepto, básicamente estoy codificando a mi vaquero y no mirando hacia atrás. Si estoy trabajando en una aplicación en la que voy a estar trabajando durante un tiempo, entonces me aseguro de codificarla lo suficientemente bien como para que sea comprensible dentro de un mes.

Creo que diseñar tu código es un poco dudoso. Como algunos han dicho anteriormente, su trabajo es hacer un producto, no un código formateado, pero yo diría que al menos uno debe seguir con un estilo definido de comentar y codificar cosas. Odiaría ver la mitad de las variables en camello y la otra mitad húngara.

Pero también, depende de lo que quiera decir con 'código limpio'.

usuario7007
fuente
0

Admito haber hecho eso; y el beneficio no se molesta cada vez que lo veo. Supongo que también es más fácil de leer y, por lo tanto, los errores se vuelven más obvios; pero la verdadera razón es que no soporto el código feo.

usuario281377
fuente
0

Refactorizar su código para que sea elegante hace que sea más fácil de leer y más fácil de mantener. Incluso cosas menores como alinear sus asignaciones variables:

int foo    = 1;
int bar    = 2;
int foobar = 3;

es más fácil de leer que

int foo = 1;
int bar = 2;
int foobar = 3;

lo que significa que es más fácil pasar por alto cuando estás depurando más tarde.

Además, en PHP se le permite cualquier cantidad de bloques de código aleatorio. Los uso para agrupar tareas lógicas:

// do x
{
    // ...
}

// do y
{
    // ...
}

Esto agrega una definición clara al código relevante.

Editar : como una ventaja adicional, es fácil preceder a uno de esos bloques de código lógico con un if (false)si desea omitirlo temporalmente.

Craige
fuente
11
Creo que ya inventaron algo que hace eso: se llama función. Cada vez que te encuentres creando uno de esos bloques, deberías crear una función en su lugar. A partir de ahí, si no desea ejecutarlo, comente la llamada de función (en lugar de poner un comentario
atrasado
1
@ stargazer712: Odio las funciones de php debido a la falta de espacios de nombres definidos. Inevitablemente, al leer el código de otra persona, tienen un "incluir" en la parte superior, que incluye otras 5 cosas, cada una de las cuales incluye 4 más, y luego tengo que hacer una búsqueda en toda la base del código para encontrar la definición de la función. Muy frustrante.
Satanicpuppy
A menudo, este es un código que no garantiza una declaración de función. p.ej. sin posibilidad de reutilización, el cálculo / ajuste de variables locales de ámbito relacionados, etc
Craige
Por otro lado, el código sin posibilidad de reutilización es raro. Si te encuentras escribiendo una gran cantidad de código que no se puede reutilizar, hay una buena posibilidad de que se pueda mejorar ... en gran medida.
riwalk
-2

Solo escribo mi código, siguiendo los estándares de la compañía. Si lo quiero "embellecido", puedo ejecutarlo a través de un embellecedor de código.

Muad'Dib
fuente
2
Excepto que lo que generalmente sucede es que alguien más termina ejecutándolo a través de un embellecedor tratando de limpiar lo que no pudo limpiar.
riwalk
@ Stargazer712, que es exactamente la razón por la que no me molesto mucho más allá de seguir los estándares de la compañía
Muad'Dib
@ Maud'Dib, el problema es que el resultado es tan bueno como el embellecedor. Mientras que el espacio en blanco horizontal se trata completamente del alcance (y, por lo tanto, se limpia muy bien), el espacio en blanco vertical generalmente se trata de intención (agrupando lo que está relacionado) y se limpia muy mal. En pocas palabras: ten piedad de tus compañeros desarrolladores.
riwalk
@ Stargazer712 El problema es, a excepción de los "estándares de la compañía", todo lo demás es cuestión de gustos, lo cual es subjetivo. Por ejemplo, me gusta poner espacios en lugares donde mi compañero de trabajo los odia positivamente. Hago que me parezca agradable, y eso es todo lo que puedo llegar.
Muad'Dib
1
Tenga cuidado con los "embellecedores", ya que pueden estropear los compromisos de fusión a lo grande (tengo experiencia de primera mano :)).
Juha Untinen