¿Sería una mala forma poner llaves en la misma línea que la declaración para declaraciones "if" de una sola línea?

Question

Así que sé que se considera una buena práctica incluir siempre llaves para if, for, etc, aunque son opcionales si solo hay una declaración siguiente, por la razón de que es más fácil hacer algo accidentalmente como

if(something == true) 
    DoSomething(); 
    DoSomethingElse(); 

al editar rápidamente el código si no coloca llaves.

¿Qué pasa algo como esto sin embargo:

if(something == true) 
{ DoSomething(); } 

De esa manera siguen ocupando un menor número de líneas (que aumenta la legibilidad de la OMI), pero aún lo hace poco probable que el error accidental desde arriba?

Lo pregunto porque no creo que he visto este estilo antes de si o bucles, pero yo lo veo utiliza para get y set en C# propiedades como:

public string Name 
    {get;set;} 

No pedir lo que es Lo mejor es que eso es demasiado subjetivo, sino más bien simplemente si esto se consideraría un estilo aceptable y, en caso negativo, por qué no.

Answer 1

Cuando me encuentro con una sola línea de sentencia if, por lo general no tome la curlys y mantener todo en la misma línea:

if (something == true) DoSomething(); 

Es rápido, fácil y ahorra espacio.

Answer 2

En lugar de:

if(something == true) 
{ DoSomething(); } 

Haga esto:

if(something == true) { DoSomething(); } 

Answer 3

No hay ningún problema allí ... de hecho, Visual Studio no pondrá ese código en su propia línea si intenta formatearlo automáticamente. Entonces, si eso es más legible para ti ... eres bueno.

Answer 4

De esa manera siguen ocupando un menor número de líneas (que aumenta la legibilidad de la OMI)

estoy de acuerdo que tienen menos saltos de línea aumenta la legibilidad. El diseño del código debe hacer que su estructura sea más visible, no ocultarla.

Answer 5

Si realmente desea guardar líneas de código, puede escribir así:

if(something == true) { DoSomething(); } 

o esto, sin los apoyos

if(something == true) DoSomething(); 

Answer 6

Si trabaja en un equipo, necesita llegar con un estándar.

Personalmente me gusta hacer:

if(foo) 
    DoSomething(); 

o

if(foo) DoSomething(); 

no veo un problema con no tener las llaves.La razón por la que las personas citan, la que mencionas sobre agregar otra declaración en la línea a continuación, es una que nunca he visto.

Answer 7

No veo por qué no. También lo he usado para funciones cortas.

En el frente de estilo ofensivo, que es mucho mejor que lo indecible:

if (something== true) { 
     DoSomething(); 
    } 

Pero, ya que estamos en el tema de estilo, que es

if (something) 

y

if (!something) 

Nunca

if (something== true) 

o

if (something== false) 

Answer 8

Yo recomendaría que te gusta Esteban y Nicolás Mancuso dijo.

Uso:

if(something) { DoSomething(); } 

Con o sin el soporte. Tan pronto como comiences a usar una versión extraña de la declaración "if", comenzarás a ver a tus colegas mirando tu código de una manera extraña.

Normalmente utilizo un forro para la validación.

Ejemplo:

if(param1 == null) throw new ArgumentNullException("param1"); 

Answer 9

Mientras eres consistente, no debería ser un problema. En una empresa anterior que era el escenario típico, pero en mi empresa actual prefieren tener llaves en líneas separadas.

Answer 10

Ayer me encontré con este problema mientras trabajaba en un código escrito por otra persona. El código original fue:

if (something == true) 
    DoSomething(); 

y quería una impresión de depuración antes de llamar a DoSomething(). Lo que haría instintivamente

if (something == true) 
    print("debug message"); 
    DoSomething(); 

Pero que haría que el if se aplican sólo al mensaje de depuración, mientras que DoSomething() se llamaría incondicionalmente. Es por eso que prefiero tener llaves, por lo que la edición instintiva termina como:

if (something == true) { 
    print("debug message"); 
    DoSomething(); 
} 

Answer 11

El espacio en blanco en forma de nuevas líneas, sangría, espaciado, la alineación y así sucesivamente es un aspecto importante de la tipografía y es ampliamente utilizado para mejorar la legibilidad del texto en artículos, libros y sitios web. No estoy seguro de por qué no se aplicará lo mismo a la legibilidad del código.

Dicho esto, no hay nada de malo en que usted y su equipo utilicen su estilo. Siempre y cuando todos estén de acuerdo.

Answer 12

que tienden a poner los frenos de apertura en su propia línea como esta:

if (condition) 
{ 
    statement; 
    statement; 
} 

Así que viendo algo como:

if (condition) 
    statement; 
    statement; 

se destaca como mal de inmediato. Si sólo tengo una declaración que acaba de dejarlo como

if (condition) 
    statement; 

y poner las llaves en la tarde si tengo una declaración adicional para agregar. Realmente no veo ningún lugar para la confusión.

Poner la declaración en la misma línea que la condición es un mal hábito para entrar, ya que cuando se depura, la mayoría de los depuradores cuentan todo en una sola línea. (Me doy cuenta de que en C# este no es el caso).

Answer 13

Muchas personas han sugerido poner ambos en una sola línea. Esto puede aumentar la legibilidad, pero a costa de una disminución de la capacidad de depuración, en mi opinión. He recorrido un montón de código escrito de esta manera y es más difícil de depurar por eso.

Algunos depuradores e IDEs podrían pasar por encima de las dos partes de una sola línea if -statement y mostrar claramente si la condición se evaluó como verdadera o no, pero muchos otros depuradores pueden tratarla como una sola línea, lo que dificulta determinar si se llamó el cuerpo de la declaración if.

Por ejemplo, el depurador VS2008 para el código C++ pasará sobre esto como una sola línea, lo que dificulta determinar si se llamó a Foo().

if (a==b) { Foo(); } 

Answer 14

Personalmente, me gusta que todos mis bloques tengan el mismo patrón. Siempre utilizo llaves para ifs y siempre comienzan una nueva línea. Me gusta el modismo para definir automáticamente las propiedades públicas de poner {get; conjunto; } en la misma línea. Siento que tener todos los bloques con una abrazadera en su propia línea mejora la legibilidad. Como otros han señalado, también lo hace más claro en el depurador si está pasando por encima de las líneas.

Si no está de acuerdo, está bien, también, pero como otros han dicho, sea coherente. Con ese fin, es posible que desee compartir la configuración de "formato de código" entre usted y sus compañeros de trabajo para que el formato automático haga que todo sea coherente para todos.

que haría:

if (something) 
{ 
    DoSomething(); 
} 

y

public string MyProperty { get; set; } 

Answer 15

Siempre y cuando lo hace constantemente, y asegurarse de que todos los que trabajan en su código sabe cómo lo hace, no importa Que haces.

Simplemente haga lo que le parezca más cómodo, luego asegúrese de que todos sepan que siempre debe hacerlo de esa manera.

Answer 16

En realidad, me gusta mucho más

if (something == true) 
if (something == false) 

sobre

if (something) 
if (!something) 

Para mí, el signo de exclamación es difícil de ver a simple vista, por lo que es fácil perderse. Nótese, sin embargo, que cuando el código en Python, casi siempre prefiero:

if something: 
if not something: 

A menos que yo quiero distinguir Ninguno de, por ejemplo, lista vacía.

Answer 17

me gusta hacer de vez en cuando la

if(obj != null) obj.method(); 

pero es un placer culpable ... No creo que hace que el código más legible, por lo que ¿por qué no sigue un patrón de todos los demás están usando . La única excepción que creo que es muy importante es cuando usted está mostrando la forma en que es parte de un patrón más grande, y ayudar al usuario ver el patrón más fácilmente:

public executeMethodOn(String cmd) { 
    CommandObject co; 

    if("CmdObject1".equals(cmd)) co=new CmdObject1(); 
    if("CmdObject2".equals(cmd)) co=new CmdObjec21(); 

    co.executeMethod(); 
} 

Esto hace que el patrón mucho más evidente y ayuda a las personas tratando para insertar una nueva funcionalidad ver dónde debe ir.

Dicho esto, si alguna vez tiene un patrón así, probablemente lo esté haciendo mal. Tuve que hacer esto en un sistema que no tenía reflejo, pero traté REALMENTE DIFÍCIL de evitarlo, y si hubiera tenido reflejo, hubiera sido mucho mejor.

Answer 18

que suele hacer esto con ifs de una línea:

if($something) { 
    do_something(); 
} 

La única excepción (hago Perl, no está seguro de si se permite que este estilo en C#) es para los controles de bucle, donde uso el uno invertida línea estilo:

THING: 
for my $thing (1 .. 10) { 
    next THING if $thing % 3 == 0; 
} 

Con buena coloración de sintaxis es posible hacer que esas líneas se destaquen de forma pronunciada.

Answer 19

Estás todo INCORRECTO INCORRECTO EQUIVOCADO !!!!! ;-)

Afortunadamente, VS vuelve a formatear toda tu locura en mi formato aprobado personalmente, simplemente reemplazando la última llave de cada archivo.

El espacio en blanco es algo de estilo. Ya que tenemos diferentes estilos de lectura y estilos de aprendizaje, realmente no importa cómo lo hagas más. Las herramientas nos permitirán cambiar de un lado a otro. La única desventaja de esto que he notado es el costo que implica seguir los cambios en el control de la fuente. Cuando vuelvo a formatear un archivo de estilo K de K & en un formato más sano (mi opinión) y compruebo que vuelva a cambiar al control de fuente, muestra que casi todas las líneas han cambiado. Eso es un dolor. Pero muchas utilidades de diff pueden ignorar los cambios en el espacio en blanco (aunque la mayoría solo en una línea, no en líneas). Ese es un problema. Pero no es un show stopper.

Answer 20

C proporciona mucha libertad en los problemas de formato, por lo que tenerlos en la misma línea o en diferentes líneas es irrelevante para la compilación.

Como resultado, ese "sería malo" solo se refiere a las convenciones de codificación. Depende del contexto.Si trabajas en un equipo, es una buena idea preguntarles a los demás qué piensan y crear un estilo de formato estándar. Si no, depende de ti.

Entonces, si crees que es mejor, adelante. Si no, entonces no. Es realmente así de simple (a menos que utilice un IDE que impone algunas convenciones de estilo)

Answer 21

prefiero la sintaxis horridly indecible:

if (true == something) { 
    doSomething1(); 
} 

Sí, esa es la forma K & R hizo ... y sí , Vuelvo tan lejos ... y sí, esa es una buena razón para mí. Esto hace que yo reciba sintaxis común, incluso cuando hago algo como esto:

if (-1 == doSomething()) { 
    doSomethingElse(); 
} 

puse las llaves en sin importar el número de las líneas de código que contienen. Me ha picado la "necesidad de agregar una línea de código de prueba" y me perdí la falta de llaves varias veces.

Siempre comparo con el literal de la izquierda. Esto evita el error de "probar una tarea" (por ejemplo, si (algo = verdadero) {...}).

No hay más peligro para la portabilidad de "(algo == verdadero)" que con el conjunto de valores sobrecargado que significa "verdadero" y "falso" en una comparación booleana, pero es un tipo diferente de peligro ¿Estás escribiendo en un idioma que considera "vacío" (y/o cero y/o NULL y/o espacio en blanco) como "verdadero" o "falso"? Prefiero una convención que sea segura para todos los casos ... porque soy flojo.