¿Debo usar identificadores de bloque ("end;") en mi código?

Question

Code Complete dice que es una buena práctica usar siempre usar identificadores de bloque, tanto por claridad como como medida defensiva.

Desde que leí ese libro, he estado haciendo eso religiosamente. A veces parece excesivo, como en el caso a continuación.

¿Steve McConnell tiene razón al insistir en usar siempre identificadores de bloque? ¿Cuál de estos usarías?

//naughty and brief 
with myGrid do 
    for currRow := FixedRows to RowCount - 1 do 
    if RowChanged(currRow) then 
     if not(RecordExists(currRow)) then 
     InsertNewRecord(currRow) 
     else 
     UpdateExistingRecord(currRow); 

//well behaved and verbose 
with myGrid do begin 
    for currRow := FixedRows to RowCount - 1 do begin 
    if RowChanged(currRow) then begin 
     if not(RecordExists(currRow)) then begin 
     InsertNewRecord(currRow); 
     end //if it didn't exist, so insert it 
     else begin 
     UpdateExistingRecord(currRow); 
     end; //else it existed, so update it 
    end; //if any change 
    end; //for each row in the grid 
end; //with myGrid 

Answer 1

Personalmente, prefiero el primero, como en mi humilde opinión el "final"; no me digas mucho, y una vez que todo está cerca, puedo decir por la identación qué sucede cuando.

Creo que los bloques son más útiles cuando se tienen declaraciones grandes. Podría hacer un enfoque mixto, donde inserte unos pocos "comenzar ... fin" y comente lo que están terminando (por ejemplo, utilícelo para el con y el primero si).

mi humilde opinión también se puede romper esto en más métodos, por ejemplo, la parte

if not(RecordExists(currRow)) then begin 
    InsertNewRecord(currRow); 
    end //if it didn't exist, so insert it 
    else begin 
    UpdateExistingRecord(currRow); 
    end; //else it existed, so update it 

podría estar en un método separado.

Answer 2

Siempre he estado siguiendo el estilo 'de buen comportamiento y verbosa', excepto aquellos comentarios adicionales innecesarias de los bloques extremos.

De alguna manera tiene más sentido poder ver el código y darle sentido a él más rápido, que tener que pasar al menos un par de segundos antes de descifrar qué bloque finaliza.

Consejo: estudio KB atajo visual para C# salto comienzan y terminan: Ctrl +]

Si utiliza Visual Studio, y luego tener las llaves para C# al principio y al final del bloque de ayuda también por el hecho que tiene un atajo de KB para saltar al principio y al final

Answer 3

Usaría lo que mi empresa haya establecido para sus estándares de codificación.

Dicho esto, preferiría usar el segundo bloque, más detallado. Es mucho más fácil de leer. Sin embargo, podría dejar de lado los comentarios de final de bloque en algunos casos.

Answer 4

Si mal no recuerdo, CC también dio algunos consejos sobre los comentarios. Especialmente sobre no reescribir lo que hace el código en los comentarios, pero explicando por qué hace lo que hace.

Answer 5

Yo diría que tiene razón por el hecho de que el código todavía se puede interpretar correctamente si la sangría es incorrecta. Siempre me gusta ser capaz de encontrar los identificadores de inicio y final de bloque para bucles cuando hojeo el código, y no confío en la sangría apropiada.

Answer 6

Nunca es siempre de una manera u otra. Como confío en mí mismo, usaría el estilo más corto y más escueto. Pero si se encuentra en un entorno de equipo en el que no todos tienen la misma habilidad y la capacidad de mantenimiento es importante, es posible que desee optar por lo último.

Answer 7

El identificador de bloque no solo es más fácil de leer, son mucho menos propensos a errores si está cambiando algo en la lógica if else o simplemente agrega una línea y no reconoce que la línea no está en el mismo bloque lógico que el resto del código.

Usaría el segundo bloque de código. El primero se ve más bonito y más familiar, pero creo que es un problema del lenguaje y no de los identificadores de bloque

Si es posible, utilizo el estilo de comprobación para asegurar que se usan corchetes.

Answer 8

comentando al final es realmente muy útil para los idiomas en HTML, como también lo hacen el código C con malformaciones como una sucesión infinita de if/else/if/else

Answer 9

frecuentes // comentarios al final de las líneas de código (por su bien Ejemplo de Behaved and Verbose) hace que el código sea más difícil de leer en mi humilde opinión: cuando lo veo, termino escaneando los comentarios "obvios" de algo especial que normalmente no está allí.

prefiero comentarios sólo cuando lo obvio no es (es decir, en general y/o funcionalidad única)

Answer 10

Creo que depende un poco de la situación. A veces simplemente tienes un método como este:

void Foo(bool state) 
{ 
    if (state) 
     TakeActionA(); 
    else 
     TakeActionB(); 
} 

No veo cómo hacer que parezca esto:

void Foo(bool state) 
{ 
    if (state) 
    { 
     TakeActionA(); 
    } 
    else 
    { 
     TakeActionB(); 
    } 
} 

Mejora de la legibilidad en absoluto.

Answer 11

Mi reacción instintiva sería la segunda lista (con los comentarios repetitivos eliminados del final de las líneas, como todo el mundo ha estado diciendo), pero después de pensarlo más profundamente iría con la primera más una o dos líneas de comentarios útiles de antemano que explican lo que está sucediendo (si es necesario). Obviamente en este ejemplo de juguete, incluso el comentario antes de la respuesta concisa probablemente no sea necesario, pero en otros ejemplos podría serlo.

Tener menos (pero todavía legible) y fácil de entender código en la pantalla ayuda a mantener el espacio de su cerebro libre para futuras partes del código IMO.

Answer 12

Soy un desarrollador de Python, por lo que no veo la necesidad de identificadores de bloque. Estoy bastante feliz sin ellos. La sangría es un indicador suficiente para mí.

Answer 13

Estoy con aquellos que prefieren un código más conciso.

Y parece que preferir una versión detallada a una concisa es más una elección personal, que una conveniencia universal. (Bueno, dentro de una empresa puede convertirse en una regla (mínima) universal.)

Es como paréntesis excesivos: algunas personas lo prefieren como (F1 and F2) or ((not F2) and F3) o (A - (B * C)) < 0, y no necesariamente porque no conocen las reglas de precedencia. Es más claro para ellos de esa manera.

Answer 14

Voto por un medio feliz. La regla que usaría es usar las palabras clave de horquillado cada vez que el contenido tenga múltiples líneas. En la acción:

// clear and succinct 
with myGrid do begin 
    for currRow := FixedRows to RowCount - 1 do begin 
    if RowChanged(currRow) then begin 
     if not(RecordExists(currRow)) 
     InsertNewRecord(currRow); 
     else 
     UpdateExistingRecord(currRow); 
    end; // if RowChanged 
    end; // next currRow 
end; // with myGrid 

Answer 15

Personalmente recomiendo siempre utilizando identificadores de bloques en los idiomas que los apoyan (pero siga las normas de codificación de su empresa, como sugiere @ Muad'Dib).

La razón es que, en idiomas no-Pythonic, el espacio en blanco es (generalmente) no significativo para el compilador pero es para humanos.

Así

with myGrid do 
    for currRow := FixedRows to RowCount - 1 do 
    if RowChanged(currRow) then 
     Log(currRow); 
     if not(RecordExists(currRow)) then 
     InsertNewRecord(currRow) 
     else 
     UpdateExistingRecord(currRow);    

parece hacer una cosa pero hace algo bastante diferente.

Sin embargo, eliminaría los comentarios al final de la línea. Use un IDE que resalte bloques. Creo que Castalia hará eso para Delphi. ¿Con qué frecuencia lees los códigos impresos?