¿Los frenillos deben estar en su propia línea o no? ¿Qué piensas al respecto?
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
o debería ser
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
o incluso
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
Por favor, sea constructivo! Explique por qué, comparta experiencias, respalde con hechos y referencias.
Cuando era estudiante solía poner llaves en la misma línea, de modo que hay menos líneas y el código se imprime en menos páginas. Mirar un solo carácter de corchete impreso como la única cosa en una línea es molesto. (medio ambiente, desperdicio de papel)
Pero cuando se codifican aplicaciones grandes, es asequible permitir algunas líneas con solo llaves en ellas, teniendo en cuenta la sensación de "agrupación" que da.
Sea cual sea el estilo que elija, sea consistente para que no se convierta en una sobrecarga para que su propio cerebro procese múltiples estilos en fragmentos de código relacionados . En diferentes escenarios (como arriba) diría que está bien usar diferentes estilos, es más fácil "cambiar de contexto" a un nivel alto.
Nunca debes hacer el tercer método.
Escatimar en frenillos puede ahorrarle algunas pulsaciones de tecla la primera vez, pero el siguiente programador que viene, agrega algo a su cláusula de otro tipo sin darse cuenta de que faltan frenos en los frenos.
Escriba su código para otras personas.
Durante mucho tiempo argumenté que tenían el mismo valor, o por lo tanto muy cerca de igual , que la posible ganancia al tomar la decisión correcta estaba muy, muy por debajo del costo de de discutiendo al respecto.
Sin embargo,ser coherente es importante . Así que dije que vamos a lanzar una moneda y escribir un código.
He visto a los programadores resistirse a un cambio como este antes. ¡Superalo! He cambiado muchas veces en mi carrera. Incluso utilizo diferentes estilos en mi C # que en mi PowerShell.
Hace unos años, estaba trabajando en un equipo (~ 20 desarrolladores) que decidió solicitar aportes y luego tomar una decisión y luego aplicarla en todo el código base. Tendríamos 1 semana para decidir.
Muchos gemidos y amp; girando los ojos. Un montón de "Me gusta mi camino, porque es mejor", pero no sustancia.
Mientras estudiábamos los puntos más finos de la pregunta, alguien preguntó cómo abordar este problema con un estilo de apoyo en la misma línea:
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
Tenga en cuenta que no es inmediatamente obvio dónde termina la lista de parámetros y comienza el cuerpo. Comparar con:
void MyFunction(
int parameterOne,
int parameterTwo)
{
int localOne,
int localTwo
}
Hicimos algunas lecturas sobre cómo las personas de todo el mundo habían resuelto este problema y encontraron el patrón de agregar una línea en blanco después de la abrazadera abierta:
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
Si vas a hacer una pausa visual, también puedes hacerlo con una abrazadera. Luego tus saltos visuales también se vuelven consistentes.
Editar : dos alternativas a la solución de "línea en blanco adicional" al usar K & R:
1 / Sangrar los argumentos de la función de forma diferente al cuerpo de la función
2 / Coloque el primer argumento en la misma línea que el nombre de la función y alinee los argumentos adicionales en las nuevas líneas con ese primer argumento
Ejemplos:
1 /
void MyFunction(
int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
2 /
void MyFunction(int parameterOne,
int parameterTwo) {
int localOne,
int localTwo
}
/Editar
Sigo argumentando que la coherencia es más importante que otras consideraciones, pero si no tenemos un precedente establecido , entonces la mejor manera es ir por el momento.
Las reglas cardinales son:
Incluso si no tiene restricciones externas, es mejor (IMO) buscar un estándar de codificación existente (ampliamente utilizado) o una guía de estilo, e intente seguirlo. Si implementas tu propio estilo, es muy probable que llegues a lamentarlo en unos años.
Finalmente, un estilo que se implementa / implementa con los comprobadores de estilo y los formateadores de código existentes es mejor que el que se debe "aplicar" manualmente.
El beneficio del primer método es que es más compacto verticalmente, por lo que puedes colocar más código en tu pantalla, y es por eso que lo prefiero. El único argumento que escuché a favor del segundo método es que facilita emparejar los corchetes de apertura y cierre, pero la mayoría de los IDE tienen un atajo de teclado para eso, y en realidad es una declaración falsa, en lugar de emparejar un corchete de apertura con un cierre corchete puede emparejar un corchete de cierre con la expresión "inicio de bloque" (si, también, para, while) en el mismo nivel de sangría, por lo que es tan fácil determinar dónde está el inicio del bloque.
No veo ninguna razón para desperdiciar una línea completa solo por un corchete cuando la construcción anterior para / while / if ya indica visualmente el inicio de un bloque.
Dicho esto, creo que el corchete de cierre debería estar en su propia línea porque necesitamos algo para indicar el final de un bloque y su estructura de sangría de forma visible.
Yo prefiero
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
sobre
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
porque la línea you.postAnswer(); es mucho más fácil de leer y encontrar a primera vista. En la segunda forma, se mezcla con la línea por encima ( you.hasAnswer() ), lo que hace que mis ojos tengan que enfocarse más para leerlo.
Prefiero el primer método. Las llaves no valen totalmente la línea separada.
Lo que pasa es que los tirantes no son importantes. Solo son basura sintáctica , lo cual es absolutamente innecesario para comprender para qué sirve el código, su propósito y la forma en que se implementa. Son solo un tributo a los lenguajes de estilo C al estilo antiguo, donde la agrupación visual de operadores era imposible debido al bajo espacio disponible en la pantalla.
Hay idiomas (Python, Haskell, Ruby) que están bien sin llaves. Esto solo confirma que los tirantes son basura, y no deben merecer una línea para ellos siempre que sea posible:
if (you.hasAnswer()){
you.postAnswer();
}else{
you.doSomething();
}
Usa Python y esquiva el argumento por completo.
La posición de las llaves debe ser
metadatos
configurable en el IDE por el programador. De esa manera, esas llaves molestas en todo el código, independientemente del autor, tienen el mismo aspecto.
Depende.
Si estoy codificando en Javascript o jQuery, utilizo la primera forma:
jQuery(function($) {
if ($ instanceOf jQuery) {
alert("$ is the jQuery object!");
}
});
Pero si estoy codificando en C #, uso la segunda forma, porque esa es la forma canónica de hacerlo en C #.
public int CalculateAge(DateTime birthDate, DateTime now)
{
int age = now.Year - birthDate.Year;
if (now.Month < birthDate.Month
|| (now.Month == birthDate.Month && now.Day < birthDate.Day))
age--;
return age;
}
Tenga en cuenta que su ejemplo se puede escribir
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
en C #.
Prefiero el primero porque me resulta más difícil ver el error en este ejemplo.
if (value > maximum);
{
dosomething();
}
de lo que es en este ejemplo
if (value > maximum); {
dosomething();
}
El ; { me parece más incorrecto que una línea que termina con ; , por lo que es más probable que lo note.
Prefiero una ligera variante de 1)
if (you.hasAnswer()) {
you.postAnswer();
} // note the break here
else {
you.doSomething();
}
¿Por qué?
Creo que siempre poner llaves en su propia línea disminuye la legibilidad. Solo puedo colocar una cierta cantidad de código fuente en mi pantalla. El estilo de corchete 2) hace que los algoritmos de levantamiento con muchos bucles y condicionales anidados sean dolorosamente largos.
Sin embargo, quiero que else comience en una nueva línea porque if y else pertenecen juntos, visualmente. Si hay un corchete delante de else , es mucho más difícil detectar qué pertenece a qué.
3) se descalifica a sí mismo. Todos sabemos qué cosas malas pueden suceder si omites los corchetes y te olvidas de ello.
Leí en alguna parte que los autores de algún libro querían que su código tuviera este formato:
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
Pero las limitaciones de espacio de su editor significaban que tenían que usar esto:
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
Ahora no sé si eso es cierto (ya que no lo puedo encontrar más), pero este último estilo es muy común en los libros.
A nivel personal, prefiero los corchetes en una línea separada como:
a) indican un nuevo alcance
b) es más fácil de detectar cuando tienes una discrepancia (aunque esto es un problema menor en un IDE que resalta los errores para ti).
Ah, el One True Brace Style .
Tiene todo lo necesario para un Camino Sagrado, incluso un profeta (Richard "mi camino o la carretera" Stallman).
El tipo estaba tan equivocado con tantas cosas, pero GNU es muy acertado cuando se trata de llaves.
[Actualización] He visto la luz, y ahora adoro a Allman
Segundo ejemplo, soy muy grande en legibilidad. No soporto mirar si bloquea de otra manera = (
Respuesta simple: ¿qué es más fácil de depurar?
// Case 1:
void dummyFunction() {
for (i = 0; i != 10; ++i) {
if (i <= 10)
std::cout << "i is: " << i << "\n";
std::cout << 10 - i << " steps remaining\n";
// Some hard work here
// which is really hard
// and does take some screen estate
}
else
std::cout << "We'll never get there";
}
} // COMPILER ERROR HERE
// Case 2:
void dummyFunction()
{
for (i = 0; i != 10; ++i)
if (i <= 10)
{
std::cout << "i is: " << i << "\n";
std::cout << 10 - i << " steps remaining\n";
// Some hard work here
// which is really hard
// and does take some screen estate
}
else
std::cout << "We'll never get there\n";
}
} // COMPILER ERROR HERE
¿En qué caso diagnosticaste el problema primero?
No me interesan mucho las preferencias personales (hay muchos otros estilos, incluidos whitesmith y al.) y no me importa mucho ... siempre y cuando no obstaculice mi capacidad para leer el código y debug it.
En cuanto al argumento del "espacio de desecho", no lo compro: tiendo a agregar líneas en blanco entre los grupos lógicos de todos modos para aclarar el programa ...
No es que nadie se dé cuenta, pero es por eso que los frenos pertenecen a la misma línea como condicional (excepto los condicionales muy largos, pero eso es un caso de borde):
En C, esta es una construcción válida:
while(true);
{
char c;
getchar(); //Wait for input
}
¡Rápido! ¿Qué hace este código? Si respondiste "bucle infinito pidiendo entrada", estás equivocado! Ni siquiera llega a la entrada. Se atrapa en while(true) . Note que el punto y coma al final. Este patrón es en realidad más común de lo que parece que debería ser; C requiere que declare sus variables al comienzo de un bloque, por lo que se inició una nueva.
Una línea de código es un pensamiento. Las llaves son una parte del pensamiento que contiene el condicional o bucle. Por lo tanto, pertenecen a la misma línea.
Me gusta el primer método. Parece una OMI más ordenada, y es más compacta, lo que me gusta.
EDITAR: Ah, un tercero. Me gusta el mejor cuando es posible, ya que es aún más pequeño / más limpio.
Podrías escribirlo:
you.hasAnswer() ? you.postAnswer() : you.doSomething();
Para responder a la pregunta; Solía preferir las llaves en su propia línea, pero para evitar tener que pensar en los errores de la inserción automática de punto y coma en los navegadores, empecé a usar el estilo egipcio para javascript. Y cuando codifiqué java en eclipse, no tenía ningún interés en luchar (o configurar) el estilo de corsé predeterminado, así que también fui con el egipcio en ese caso. Ahora estoy bien con ambos.
Casi todas las respuestas aquí están diciendo alguna variación sobre "Hagas lo que hagas, quédate con uno o dos".
Así que lo pensé por un momento, y tuve que admitir que simplemente no lo veo tan importante. ¿Puede alguien honestamente decirme que es difícil seguir lo siguiente?
int foo(int a, Bar b) {
int c = 0;
while(a != c)
{
if(b.value[a] == c) {
c = CONST_A;
}
c++;
}
return c;
}
No estoy seguro de nadie más ... pero no tengo absolutamente ningún problema mental al cambiar entre estilos. Me tomó unos minutos darme cuenta de lo que hizo el código, pero ese es el resultado de que escribí sintaxis al estilo C al azar. :)
En mi opinión no tan humilde, las llaves de apertura son casi totalmente irrelevantes para la legibilidad del código. Hay algunos casos de esquinas enumerados anteriormente donde un estilo u otro marca la diferencia, pero en su mayor parte, el uso juicioso de líneas en blanco lo limpia.
FWIW, nuestros estilos de codificación en el trabajo utilizan un formulario 1 ligeramente más estructurado y un formulario 3 modificado (C ++)
// blank line is required here
if (x) {
//This blank line is required
y = z;
}
// blank line is required here too, unless this line is only another '}'
if (x) y = z; //allowed
if (x)
y = z; // forbidden
Tengo curiosidad de que aquellos que prefieren el formulario 2 encuentren mejor esta versión del formulario 1, solo porque la línea en blanco ofrece una separación visual más fuerte.
Me sorprende que esto no se haya planteado todavía. Prefiero el segundo enfoque porque te permite seleccionar el bloque más fácilmente.
Cuando las llaves comienzan y terminan en la misma columna y en su propia línea, puede seleccionar desde el margen o con el cursor en la columna 0. Esto generalmente equivale a un área más generosa con la selección del mouse o menos pulsaciones con la selección del teclado .
Originalmente trabajé con llaves en la misma línea que el condicional, pero cuando cambié, encontré que aceleró la velocidad a la que trabajé. No es de día y de noche, por supuesto, pero es algo que te hará frenar un poco el trabajo con frenos al lado de tus condicionales.
Personalmente me gusta la segunda forma.
Sin embargo, en mi opinión, la forma en que lo voy a demostrar es la mejor, ¡porque da como resultado la mayor seguridad en el trabajo! Un compañero de mi universidad me pidió ayuda con su tarea y así es como se ve su código. Todo el programa parecía un solo bloque. Lo interesante es que el 95% de los errores en el programa que hizo provino de llaves que no coinciden. El otro 5% fue obvio una vez que se ajustaron las llaves.
while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
if(i%1==0){
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
if(i%1==0){
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='%pre%';
puts(input);
';
puts(input);
Mi preferencia personal es por el primer método, probablemente porque así es como aprendí PHP por primera vez.
Para las declaraciones de if de una sola línea, usaré
if (you.hasAnswer()) you.postAnswer();
Si no es you.postAnswer(); sino algo mucho más largo, como you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType); probablemente volveré al primer tipo:
if (you.hasAnswer) {
you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}
Nunca usaré un salto de línea, y nunca usaré este método si también hay una declaración else .
if (you.hasAnswer()) you.postAnswer();
else you.doSomething()
es una posibilidad teórica, pero nunca la usaría. Esto tendría que ser convertido en
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
No deberían; primer método para mí.
Cuando miro el segundo, debido a las líneas no utilizadas (aquellas que solo tienen llaves, aparte de la última llave de cierre), parece que rompe la continuidad del código. No puedo leerlo tan rápido porque necesito prestar especial atención a las líneas vacías que normalmente significan una separación en el propósito del código o algo así, pero en ningún caso "esta línea pertenece a una llave" (que solo repite el significado de sangría).
De todos modos, al igual que cuando escribes texto ... agregar una sangría al principio de un párrafo es superfluo si hay una línea en blanco delante de ella (doble signo de cambio de párrafo), no hay necesidad de desperdiciar líneas por llaves cuando estamos apropiadamente haciendo sangría.
Además, como ya se dijo, permite encajar más código en la pantalla, que de lo contrario es un poco contraproducente.
Depende de la plataforma / idioma / convenciones
En Java:
void someMethod() {
if (you.hasAnswer()) {
you.postAnswer();
} else {
you.doSomething();
}
}
En C #
void someMethod()
{
if (you.hasAnswer())
{
you.postAnswer();
}
else
{
you.doSomething();
}
}
En C:
void someMethod()
{
if (you_hasAnswer()) {
you.postAnswer();
} else {
you_doSomething();
}
}
Odio cuando los chicos de Java usan su estilo en el código C # y viceversa.
Todo lo que puedo decir es que si eres fanático del método # 3, serás perseguido por todos los formateadores de códigos IDE en la tierra.
Utilizo el primer método simplemente porque es más compacto y permite más código en la pantalla. Yo mismo nunca he tenido un problema con emparejar llaves (siempre las escribo, junto con la declaración if antes de agregar la condición, y la mayoría de los entornos te permiten saltar a la abrazadera correspondiente).
Si hiciste la necesidad de emparejar llaves de forma visual, preferiría el segundo método. Sin embargo, eso permite menos código a la vez, lo que requiere que se desplace más. Y eso, al menos para mí, tiene un mayor impacto en la lectura de código que tener llaves cuidadosamente alineadas. Odio el desplazamiento. Nuevamente, si necesita desplazarse por una única declaración if , es muy probable que sea demasiado grande y necesite refactorización.
Pero; Lo más importante de todo es la consistencia. Usa uno o el otro, ¡nunca los dos!
Cuando estaba aprendiendo programación a los 12, puse las llaves en la siguiente línea porque los tutoriales de codificación de Microsoft son así. También sangré con 4 espacios TABS ese tiempo.
Después de unos años, aprendí Java y JavaScript, y vi más códigos de llaves en la misma línea, así que cambié. También comencé a sangrar con espacios de 2 espacios.
Hay una cuarta opción que mantiene las llaves alineadas, pero no desperdicia espacio:
if (you.hasAnswer())
{ you.postAnswer();
i.readAnswer();
}
else
{ you.doSomething();
}
El único problema es que la mayoría de los autoformateadores del IDE se ahogan con esto.
Todo depende de usted, siempre y cuando no esté trabajando en un proyecto en el que el administrador del proyecto haya establecido algunas restricciones de codificación o algunos estándares que todos los programadores que están trabajando en ese proyecto deben seguir durante la codificación.
Personalmente preferiría el primer método.
¿También no obtuve lo que quieres mostrar con el tercer método?
¿No es una manera incorrecta? Por ejemplo, considere una situación como ...
if (you.hasAnswer())
you.postAnswer();
else
you.doSomething();
Ahora, ¿qué pasa si alguien quiere agregar más declaraciones en el bloque si ?
En ese caso, si utiliza el tercer método, el compilador lanzará el error de sintaxis.
if (you.hasAnswer())
you.postAnswer1();
you.postAnswer2();
else
you.doSomething();
Lea otras preguntas en las etiquetas coding-style code-formatting