Declaraciones de línea única y buenas prácticas

11

Recientemente adquirí un hábito que sé que muchos de ustedes pueden desaprobar, pero que, al final, me ayuda a vigilar la estructura del código global en lugar de la estructura de un método repetitivo único (a veces): agrupar un número de declaraciones en una sola línea, como esta:

textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!";

Opuesto a

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

Solía hacerlo para tareas repetitivas para mantener la "belleza" general del código y para ayudarme a rastrear la estructura del programa fácilmente, pero admito que puede no ser una buena práctica. De hecho, lo uso mucho, así que me gustaría saber qué piensa sobre esto. Además, ¿cree que alguien que alguna vez tenga que mantener mi código tiene problemas con este enfoque?

coding-style

— Usuario
fuente

55

Esta podría ser una buena pregunta para codereview.stackexchange.com

1

Tendré problemas si tuviera que mantener. Lo primero que haría es hacer un CTRL + F para ";" y poner un salto de línea Pero solo soy yo :-). Me gusta una línea solo si tengo una razón para, por ejemplo, inicializar las propiedades habilitadas de algunos cuadros de texto con un valor predeterminado de falso: textBox1.Enabled = textBox2.Enabled = false;

— Arun

2

Si está haciendo una pregunta de estilo de codificación, sería útil si especificara el idioma.

— Caleb

3

Si bien puede no surgir en el ejemplo dado, ¿cómo vas a poner un punto de interrupción en la segunda o tercera o ... declaración si los estás poniendo todos en una línea?

— Marjan Venema

1

Y también, estoy acostumbrado al formato automatizado (Java), donde el código tiene una apariencia uniforme de todos modos.

— Kwebble

22

Realmente creo que la legibilidad sufriría mucho tanto para usted como para cualquier otra persona que lea el código. Todo tiene sentido cuando lo escribes la primera vez porque está activamente en tu mente. Es diferente cuando escanea el código para ver qué variables y funciones están donde ... está destruyendo su propia capacidad de escanear su propio código. Eso es un gran no-no, y más allá de malo si cualquier otra persona siempre tiene que leer su código.

Además, piense en cómo lee el código. Siempre es de arriba hacia abajo, desplazándose hacia abajo. Su método no encaja con esto, e incluso presenta uno de los problemas más feos posibles en la lectura de código; desplazándose horizontalmente . Nunca subestimes lo difícil que puede ser la lectura del código. Nunca te desplazas horizontalmente, nunca haces que las personas se desplacen horizontalmente, en casi cualquier contexto es extremadamente antinatural.

Además, si su problema es la entrada de código repetitiva ... no olvide Ctrl-C. Desde su código de ejemplo, podría ser más eficiente escribir todo manualmente, pero si tiene que copiar varias líneas varias veces, parece que sería igual de eficiente copiar la línea uno más una nueva línea, péguela x veces y hacer los cambios, es menos probable que también se cometa un error tipográfico.

Ah, y errores tipográficos! Dañar la legibilidad de su código de esa manera puede hacer que sea una pesadilla encontrar cuál de las 50 declaraciones de variables establece incorrectamente. La mayoría de los compiladores dan errores en los números de fila Y columna ahora, pero encontrar un error en una fila es MUCHO más fácil que encontrar una columna.

— Ben Brocka
fuente

2

a) Código de lectura / escaneo: la mayoría de las personas al escanear el código leen los primeros caracteres de la línea y luego continúan a menos que sea "interesante", luego leen un par más. Errores del compilador: la mayoría de las veces interpreto el error del compilador como "Problema con la línea <x>". solo si no puedo; resolverlo al instante (raro), así que realmente leí el error.

— mattnz

19

Una declaración por línea también facilita ver lo que ha cambiado en una diferencia de lado a lado.

— Hugo
fuente

2

Esta es probablemente la razón más importante, si alguien tiene que fusionar ese código, casi todas las herramientas de fusión harán que sea más fácil aislar y mover líneas en lugar de subcadenas de filas.

— anon

@anon Buen punto sobre las herramientas de fusión también; una declaración por línea significa menos conflictos de fusión para limpiar.

— Hugo

10

Si bien el ejemplo no muestra esto, hay otro problema con la agrupación de varias declaraciones en una línea. ¿Qué sucede si una de las cinco declaraciones que tiene en una sola línea arroja una excepción?

Su seguimiento de la pila dirá "EBlah en la línea N" ... y ahora no tiene idea de cuál de esas cinco declaraciones arrojó la excepción.

(Lo mismo sucede con una declaración excesivamente larga de cualquier tipo).

— Frank Shearar
fuente

2

El mismo concepto se aplica a la depuración, donde una vez más la granularidad es típicamente un número de línea.

— David Hammen

2

Oh, sí, esto puede ser un problema. Un "favorito" es cuando se suelta un puntero nulo en algo como foo.bar[grill.boo].flip.flap[flop].mickey(minnie).marshmallow(sintaxis Java / C #). Ordenar ese tipo de desorden siempre es mejor con líneas adicionales (y variables temporales ... y un Brick Of Clue 2D6 para el desarrollador original).

— Donal Fellows

7

Una declaración por línea es un estilo de codificación ampliamente utilizado. Como resultado, la mayoría de los desarrolladores que miran su código en el futuro probablemente se estremecerán cuando vean varias declaraciones por línea. Cuando estás acostumbrado a ver algo de una manera, puede ser desorientador verlo de otra manera.

Por esta razón, aconsejo no hacerlo, excepto en circunstancias excepcionales.

— Igby Largeman
fuente

4

La última vez que hice esto fue hace 25 años usando lenguajes interpretados en micros pequeños que se ejecutan con bajas velocidades de reloj, donde cada espacio o retorno de carro eliminado dio un aumento en el rendimiento.

Ahora me estremezco al pensar en ello (aunque se hizo por una buena razón).

Lamentablemente, dicho código es difícil de leer y, por lo tanto, difícil de mantener.

— rápidamente_ahora
fuente

1

Así que lo escribe correctamente, luego elimina espacios en blanco y cualquier otra preparación para su "copia de máquina". Justo como minificar javascript hoy en día.

— CaffGeek

1

Sí, también escribí un programa para reprocesar el código fuente como ese, en 1986. Otra cosa que espero no tener que volver a hacer nunca más.

— rapid_now

1

Sintácticamente, realmente no hay nada de malo en ello. Realmente depende del estilo de codificación de su equipo.

Como la mayoría del código que he visto (incluido el código que está dentro de los encabezados estándar de c ++) se realiza de esta manera, elegiría su primer método.

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

— Jorge el curioso
fuente

0

Este es un estilo de codificación realmente inusual.

En su lugar, le recomendaría usar líneas vacías para delimitar partes lógicas de código.

— svick
fuente

0

Ir demasiado lejos hacia la derecha puede crear tantos problemas como múltiples líneas.

He tenido que lidiar con algunas declaraciones SQL con docenas de campos. Normalmente, pondría uno por línea, pero en algunas ocasiones, he consolidado 3 o 4 en una fila. Esto parece una buena idea durante el desarrollo cuando tienes que desplazarte hacia arriba y hacia abajo varias veces.

Lamento volver a este código. Tener filas adicionales simplemente no parece crear un gran problema, por lo que generalmente lo limpio.

— JeffO
fuente

0

Además, ¿cree que alguien que alguna vez tenga que mantener mi código tiene problemas con este enfoque?

Después de poner sus manos sobre su cabeza por un minuto, usará sus funcionalidades IDE Regex favoritas para separar automáticamente todo ese código ilegible en una declaración por línea.

Solo un vistazo rápido al ejemplo que mostró es suficiente para comprender cuánto más legible es el segundo enfoque.

Es mucho más fácil seguir el flujo vertical de la página, sin tener que mover los ojos horizontalmente para siempre.

Mire su ejemplo: inmediatamente sabe que el código tiene que ver con la Textpropiedad de diferentes textBoxobjetos, y contienen cadenas como valores. Muy claro.

— Jose Faeti
fuente

0

Yo personalmente no usaría ese estilo. Para resumir

Pros

menos líneas de código para desplazarse
se puede usar para agrupar semánticamente el código para expresar: "muchas cosas de asignación". PERO siempre puedes refactorizar dicho bloque en una función si te molesta demasiado.

Contras

difícil de leer, generalmente es más fácil leer el código horizontalmente (descremado, sin movimiento ocular, ...)
diff se convierte fácilmente en una pesadilla, incluida la fusión
más difícil de cambiar (copiar y pegar, comentar, ...)
la depuración puede ser un problema en muchos IDE, ya que funcionan en líneas en lugar de expresiones individuales.

— Mar
fuente

Algunas de las "desventajas" a veces pueden ser profesionales. Por ejemplo, supongamos que un fragmento de código tiene ocho operaciones consecutivas del formulario if (x > maxX) {x=maxX; peggedAny = true;}. Si cada una de estas operaciones encaja fácilmente en una sola línea, preferiría tener ocho líneas como esa que docenas de líneas que dividen las declaraciones. Si tales comparaciones se usaran en suficientes lugares, cuatro declaraciones del formulario peggedAny |= pegValueMinMax(ref x, minX, maxX);podrían ser mejores, pero alguien que lea eso tendría que leer pegValueMinMaxpara ver qué hace.

— supercat

Además, si una pequeña parte de una línea cambia, un "diff" lo considerará como un cambio en toda la línea. Si la línea se comportara funcionalmente como una unidad, eso sería algo bueno. De lo contrario, si una operación semántica se divide entre varias líneas, los cambios en algunas líneas podrían afectar la operación de maneras que no serían evidentes.

— supercat