¿Es el formato inconsistente un signo de un programador descuidado?

64

Entiendo que cada persona tiene su propio estilo de programación y que debería poder leer los estilos de otras personas y aceptarlos tal como son. Sin embargo, ¿se consideraría a uno como un programador descuidado si el estilo de codificación de uno fuera inconsistente en el estándar en el que estaban trabajando?

Algunos ejemplos de inconsistencias podrían ser:

  1. A veces nombra variables privadas con _ y otras veces no
  2. A veces, con sangrías variables dentro de los bloques de código
  3. No se alinean los apoyos hacia arriba, es decir, en la misma columna si se usa comenzar con el nuevo estilo de línea
  4. El espaciado no siempre es consistente alrededor de los operadores, es decir, p = > p + 1, p + = 1 frente a otras veces p = > p + 1 o p = > p + 1 etc

¿Esto es algo que, como programador, debería ocuparme de abordar? ¿O es algo tan insignificante que al final del día no debería preocuparme por lo que ve el usuario final y si el código funciona en lugar de cómo se ve mientras se trabaja?

¿Es una programación descuidada o simplemente sobre la selección obsesiva de liendres?

EDIT : Después de algunos excelentes comentarios, me di cuenta de que podría haber omitido alguna información en mi pregunta. Esta pregunta surgió después de revisar el registro de código de otros colegas y notar algunas de estas cosas y luego darme cuenta de que he visto este tipo de incoherencias en los registros anteriores. Luego me puse a pensar en mi código y en si hago las mismas cosas y noté que normalmente no lo hago, etc. No estoy sugiriendo que su técnica sea mala o buena en esta pregunta o si su forma de hacer las cosas es correcta o incorrecta. .

EDIT : para responder a algunas consultas y obtener más comentarios positivos. La instancia específica en la que se realizó esta revisión fue usar Visual Studio 2010 y la programación en c #, por lo que no creo que el editor cause ningún problema. De hecho, sólo debería ayudar, espero. Lo siento si dejé esa información y afecta las respuestas actuales. Intenté ser un poco más genérico para comprender si esto se consideraría descuidado, etc. Y para agregar un ejemplo aún más específico de una pieza de código que vi durante la lectura del registro:

foreach(var block in Blocks)
{
   // .. some other code in here

   foreach(var movement in movements)
   {
       movement.Moved.Zero();
       } // the un-formatted brace
   }

Una cosa tan pequeña que sé, pero muchas cosas pequeñas se suman (???), y tuve que echar una doble mirada al código en el momento para ver dónde estaba todo alineado, supongo. Tenga en cuenta que este código fue formateado adecuadamente antes de este check-in.

EDIT : después de leer algunas respuestas geniales y pensamientos variados, el resumen que he tomado de esto fue.

  1. No es necesariamente un signo de un programador descuidado. Sin embargo, como programadores tenemos el deber (para nosotros y otros programadores) de hacer que el código sea lo más legible posible para ayudar en el desarrollo continuo. Sin embargo, puede sugerir deficiencias, que es algo que solo es posible revisar caso por caso (persona por persona).
  2. Hay muchas razones por las que esto puede ocurrir. Deben tomarse en contexto y trabajar con la persona / personas involucradas si es razonable. ¡Tenemos el deber de intentar y ayudar a todos los programadores a convertirse en mejores programadores!
  3. En los viejos tiempos, cuando el desarrollo se realizaba con un buen bloc de notas antiguo (u otra herramienta de edición de texto simple), esto ocurría con mucha más frecuencia. Sin embargo, ahora contamos con la asistencia de los IDE modernos, por lo que, aunque no deberíamos necesariamente convertirnos en OTT al respecto, probablemente debería abordarse en cierta medida.
  4. Nosotros, como programadores, variamos en nuestros estándares, estilos y enfoques de soluciones. Sin embargo, parece que, en general, todos tomamos PRIDE en nuestro trabajo y, como rasgo, es algo que puede diferenciar a los programadores. Hacer lo mejor de nuestras capacidades, tanto interno (código) como externo (resultado del usuario final) nos ayuda a darnos esa gran palmadita en la espalda que quizás no busquemos pero que llena nuestro corazón de orgullo.
  5. Y finalmente, para citar a CrazyEddie de su publicación a continuación. No te preocupes por las cosas pequeñas
pregunta dreza 12.04.2017 - 09:31

16 respuestas

65

Tienes razón al señalar que los usuarios son lo más importante, al final. Pero este es el punto que creo que te has perdido: otros desarrolladores son usuarios de tu código. Es tan importante lo que ven como lo que ven los usuarios de su aplicación.

Ahora, si se trata de una compensación, si la mejora de su código empeoró la experiencia del usuario, entonces tendría que decirle que preste atención al grupo más grande (con suerte a sus usuarios).

Pero no es una compensación. Puedes alcanzar ambos objetivos simultáneamente. Así que hazlo.

Como nota al margen, si usted es el único desarrollador que trabajará en este proyecto (aplicaciones desechables), entonces no tiene un problema inmediato. Pero, ¿no sería mejor adquirir el hábito de ser coherente ahora que cuando estás en un trabajo con un equipo?

Hay ocasiones en que un equipo puede tomar la decisión de permitir que el código se escriba 2 (o incluso más) formas diferentes, pero eso generalmente se basa en "vamos a cambiar nuestro enfoque para todos los nuevos códigos, cambiar código cuando estamos en esa área, pero no cambiamos el código que nunca se toca hasta que queda tan poco que vale la pena hacer un proyecto ". Esos casos deben ser manejados con mucho cuidado.

EDIT : para responder a tus ediciones: en mi opinión, eso empeora las cosas. No es un caso de escritura torpe porque el IDE lo habría corregido. Parece que había otro bloque de código dentro del interior-si, que se eliminó junto con el refuerzo exterior. Esto es tan fácil de solucionar que no hay excusa para no hacerlo.

Una vez que la sangría se sale de control, el código se vuelve muy difícil de leer e incluso más difícil de depurar. No creo que estés haciendo nada.

    
respondido por el pdr 21.05.2012 - 11:56
30

Si hay algo de coherencia, trato de pasarlo por alto y seguir adelante. No hay necesidad de ser un perfeccionista. Pero si el desarrollador que escribió el código fue descuidado, es posible que él o ella no entiendan que otros desarrolladores necesitarán leer su código, y si el desarrollador no entiende los conceptos de legibilidad, esto me dice algo acerca de este desarrollador que habla volúmenes:

¡Esta persona no sabe leer el código ellos mismos!

En muchas de nuestras carreras, no necesariamente escribimos código desde cero. En lugar de repetición, reutilizamos bloques de código o consumimos API escritos por otros desarrolladores, y estos forman los componentes básicos de nuestras aplicaciones. A menudo, aprender a usar estas herramientas implica leer documentación de la API y leer ejemplos de código. Además, comprender los módulos en un proyecto desarrollado internamente, donde puede que no haya buenos API o ejemplos de código, implica la habilidad de leer cuidadosamente y comprender bloques desconocidos de código heredado, la mayoría de los cuales probablemente contienen problemas de formato y estilo en sí mismos.

Al ver a un nuevo desarrollador escribir su propio serializador JSON y preguntarle por qué no está usando Jackson o GSON, dice "Lanza errores y no funciona. ¡No tiene sentido!"

¿Por qué estaba haciendo esto?

La forma en que un desarrollador escribe su código nos dice mucho acerca de sus habilidades. Teniendo en cuenta que en la mayoría de los campos, un profesional recién formado aprende trabajando con otros profesionales más experimentados, al ver un código descuidado me indicaría que la persona que lo escribió no ha tenido la oportunidad de aprender de los demás, principalmente porque no lo ha hecho. Lo intenté.

Cuando asesoramos a nuevos desarrolladores, trabajamos en estos puntos. El desarrollador que escribió su propio reemplazo de Jackson obtuvo un nuevo respeto por la legibilidad del código cuando analizamos algunos ejemplos bien escritos de esto en acción.

Una vez que un desarrollador experimenta esto de primera mano y entiende que el trabajo implica no solo escribir código sino también leerlo, su enfoque cambia.

Joel Spolsky tiene algunos consejos de Seth Gordon sobre cómo podría acercarse a leer el código. .

Finalmente, si los desarrolladores con los que está trabajando no son nuevos y, de hecho, se les llama ingenieros superiores, es posible que desee considerar buscar trabajo en otra parte. Estos ingenieros no te respetan a ti, a tu tiempo ni a la organización para la que trabajan, y no les importa si tú o alguien más tiene que limpiar su desorden. El código mal formateado, y no me refiero a solo unos pocos subrayados faltantes, es un signo de una patología en la organización. O bien dice que no tienen experiencia, o simplemente no les importa.

    
respondido por el jmort253 21.05.2012 - 00:30
18

Sí.

Tomando un grupo de muestra de más de 50 desarrolladores con los que he trabajado, todavía tengo que encontrarme con un desarrollador que es sistemáticamente descuidado en su formato y aún así tiene un rendimiento sobresaliente en términos de corrección de código, y cumple con todos los requisitos funcionales y no funcionales. requerimientos consistentes y efectivos.

El formato descuidado es un signo de falta de atención al detalle. Esa falta constante de detalles, en todos los casos en mi experiencia personal, se ha traducido invariablemente en la misma falta de detalles en la corrección del código también.

En otras palabras, nunca me he encontrado con un gran desarrollador (alta corrección y facilidad de mantenimiento) que tenga un formato sistemáticamente descuidado.

Sobre la base de esta experiencia, uso el descuido de formateo consistente, sistemático y repetitivo como un indicador negativo del calibre del desarrollador.

    
respondido por el zooone9243 22.05.2012 - 11:18
10

Creo que, de alguna manera, en parte te estás preguntando la pregunta incorrecta. ¿Es el código legible? ¿Puedes entender lo que se supone que debe hacer de un vistazo?

El formato del código es algo que permite que las personas que no están familiarizadas con su código se sientan cómodas. En cierto modo, esto es algo bueno, es posible que mire el código de otra persona y que se sienta similar ... cómodo. Algunos idiomas (por ejemplo, Python) requieren un cierto grado de formato para funcionar correctamente. En otras formas, el formato del código es una distracción en la que el lenguaje en sí no depende realmente de él. ¿Realmente te importa si tus métodos están correctamente encapsulados, o si tus variables privadas comienzan con un guión bajo, o incluso si tus métodos públicos y privados están en algún tipo de orden específico?

Esto me lleva de nuevo al tema de la legibilidad. Su tarea es codificar los requisitos y comunicar lo que ha hecho al siguiente desarrollador que modificará el código después de usted. Mantener el código en buen estado, con una buena carcasa de camello y nombres consistentes puede ayudar con esto hasta cierto punto, pero diría que la atención está en los detalles de lo que hace en el código mismo. Mantener sus métodos cortos, nombrar todos los elementos de su código de manera descriptiva y eliminar la duplicación puede hacer una gran diferencia que si le preocupa si debe colocar el corchete en la siguiente línea o si ha sangrado de manera consistente. Estos problemas de formato se vuelven más importantes cuando el código es largo y difícil de analizar por el lector rápidamente.

Lo que quiero decir es que es probable que tu código ya esté en problemas si estás en la etapa de preocuparte por el formato del formato. Dicho esto, si el formato le molesta, le costará muy poco arreglar las cosas a medida que avanza, siempre que esté dentro del alcance del trabajo que se supone que debe hacer en ese momento.

Entonces, ¿todo esto es la selección de liendres o un signo de un codificador descuidado? Eso depende en gran medida de su punto de vista. Personalmente no lo creo. Tal vez podría verse como un signo de pereza o poca atención a los detalles, pero si el código funciona y pasa todas sus pruebas, entonces podría preguntarse qué tan "descuidada" es realmente la codificación. Por otro lado, si a alguien más le resulta difícil leer su código, esto podría ser una señal de que su código puede ser difícil de mantener, y eso en sí mismo podría ser motivo de preocupación.

Si está trabajando dentro de un equipo, o si es probable que deje su código para ser mantenido por otra persona, entonces creo que es mejor mantener su código limpio y ordenado, legible y fácil de entender. Es posible que las reglas de formato y el estilo deban discutirse en grupo y establecer algunas pautas o codificarlas en una herramienta de verificación de código (como StyleCop para C #, por ejemplo). Si se trata de un proyecto personal y los demás nunca lo cuidarán, entonces el punto es discutible, aunque diría que es mejor practicar las buenas técnicas de codificación limpia como un hábito en lugar de algo que haces ocasionalmente.

    
respondido por el S.Robins 21.05.2012 - 00:32
9

No puedo dejar de pensar que la codificación tiene que ver con los detalles. Cada detalle de nuestro código es importante: para la corrección, para la legibilidad, para la extensibilidad, para el mantenimiento.

Si bien los ejemplos dados no son desastrosos en sí mismos, para mí hablan de una falta de atención a los detalles que consideraría preocupantes, especialmente en una herramienta como Visual Studio que ofrece mucha ayuda, uso Ctrl + K , Ctrl + D casi tan habitualmente como Ctrl + S

Trabajo con un programador que es igualmente descuidado (y también ignora flagrantemente nuestros estándares de codificación con cosas como la ausencia de espacios en blanco entre los métodos y los nombres de los métodos privados en minúsculas) y con el tiempo nos hemos dado cuenta de que tenemos que mantenernos muy Preste atención a su trabajo, ya que este descuido se extiende a su diseño y prueba, y hemos tenido que hacer un esfuerzo considerable "ordenando" detrás de él.

    
respondido por el HappyCat 21.05.2012 - 13:05
4

Creo que es una señal de que el desarrollador no estaba usando las herramientas disponibles para ellos. Si está utilizando una herramienta como IntelliJ Idea para Java, o cualquiera de los otros IDE con todas las funciones disponibles en el momento, hacen que sea tan fácil escribir código limpio que es tan fácil o más fácil hacerlo.

El problema de ser relajado en su formato es el que se comentó, en la publicación original, es probable que otras personas que lean su código sean escépticas con respecto a la calidad del resto del código. Más importante aún, hace que el código sea más difícil de mantener una vez que se convierte en código heredado.

Si estuviera haciendo una revisión de código, podría vivir con el espacio inconsistente entre los operadores, pero probablemente fallaría la revisión debido a la sangría inconsistente y la asignación de nombres de variables. Especialmente cuando un atajo de teclado lo formateará si está utilizando un IDE. Creo que cuando se trabaja como parte de un equipo, es importante que todos utilicen las mismas herramientas y convenciones para evitar el mapeo mental tanto como sea posible.

Sugiero que, como prueba, intente colocar parte de ese código como parte de una pregunta en el Desbordamiento de pila o como una Revisión en la versión beta de revisión de código y ver qué otros comentarios recibe.

    
respondido por el Klee 21.05.2012 - 00:41
4

Algunas consistencias son más importantes que otras.

Las inconsistencias en la sangría pueden ser el resultado del uso de diferentes plataformas / herramientas. ¿Estás sangrando con espacios o pestañas? Cuantos espacios ¿Dónde están las pestañas?

A principios de los 90, las personas usaban pestañas para reemplazar 8 espacios y sangraban 2 o 4 espacios. (En realidad, yo prefería 3). Así que algunos equipos acordaron usar solo las pestañas y luego establecer sus tabulaciones donde quisieran. Por supuesto, esto más tarde causó problemas ya que otras herramientas reemplazaron automáticamente las pestañas con espacios o viceversa. Ahora casi todos usan espacios para que al menos todos vean lo mismo.

Si desea ponerse rígido con respecto al formato, puede usar Checkstyle para aplicar las reglas que desee.

Personalmente, soy coherente con algunas cosas en Java, como los nombres de los paquetes son minúsculas, los nombres de las clases comienzan con mayúsculas (y nada más) y otras prácticas comunes de estilo Java. Por otro lado, no soy tan coherente con respecto a si utilizo o no llaves en una instrucción if cuando no tengo que hacerlo. Generalmente pongo espacio alrededor de los operadores aritméticos, pero no lo haré en algunos casos, particularmente si es la diferencia entre hacer la línea demasiado larga o no.

Las diferencias que veo:

  • ¿Las inconsistencias hacen que el código sea más difícil de leer?
  • Las inconsistencias hacen que sea más difícil de recordar o entender los puntos importantes.
  • ¿La construcción lleva a errores más fácilmente pasados por alto?

Ser consistente con el uso de mayúsculas hace que sea muy fácil distinguir de un vistazo la diferencia entre un nombre de clase y una variable. Ser inconsistente rompe eso sin una buena razón, y por eso es muy malo.

Probablemente no sea un problema ser inconsistente con respecto al espaciado alrededor de los operadores aritméticos.

No usar llaves con una instrucción if puede ser peligroso, ya que si agrega una segunda declaración a la cláusula then sin agregar también llaves, la segunda declaración puede parecer que forma parte de la cláusula then pero en realidad no lo es. El hecho de no usar llaves puede, de hecho, ser considerado descuidado. No tengo otra defensa que no sea la que guarda una línea, lo que hace que el código sea más compacto, que es débil, especialmente porque siempre puse else en una nueva línea en lugar de ponerlo en la misma línea que la llave de cierre del "entonces" cláusula.

Los programadores se extienden en sus estilos. Algunos de los programadores más ingeniosos y creativos utilizan una estricta rigidez de estilo como una forma de liberar recursos mentales. (Una vez vencí a un gran maestro de ajedrez en una exhibición de 60 personas haciendo que renunciara simplemente orientando a mis caballeros para que se enfrentaran a él. Quería verlos de perfil). Otros, como yo, sienten que la rigidez a cualquier nivel inhibe La creatividad y la irritación y las reglas que no son demostrablemente importantes.

Como suele ser el caso, generalmente es mejor encontrar algún tipo de medio feliz.

    
respondido por el Old Pro 21.05.2012 - 02:49
2

Mi opinión es que la mayoría de las personas son bastante consistentes en el uso de espacios en blanco, guiones bajos, etc., por el mismo motivo que escriben correctamente las palabras, usan la puntuación de manera constante, usan el cinturón de seguridad, se cepillan los dientes y comienzan por el mismo lado. , y así. Cuando haces algo con regularidad, te acostumbras a hacerlo de cierta manera y lo haces sin pensarlo mucho.

En este momento, sin mirar el código que he escrito recientemente, no puedo decir si normalmente escribo foo = bar; o foo=bar; , pero estoy bastante seguro de que lo escribo de la misma manera cada vez . (De hecho, puedo decirle ahora que hago lo primero: escribir el primer ejemplo fue rápido, pero tuve que pensar para evitar escribir espacios alrededor del = en el segundo ejemplo).

Si vi a alguien escribiendo un código que era muy inconsistente en la forma en que estaba formateado, no necesariamente supondría que fueran tan descuidados como uno de los siguientes:

  • no tenían experiencia y aún no habían desarrollado un estilo automático;

  • no habían escrito mucho código recientemente

  • tenían problemas con algún otro aspecto del código que lleva a muchas ediciones de prueba y error

  • el código en cuestión se escribió hace un tiempo y fue editado por varias personas durante su vida útil

De su pregunta no queda claro si está hablando de su propio código o del de otra persona. Si es suyo y le preocupa cómo se refleja en usted, entonces es algo en lo que debe trabajar en las próximas semanas. Dedique un poco de tiempo a descubrir cómo desea que se vea su código (de acuerdo con los estándares de codificación de la empresa) y luego preste especial atención a medida que escribe el código en las próximas semanas. Si realmente se está quejando de uno de sus compañeros de trabajo, entonces es mejor que no lo moleste y permita que su gerente lo aborde si es un problema para el equipo. Si es amigable con la persona en cuestión, puede sugerirle usar una herramienta para formatear el código. Muchos IDE proporcionan ayuda para el formateo, y hay muchas impresoras y formateadores de código bonitos (por ejemplo, Uncrustify) que pueden ayudar.

    
respondido por el Caleb 21.05.2012 - 01:24
2

Definitivamente deberías hablar con él sobre esto.

Para mí, el código correctamente formateado es muy importante. Me permite ver rápidamente la estructura en un programa, encontrar posibles fallas, lo que sea. Cuando hay un código que es solo una pantalla de texto con muy poco espacio, es mucho más difícil de leer que cuando se divide en bloques lógicos y algunos espacios entre los operadores, etc.

Los guiones bajos en las variables privadas son algo importantes: es bueno tener una forma de identificar rápidamente una variable global, por lo que al buscar un problema, instantáneamente sabes que probablemente no esté contenido en ese método en particular.

Como han dicho otros, si un desarrollador no está preocupado por lo legible que es su código, hay un problema. Probablemente tendrá que leerlo él mismo más tarde, y es muy probable que no recuerde lo que el código hace de memoria. Quizás aún no haya trabajado en un gran proyecto, donde este es un problema mayor que en proyectos pequeños.

Recuerdo que las personas en las clases de programación me pedían ayuda, y de vez en cuando tenía que decirles que formatearan su código antes de que pudiera comenzar a ver lo que está mal. Es increíble ver cuánta gente piensa que la sangría y la correcta asignación de nombres de variables no son importantes.

    
respondido por el Ben F 21.05.2012 - 12:05
2

Imagine a un carpintero construyendo una gran pieza de madera, dejando todas las herramientas repartidas por toda la mesa de trabajo, de una manera desordenada, mientras construye esta gran obra de arte de madera. Ahora imagine que el carpintero se enferma y otro carpintero viene para terminar la pieza de madera. Cuando ve todo el desorden a su alrededor, pierde tiempo y paciencia para organizar todo a su alrededor para que pueda comenzar a terminar la pieza de la manera que mejor sabe. Al final, la pieza de madera es grande, hermosa, brillante y el cliente la compra.

Ahora cambie el carpintero por un desarrollador de software.

Creo que la lección importante aquí es la satisfacción del cliente con el producto de software, pero también es importante cómo los desarrolladores trabajan juntos y usan correctamente las herramientas disponibles que tienen y están organizados para que todos puedan trabajar de manera rápida y productiva con los otros trabajan.

Creo que cada desarrollador debe ser perfeccionista, ama lo que está haciendo para que pueda divertirse resolviendo los problemas de los clientes y deje una mesa de trabajo limpia (sangría adecuada, uso correcto de nombres de variables, excelente documentación, etc.) .) para que otros utilicen y mejoren su trabajo.

    
respondido por el Miguel Rentes 21.05.2012 - 13:03
2

No creo que la consistencia sea realmente el problema: es si el código leído por otro programador o no transmite con precisión la función del código. Eso depende del contexto.

La idea de que las llaves deben coincidir o que el nombre de una variable sea indicativo de su propósito es bastante universal. Entonces, alguien que escribe llaves que no se alinean o que da nombres de variables que son contrarios a su propósito está transmitiendo información falsa. Eso es malo: aunque el código pueda funcionar, también podría ser el resultado de errores equilibrados. Es frágil e inestable.

Por otro lado, la forma en que las variables se capitalizan y lo que eso significa es mucho más variada. Depende de las convenciones del lenguaje, la plataforma, el entorno de desarrollo y, sobre todo, de las convenciones del equipo de programación. Si no hay convenciones consistentes, si no se ha escrito nada que diga "así es como debe hacerse", entonces no hay razón para esperar un código consistente. En otras palabras, si una práctica estilística particular no tiene significado en un contexto dado, entonces la inconsistencia tampoco tiene significado.

De los cuatro ejemplos originales, diría que las variaciones en 1, 2 y 4 solo son significativas si a esos elementos se les han dado significados bien establecidos en primer lugar. Solo el # 3 tiene un significado bastante universal e incluso entonces solo sería crítico si la alineación estuviera lo suficientemente lejos como para ser realmente engañosa.

Se podría argumentar que un buen programador debe tener un estilo coherente incluso en ausencia de un estilo impuesto desde el exterior, pero creo que es una suposición falsa. Un buen programador debe poder adaptarse a las reglas que se les dan, y esas reglas cambiarán a medida que se mueven de un proyecto a otro. Entonces, si hay una inconsistencia en la ausencia de reglas, es la ausencia de reglas, no la inconsistencia, la responsable de cualquier problema de legibilidad.

    
respondido por el Seth Noble 21.05.2012 - 16:17
2

Llego tarde a la pregunta, pero merece esto: el código de computadora es la expresión de la intención del desarrollador. Si el desarrollador no está expresando o no puede expresar su intención tanto para el compilador como para el siguiente humano para mantener su código, entonces no está haciendo su trabajo.

Si el código 'descuidado' hace que la intención del desarrollador sea menos clara o incluso da la impresión de una intención diferente, entonces es un problema. En algunos casos será un problema para el compilador, en otros casos será un problema para el mantenedor. Pero sigue siendo un problema, ya que no necesitamos que el mantenedor "arregle" la intención y luego introduzca errores porque la "solución" estaba equivocada.

    
respondido por el dotancohen 27.06.2013 - 18:07
2

En palabras sencillas:

El software realmente bueno solo se puede construir sobre bases sólidas. El código limpio y consistente es una de esas bases.

La abstracción continua de la complejidad es lo que permite a los programadores hacer cosas cada vez mejores.

¿Cómo puedes hacer cosas cada vez más grandes si tienes que hacer frente todo el tiempo para codificar la inconsistencia?

La inconsistencia del código agrega su propia complejidad a los problemas del dominio.

Además, ser consistente requiere menos esfuerzo general que al revés.

  

Cualquier tonto puede escribir código que una computadora pueda entender. Bueno   Los programadores escriben código que los humanos pueden entender. (M. Fowler)

    
respondido por el Tulains Córdova 27.06.2013 - 18:34
1

Hay muchas razones por las que las cosas de las que te quejas pueden pasarle a un desarrollador perfectamente bueno.

  

Algunos ejemplos de inconsistencias podrían ser:

     

A veces nombra variables privadas con _ y otras veces no

Ese es un poco molesto. Lo he hecho antes. Quizás estén en un estado intermedio de ver si postfix _ es algo que quieren usar.

  

A veces   con sangrías variables dentro de los bloques de código

     

No alineando los tirantes hacia arriba   es decir, la misma columna si se usa comenzar usando un nuevo estilo de línea

Cualquiera de estos puede ser atribuido al codificador usando un editor que hace cosas por ellos. A veces esos editores hacen algo raro y nunca se sabe.

También puede haber sido editado en múltiples editores y / o por varias personas. Además, tal vez sea TU editor el que muestre el código incorrecto.

  

No espaciado   siempre coherente con los operadores, es decir, p = > p + 1, p + = 1 frente a otras veces p   = > p + 1 o p = > p + 1 etc

Error tipográfico, diferentes requisitos de formato para diferentes condiciones, etc ...

No te preocupes por las cosas pequeñas. Revise estas cosas, pero no son una señal importante de un mal desarrollador, no.

    
respondido por el Crazy Eddie 21.05.2012 - 03:10
1

Un programador amigo mío tiene dislexia. No tiene dificultad con el pensamiento lógico, o con escribir código que sea funcional, elegante, bien probado, todo lo que razonablemente podría esperar de un desarrollador decente. Pero difícilmente puede escribir para salvar su vida, y simplemente no nota las inconsistencias en la ortografía y el formato tanto como otras personas, porque su mente es mejor para prestar atención a otros tipos de detalles.

Ese es el extremo lejano del espectro, pero debe comprender que, si bien los desarrolladores deben estar orientados a los detalles, no todos los desarrolladores están orientados a los detalles de la misma manera , especialmente cuando se trata de aspectos de El código que no afecta su funcionamiento real.

Línea inferior: si desea un código estándar, ejecute autoformato y continúe con cosas más importantes.

    
respondido por el Jon Purdy 21.05.2012 - 19:44
1

Supongo que depende de los estándares de la organización. Si no tiene algunas pautas de formato, trataría de incluirlo en la agenda si fuera usted.  Una vez que se acuerda un estándar, puede usar la función de formato de su editor preferido para asegurarse de que todos usen el mismo estándar. (incluso puede usar lo que le gusta antes de enviarlo en sentido ascendente si aplica la herramienta de formato antes de enviar el código a su servidor de control de fuente)

Con respecto a sus preocupaciones sobre sus estándares si su código no tiene el formato correcto: creo que podría ser un indicador de cuánta atención presta a los detalles. Si crees que este es el caso, podría ser algo para discutir, pero esto también puede quedar atrapado en las revisiones de código y el puede obtener comentarios significativos de los que puede aprender. preocuparse por el estilo del código solo es como ponerle la función a la función. Si escribe código descuidado, es probable que también aparezca en sus métricas de calidad, por lo que el estilo de código por sí solo no merece la pena preocuparse, hay herramientas para eso.

    
respondido por el Onno 22.05.2012 - 10:50

Lea otras preguntas en las etiquetas