validate - regex rut c#

¿Cómo formateas tus declaraciones compuestas en Delphi y C#?

Question

Como desarrollador de Pascal y Delphi desde hace mucho tiempo, siempre alineo mi comienzo y finalizo así:

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

Lo que me vuelve loco es el código formateado así:

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

Cuando hay algunos niveles de declaraciones compuestas, encuentro que esto es 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 los corchetes 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 formularse en 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

Alguien publicó que escribirían lo siguiente:

if x=y then z;

Ahora 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 2

El estándar en el mundo C es alinear llaves de cierre con la instrucción inicial:

if (I am nuts) {
Psychiatry
}

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

if (I am nuts)
{
Psychiatry
}

En algunos estilos, las llaves tienen diferentes sangrías:

if (I am nuts)
{
Psychiatry
}

o incluso

if (I am nuts)
{
Psychiatry
}

Utilicé el primer estilo durante mucho tiempo en Perl, y este fue mi camino para la continuación del resto:

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

pero después de haber estado expuesto a Lisp, no veo ningún valor adicional al colocar las llaves en su propia línea cuando ya estoy sangrando correctamente:

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

Sin embargo, no tengo ninguna esperanza de cambiar las formas tradicionales de C con estos pensamientos.

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

Answer 3

Nunca escribiría el código (su segundo ejemplo) de esa manera. Sería cualquiera (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;

fin;

A veces utilizo ese colapso (como en el segundo caso) para combinar si ... y finalmente intento.

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

Answer 4

Personalmente, prefiero comprimir declaraciones de unión en una línea. Por ejemplo, end else en otra línea. Hace más claro que el próximo bloque de enunciados está relacionado con el actual.

Answer 5

Siempre alineo el Comienzo / Fin como en tu ejemplo. (Excepto que también tengo una declaración Begin / End alrededor de For, solo en caso de que vayas agregue código más tarde).

De todos modos, si tu código tiene múltiples niveles de profundidad, entonces realmente no importa dónde pongas tu comienzo / final ya que es demasiado 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 6

Solía ​​usar un principio "colgante" en Delphi:

if (SomeCondition) then begin
...
end;

Curiosamente, no lo hice con C, porque encontré esto más legible:

if (SomeCondition)
{
...
}

Después de un tiempo, dejé de intentar 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 en los que 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 me molesto si, obviamente, hay una sola declaración

if (SomeCondition) then
...

Answer 7

Tiendo a alinear siempre mi IF y ELSE y doblo 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. Entonces mi código se ve así:

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

o los más complejos 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 8

Tiendo 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 legible 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 9

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í que el código podría verse así (Modula-2 es sensible a mayúsculas y minúsculas):

IF x = y THEN
....
END;

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

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

De esta manera, 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 sangrado 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, use el estilo que ya existe. Cuando trabaje en un código nuevo, use su estilo preferido.

Answer 10

Esto es muy 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, así es como 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 sabor C / C ++ / Java / 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 */
...
}
}

Yo uso esto mucho. 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í, YMMV

Answer 11

Incluso si se trata de una única declaración dentro de if , siempre uso el begin-end compuestos para evitar confusiones futuras.
También puse // 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 #, sigo las convenciones de código para las declaraciones compuestas de estilo del lenguaje de programación Java .

if (condition) {
statements;
} // if

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

Tanto para Delphi como para C #, los operadores lógicos de conexión se encuentran al comienzo de la siguiente línea.

Answer 12

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 resaltado estructural de Castalia es muy útil. CnPack tiene una característica similar es que no estoy confundiendo.

Answer 13

Utilice algún formateador de código como formato de código JEDI de http://jedicodeformat.sourceforge.net/

Answer 14

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;

Aunque parezca extraño, cuando escribo en idiomas con llaves, también prefiero el diseño del parlante posterior:

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

Answer 15

Solo deja que tu IDE te guíe en la mayoría de los casos.

Answer 16

Encuentro que el código es 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.

Esto es lo que se obtiene:

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

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

Y generalmente no lo dejo cuando el bloque está 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 un enunciado tiene una palabra clave de finalización explícita, entonces el case y la repeat son mis favoritos de todos los tiempos. :)

Una cosa más acerca de if s (y while ) es que en el caso de una condición de varios pisos, tiendo a colocar then ( do ) en la siguiente línea y alinearla en la palabra clave inicial de la declaración.

Me gusta esto:

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

Además, hay algunas otras cosas ya mencionadas aquí de las que no soy extranjero, como las de una sola línea else if s (cuando corresponda) o for ... do with ... do try (s, sí, esto de nuevo puede tener algo que ver con hacer con mi naturaleza apretada-fisting mencionada anteriormente).

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

Otro punto: el estilo de formateo de alguien muy probablemente sea causado por 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. .

Answer 17

Hace algún tiempo utilicé

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

Pero ahora sigo el estándar por el

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

Como en la guía de estilo de Object Pascal

Answer 18

Yo personalmente uso:

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

Ver la Guía de estilo de Object Pascal .

En las sentencias if compuestas, coloque cada elemento separando enunciados en una nueva 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;

Aquí hay algunas variaciones más que se consideran válidas:

// 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 19

Esto fue preguntado antes. por ejemplo c-coding-standard-best-practices .