¿Cómo formatea sus declaraciones compuestas en Delphi y C#?

Question

Como mucho tiempo Pascal y desarrollador de Delphi, que siempre se alinean mi comenzar y termina así:

begin 
    if x = y then 
    begin 
    ... 
    ... 
    end 
    else 
    for i := 0 to 20 do 
    begin 
     ... 
     ... 
    end; 
end; 

Lo que me impulsa los frutos secos es código con formato de este modo:

begin 
    if x = y then begin 
    ... 
    ... 
    end 
    else 
    for i := 0 to 20 do begin 
     ... 
     ... 
    end; 
end; 

Cuando hay algunos niveles de declaraciones compuestas me resulta difícil de leer. El código anterior está bien, porque no es tan complicado, pero para ser coherente, prefiero que todo comience y termine alineado.

Cuando empiezo a usar C#, me encuentro alineando las llaves también. ¿Cuál es la norma en el mundo de C#?

Editar:

Alguien ha señalado que este es el tipo de pregunta que no debe plantearse en el SO. No veo por qué no. Estoy en proceso de configurar un documento de pautas de codificación. Sé que obtendré cierta resistencia a ciertas cosas, espero obtener algunas respuestas aquí, así puedo estar preparado para enfrentar esa resistencia de frente.

Answer 1

Todos tienen diferentes preferencias. En mi caso, aprendí Modula-2 antes de aprender Pascal. Modula-2 no tiene una palabra clave BEGIN y un END requerido para cada bloque. Así código podría tener este aspecto (Modula-2 pasa a ser entre mayúsculas y minúsculas con las palabras clave en mayúsculas):

IF x = y THEN 
    .... 
END; 

Cuando empecé a codificar en Pascal, esto se convirtió en:

if x = y then begin 
    .... 
end; 

De esta manera, el el código se parecía más a lo que estaba acostumbrado a ver, sin dejar de estar dentro del dominio del código aceptable de Pascal.

Para mí, estas primeras impresiones han influido en mi estilo preferido de corsé y hendidura para prácticamente todos los demás idiomas con los que he trabajado. No existe realmente ninguna "norma" particular para el código C#, así como tampoco hay ninguna para C o Pascal.

La única regla real a seguir es la siguiente: Cuando trabaje con un código existente, utilice el estilo que ya existe. Cuando trabaje en un código nuevo, use su estilo preferido.

Answer 2

Esto se preguntó antes. por ejemplo c-coding-standard-best-practices.

Answer 3

Nunca escribiría el código (su segundo ejemplo) de esa manera. Sería ya sea (preferido)

begin 
    if x = y then begin 
    ... 
    end 
    else begin 
    for i := 0 to 20 do begin 
     ... 
    end; 
    end; 
end; 

o

begin 
    if x = y then begin 
    ... 
    end 
    else for i := 0 to 20 do begin 
    ... 
    end; 

final;

A veces utilizo tal colapso (como en el segundo caso) para combinar si y intento ... por último.

x := GetMeTheObject; 
if assigned(x) then try 
    ... 
finally FreeAndNil(x); end; 

Answer 4

Solía ​​usar una "colgando" comenzará en Delphi:

if (SomeCondition) then begin 
    ... 
end; 

Por extraño que parezca, no lo hice con C, porque me encontré con este más legible:

if (SomeCondition) 
{ 
    ... 
} 

Después de un tiempo, dejé de tratar de guardar una sola línea aquí y allá a favor de la legibilidad:

if (SomeCondition) then 
begin 
    ... 
end; 

También uso bloques explícitos de inicio/final donde creo que mejora la legibilidad. No necesito ser "inteligente". Necesito poder seguir la intención del código de un vistazo. Más importante aún, también lo hacen todos los que puedan leerlo/mantenerlo.

if x = y then 
begin 
    ... 
    ... 
end 
else 
begin 
    for i := 0 to 20 do 
    begin 
    ... 
    ... 
    end; 
end; 

Por lo general no se molestan si es evidente que existe una única instrucción

if (SomeCondition) then 
    ... 

Answer 5

utilizo personalmente:

if Condition then 
begin 
    DoThis; 
end else 
begin 
    DoThat; 
end; 

Ver Object Pascal Style Guide.

En el compuesto si las declaraciones, poner cada elemento de separación declaraciones en un nuevo línea: Ejemplo:

// INCORRECT 
if A < B then begin 
    DoSomething; 
    DoSomethingElse; 
end else begin 
    DoThis; 
    DoThat; 
end; 

// CORRECT 
if A < B then 
begin 
    DoSomething; 
    DoSomethingElse; 
end 
else 
begin 
    DoThis; 
    DoThat; 
end; 

Éstos son algunos más variaciones que se consideran válidos:

// CORRECT 
if Condition then 
begin 
    DoThis; 
end else 
begin 
    DoThat; 
end; 

// CORRECT 
if Condition then 
begin 
    DoThis; 
end 
else 
    DoSomething; 

// CORRECT 
if Condition then 
begin 
    DoThis; 
end else 
    DoSomething; 

Answer 6

Per En términos generales, prefiero comprimir declaraciones de unión en una línea. P.ej. end else en una línea. Hace más claro que el próximo bloque de enunciados está relacionado con el actual.

Answer 7

que tienden a hacer esto en Delphi:

if a=b then begin 
    c; 
end else begin 
    d; 
end; 

if x=y then z; 

simplemente porque me resulta más fácil de leer que con los saltos de línea adicionales. Obviamente, si estoy trabajando con otros, usaré los estándares en los que acordemos (o lo que sea que use la base de códigos actual), pero cuando soy el único que está trabajando en ellos (como en proyectos personales), entonces Lo hago así.

Answer 8

estándar en el mundo C es alinear los apoyos de cierre, ya sea con la declaración de partida:

if (I am nuts) { 
    Psychiatry 
} 

o incluso poner la llave de apertura en su propia línea:

if (I am nuts) 
{ 
    Psychiatry 
} 

En algunos estilos, el llaves tienen diferentes muesca:

if (I am nuts) 
    { 
    Psychiatry 
    } 

o incluso

if (I am nuts) 
    { 
    Psychiatry 
    } 

que utiliza el primer estilo durante mucho tiempo en Perl, y esto era mi camino para el otro continuación:

if (I am nuts) { 
    Psychiatry 
    } else { 
    I am free 
} 

pero después de haber estado expuesto a Lisp, no veo ningún valor adicional de poner los frenos en su propia línea cuando ya estoy sangría correctamente:

if (I am completely nuts) { 
    Psychiatry } 
    else { 
    I am free } 

que no tienen ninguna esperanza de cambiar las formas tradicionales C con estos pensamientos, sin embargo.

Como nota aparte, Python ha descartado las llaves y se basa solo en la sangría, sin embargo, esto es demasiado lejos en mi humilde opinión, ya que conduce a cosas tan ridículas como que lambda solo puede tener una declaración.

Answer 9

Alguien ha escrito que iban a escribir lo siguiente:

if x=y then z; 

Ahora bien, esto realmente no me gusta, y no tiene nada que ver con la estética. Supongamos que x, y y z son funciones. Si paso por el código, lo anterior significa que no puedo pasar por encima de x, y y entrar en z.

1 if x=y then 
2  Z; 

ahora puedo entrar en la línea 2, sin entrar en la línea 1.

Answer 10

siempre que alinee los Comenzar/extremos como en el ejemplo. (Excepto que también tendría una declaración Begin/End alrededor de For, solo en caso de que vaya agregar código más adelante)

De todos modos, si su código tiene varios niveles de profundidad, entonces realmente no importa dónde pon tu comienzo/final ya que es muy complicado. Si te encuentras sobre, por ejemplo, 3 niveles de profundidad, detente y simplifica. Crea sub rutinas para limpiar cosas.

CodeComplete es el mejor libro de referencia sobre este tipo exacto de cosas. Si no aprendes algo leyendo ese libro, entonces me comeré mi sombrero.

Answer 11

Hace tiempo que utiliza

if <cond> then 
    begin 
    ShowMessage('balablala'); 
    exit; 
    end; 

Pero ahora siguen el estándar por el

if <cond> then 
begin 
    ShowMessage('balablala'); 
    exit; 
end; 

Como en Object Pascal Style Guide

Answer 12

tiendo a la línea siempre mi IF y ELSE y guión mi bloque BEGIN/END. Si tengo una condición múltiple SI, la divido en varias líneas.Si descubro que estoy llegando a lo profundo, entonces reconsidero lo que estoy codificando o refactorizando en múltiples métodos. Así que mi código tiene el siguiente aspecto:

if condition1 then 
    begin 
    // do something 
    end 
else // not condition1 
    begin 
    // do something else 
    end; 

o el más complejo si condicionales.

if condition1 or 
    condition2 or 
    condition3 and 
    (condition4 or 
    condition5) 
then 
    begin 
    // do something 
    end 
else // not conditions 
    begin 
    // do something else 
    end; 

Answer 13

Esto es todo bastante gracioso. Tengo mi propia forma de alineación idiosincrásica que, curiosamente, uso en varios idiomas, incluyendo Pascal, C e incluso COBOL (aunque no en mucho tiempo para eso).

Creo que lo vi por primera vez en una clase de Ken Orr. Mi versión también es muy similar a tener una regla de fuera de juego (similar a Python y F #) donde puedes usar sangría para mostrar el anidamiento.

De todos modos, aquí es cómo hago el ejemplo:

begin if x = y 
     then begin (* stack to avoid getting too much indentation *) 
      ...  
      ... 
      end 
     else for i := 0 to 20 
      do begin  
       ...  
       ...  
       end; 
     end; 

y sí, el/C++/Java/C# sabor C sería algo así como

{ if (x == y) 
      { ... /* Space as if 'then' is there */ 
      ... 
      } 
    else for (int i = 0; i<21; i++) 
       { ... /* space as if 'do' is there */ 
       ... 
       } 
    } 

utilizo mucho en esto. Podrías apilar {y} de la misma forma en que comencé y terminé, pero me parece más agradable poder ver hacia abajo un borde y confirmar los paréntesis correspondientes y el final del grupo sangrado. Varío para evitar que la sangría sea excesiva y para evitar tener demasiados "{" y "}" solos en un mar de espacios en blanco.

Yo no evangelizo esto. Nadie se ha quejado de poder leerlo. Poner "{" al final de una línea parece una retención de los preprocesadores de Ratfor y tal, más o menos como Python requiere el ("más agradable") ":" en algunos lugares. No quiero tener que escanear el borde derecho por el código cuando puedo usar la alineación en los bordes izquierdos de manera más útil.

Como decimos por aquí, tu caso es distinto

Answer 14

utilizan algún código formateador como Código JEDI Formato de http://jedicodeformat.sourceforge.net/

Answer 15

Incluso si se trata de un único estado dentro if, siempre uso compuesto begin-end para evitar confusiones futuras.
También pongo // if después de cada end;.

if A < B then 
begin 
    DoSomething; 
end; // if 

Lo mismo para otras declaraciones:

with qryTemp do 
begin 
    First; 

    while not Eof do 
    begin 
    if (A < B) 
     or (C < D) 
    begin 
     DoSomething; 
    end else 
    begin 
     DoSomethingElse; 
    end; // if-else   

    Next; 
    end; // while 
end; // with 

para C#, que siga las instrucciones compuestas Code Conventions for the Java Programming Language estilo.

if (condition) { 
    statements; 
} // if 

if ((condition1 && condition2) 
     || (condition3 && condition4) 
     ||!(condition5 && condition6)) { 
    doSomethingAboutIt(); 
} else { 
    doSomethingElse(); 
} // if-else 

Por tanto Delphi y C#, los operadores lógicos de conexión vienen al principio de la línea siguiente.

Answer 16

Soy un programador de fin de semana, así que, siendo el único que trabaja en los proyectos, me puedo permitir no seguir una convención de codificación específica, suerte.

Cuando se trata de la legibilidad del código, el structural highlighting de Castalia es muy útil. CnPack tiene una característica similar es que no estoy confundiendo.

Answer 17

¡Hah! ¡Toma esto! ;)

try 
    if Condition1 
    or ( Condition2 
     and Condition3) then 
    begin 
     DoSomething 
     DoSomeMore; 
    end 

    else if Condition4 then // I only do this if the nested "if" has "case"-like characteristics 
    begin     // otherwise the if would obviously be indented and on its own line 
     DoSomethingElse; 

     if Condition5 then 
     begin 
      DoThisToo; 
      DoFoo; 
     end; 
    end 

    else 
    DoTheWholeShebang; 

    case Whatever of 
    A: DoIt; 

    B, C, D: 
     begin 
     DoSomethingSlightly; 
     MoreComplicated; 
     end; 

    else 
    begin 
     DoWhatever; 
     DoLastResort; 
    end; 
    end; 
except 
    on ESomeException do 
    begin 
     HandleIt; 
     raise; 
    end; 
    on ESomeOtherException do 
    DealWithIt; 

    else 
    DoWhateverItTakes; 
end; 

Extrañamente, sin embargo, al escribir en idiomas llaves que también prefieren el diseño de abrazadera de arrastre:

if (condition) { 
    doSomething; 
} else { 
    doSomethingElse; 
} 

Answer 18

apenas deje su guión IDE para que en la mayoría de los casos.

Answer 19

Encuentro el código más legible cuando las palabras clave (clave tanto sintáctica como lógicamente) están expuestas tanto como sea posible.

Esto es tan importante para mí que a veces recurro a (IMO) algo bastante poco convencional.

Aquí es lo que se pone así:

if (condition) then begin 
    statement; 
    ... 
    statement; end 
else begin 
    ... 
end; 

admito, esto puede que sea un poco menos conveniente para modificar el código. Es solo que encuentro 'colgando' end en el medio de una declaración if, y alineado igual que el if, algo confuso. Si es end, debe ser el final (para la declaración); de lo contrario, espero else o el comienzo de la siguiente declaración en esa posición.

Y normalmente no lo dejo cuando el bloque then es compuesto, pero el else es una sola declaración. Esto nunca es gran cosa conmigo para invertir la condición y reorganizar los bloques. Aún más, ya que soy bastante cerrado cuando se trata de envolver una sola declaración con begin ... end s. Desde mi punto de vista y experiencia, la mayoría de los "comienzos finales son redundantes" al principio y al final más a menudo que no. Aunque me gusta cuando una declaración tiene una palabra clave de final explícita, así que case y repeat son mis favoritos de todos los tiempos. :)

Una cosa más sobre if s (y while s para el caso) es que en caso de una condición de incontables pisos tiendo a colocar then (do) en la línea siguiente y alineado en la palabra clave a partir de la declaración .

De esta manera:

if (some_long_conditional_expression) or 
    (some_other_long_conditional_expression) or 
    (some_even_longer_conditional_expression) 
then 
    Exit; 

También, hay algunas otras cosas ya mencionadas aquí, que soy ningún extranjero a, como else if s-individuales alineados (en su caso) o for ... do with ... do try s (sí, esto de nuevo puede tener algo que ver con mi naturaleza de fisting cerrado mencionada anteriormente).

En general, probablemente dependa demasiado del resaltado de código y la sangría, especialmente este último. Tal vez si no fuera por la sangría, preferiría siempre destacar el begin s.

Otro punto: el estilo de formateo de alguien puede deberse a su estilo de programación. Al igual, algunas personas odian rutinas muy grandes y tienden a factorizar siempre que sea posible, mientras que otros prefieren concentrarse en el código y no importar los bloques compuestos que abarcan la pantalla. Encuentro que estos enfoques son muy diferentes, lo que puede dar lugar a hábitos de formato diferentes. .