coding-style - div - title attribute anchor tag

Si rompes largas líneas de código, ¿cómo sangras las cosas en la siguiente línea?

Question

A veces tienes que escribir en tus líneas largas de origen, que es mejor romperlas. ¿Cómo sangrías las cosas cementadas por esto?

Puede aplicar sangría de la misma manera:

very long
statement;
other statement;

Eso hace que sea más difícil diferenciarlo del siguiente código, como se muestra en el ejemplo. Por otro lado, puedes sangrarlo un nivel:

very long
statement;
other statement;

Eso hace que sea más fácil, pero puede suceder, que la línea larga es el comienzo de un bloque anidado, que desea sangrar, como este:

if ((long test 1) &&
(long test 2) &&
(long test 3)) {
code executed if true;
}

En este caso, nuevamente es difícil de leer. La tercera posibilidad en la que puedo pensar es no romper líneas largas en absoluto, los editores modernos pueden manejarlo y crear linebreaks suaves. Pero con otro editor tienes que desplazarte de lado y no puedes influir en la posición, el editor rompe tu larga línea.

¿Qué posibilidad prefieres? ¿Tienes otras ideas para resolver esto? ¿Puedes apoyar tus preferencias con una buena justificación?

Answer 1

Casi nunca hago sangrías en la misma línea. Sin embargo, en una ocasión muy rara reinicié varias variables como esta

a
= b
= c
= d
= e
= f
= 0;

Sin embargo, la clave para hacer algo como esto es mantener al operador de asignación como el primer personaje en la siguiente línea. Esto dará la maint. programa un momento WTF cuando lo vean, obligándolos a mirar, no solo a ignorarlo.

Envolviendo una declaración muy larga, lo haré donde sea que sienta que tiene sentido ... no necesariamente en la primera sangría. Asi que :

reallyLongMethodName (paramA,paramB,paramC);

no se formatearía como

reallyLongMethodName (paramA,
paramB,
paramC);

pero terminaría más como

reallyLongMethodName (paramA,
paramB,
paramC);

con todos los parámetros alineados con el paréntesis de apertura.

Por si y por que, haria algo como

if((long test 1)
&& (long test 2)
&& (long test 3))
{
code executed if true;
}

Answer 2

Con astyle, o cualquier penetrador automático que esté usando. Parece hacer un buen trabajo, y generalmente hay cosas más importantes en las que pensar.

Answer 3

Debería intentar evitar escribir líneas de más de 80 caracteres en lugar de romperlas:

• Intente minimizar la indentación al convertir las condiciones y encapsular el código.

Linus Torvalds: si necesitas más de 3 niveles de sangría, estás jodido de todos modos,
y debe arreglar su programa.

Esto también tiene el efecto secundario de hacer que el código sea mucho más legible, además de que las condiciones son que las otras cosas que encapsulas están listas para ser usadas en otro lugar.

bool encapsulatedLongCondition() // Add some parameters
{
if (!condition1)
return false;
if (!condition2)
return false;
// ... (Other conditions)
return true;
}
if (encapsulatedLongCondition())
{
// ... (Call some methods, try not to introduce deeper if/loop levels!)
}

Simplificar su condición a través del álgebra booleana e intentar invertir la condición y devolver el valor puede ayudar mucho. :-)

Ver también: ¿Puedes simplificar este algoritmo? Consulte también 2: Refactor para C # tiene la capacidad de ayudarlo con esto. ;-)

• Use definiciones de tipo e intente evitar nombres largos

Un ejemplo simple, imagine cuánto tiempo usaría Days sin typedef con nombres más largos en otro contenedor.

struct Day
{
// Some data
};
struct Event
{
// Some data
};
typedef list<Event> Events;
typedef map<Day, Event> Days;
// Some other container that would else be long...

• ... (Debe intentar analizar por qué su línea es larga y encontrar una solución para ello)

Espero que entiendas la idea general, de esta forma no tendrás que pensar en un salto de línea sucio. ;-)

El único lugar donde vería líneas largas es en los prototipos de sus funciones o cuando los llame, allí simplemente debe tratar de romper después de la última coma posible y continuar en la siguiente línea. En lugar de hacerlo después de cada una y desperdiciar varias líneas, lo que hace que el desplazamiento se hinche y su función se destaque demasiado ... Podría colocar el tipo de devolución en la línea antes del nombre de la función si con frecuencia ve estas líneas largas.

void longFunctionName(ParameterType1 parameter1, ParameterType2 parameter2,
ParameterType3 parameter3, ParameterType4 parameter4)

Answer 4

En general, hago:

if ((long test 1) &&
(long test 2) &&
(long test 3)) {
code executed if true;
}

para delimitadores de bloque Sin embargo, si el caso de una larga fila tengo que romper, uso esto:

if (condition) {
something;
}

Diferencias clave de la respuesta de rbobby:

1. Los operadores al final de cada línea en lugar del comienzo de las líneas siguientes, para indicar claramente que la línea está incompleta
2. Salto de línea en la primera línea antes del elemento condicional: esto ayuda a mantener la "forma" del código consistente.
3. Paren de cierre no sangrado.

Esto tiene el efecto visual de hacer que las listas de parámetros / condicionales se vean como bloques de código (pero con paréntesis en lugar de llaves) .Me parece agradable la simetría. También evita tener una llave abierta abierta en una línea (que creo que se ve terrible) .

Answer 5

En mi opinión, un ancho de línea de 78 u 80 caracteres es útil, ya que hace que sea más fácil tener varios archivos abiertos uno al lado del otro en la misma pantalla.

Justificación, ¿qué tal una cita de Linus Torvalds ? :)

La respuesta a eso es que si necesita más de 3 niveles de sangrado, de todas maneras está jodido y debería arreglar su programa.

Normalmente sigo un conglomerado del estilo de codificación de Google C ++ (creo que también puedes adaptar esto a Java) y este estilo de codificación C ++ .

Answer 6

Estoy de acuerdo con "No luche contra el IDE".

Sin embargo, mi IDE (Eclipse, Visual Studio) quiere romper líneas, es como están rotas.

Esto puede significar incoherencias entre idiomas, lo cual está bien.

Answer 7

He hecho una pregunta similar en el pasado:

¿Dónde envolver una línea de código, especialmente largas listas de argumentos?

La dificultad con este tipo de preguntas es su naturaleza subjetiva, por lo que no pude aceptar una respuesta.

Creo que la parte importante es mantener el estilo de sangrado constante en toda la base de códigos.

Answer 8

La única razón para formatear el código de una manera particular es hacerlo legible. Esto es intrínsecamente subjetivo: hágalo de una manera que se vea bien y que sienta que sería más legible para alguien que mira el código por primera vez. Y voy a desafiar la sabiduría convencional y decir, no te preocupes por ningún estándar común, por dos razones

1) es difícil en esta situación, porque hay tantas posibilidades diferentes para líneas discontinuas

2) no te compra nada. período. de nuevo, el formato de los códigos es simplemente para hacer que su código sea legible, ya que tener una forma estándar de formatear los detalles de su código no le permite legibilidad.

Answer 9

Mantengo las expresiones entre corchetes en el nivel de su apertura:

if ((long test 1) &&
(long test 2) &&
(long test 3)) {
code executed if true;
}

Esto hace que sea obvio en qué nivel está cada expresión.

Answer 10

Me gustan los aparatos ortopédicos en su propia línea porque me parece más fácil ver la condición y el bloqueo interno como un solo elemento (si sabes a qué me refiero):

if ((long test 1)
&& (long test 2)
&& (long test 3))
{
code executed if true;
}

y me gusta comenzar líneas condicionales adicionales con lo que es la condición porque me parece que la condición de "unión" es muy importante y tiende a pasarse por alto al final de la línea anterior.

También intento y doblo tal que el efecto de paréntesis sea obvio (aunque tratar de evitar los largos condicionales es generalmente algo bueno).

Intento estructurar cosas para que pueda "escanear" fácilmente "cosas" :)

Answer 11

Para Java, Oracle proporciona esas convenciones. Convenciones del código de Java: Oracle.

• Descanso después de una coma
• Descanso ante un operador
• Prefiere descansos de mayor nivel a descansos de menor nivel
• Alinea la nueva línea con el comienzo de la expresión en el mismo nivel en la línea anterior
• Si las reglas anteriores conducen a un código confuso o al código aplastado contra el margen derecho, solo sangría 8 espacios en su lugar

Para un ejemplo,

longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; // PREFER
longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6; // AVOID

Otro:

//DON’T USE THIS INDENTATION
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) { //BAD WRAPS
doSomethingAboutIt(); //MAKE THIS LINE EASY TO MISS
}
//USE THIS INDENTATION INSTEAD
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
//OR USE THIS
if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}

Más ejemplos se dan en ese documento.

Answer 12

Siempre sangría, pero si las declaraciones son especiales; Me gusta alinear las pruebas y coloco los operadores extra && a la izquierda:

if ( (long test 1)
&& (long test 2)
&& (long test 3))
{
code executed if true;
}

Tirando de && a la izquierda para alinear con if también es posible, pero encuentro que esta alternativa es más difícil de leer.

Answer 13

Tengo dos reglas simples:

1. Bloque de instrucción: una sangría;
2. Continuación de línea: dos sangrías o paréntesis alineados, lo que sea más indentado.

Entonces, en el caso if:

if (
(long test 1) &&
(long test 2) &&
(long test 3)
) {
code executed if true;
}

Answer 14

Tengo una ligera variación en lo que ya está escrito aquí:

if ((long test 1) &&
(long test 2) &&
(long test 3))
{
code executed if true;
}

Me gusta tener mis operadores booleanos al final de la línea.

Los nombres largos de métodos o métodos con muchos parámetros son los siguientes:

reallyLongMethodName (paramA,
paramB,
paramC);

con los bits alineados con el nombre param anterior; no el soporte ...

Además, para reducir la sangría, comencé a usar múltiples puntos de retorno en mi código, así como también continué y rompí mis bucles. p.ej

for(int i = 0; i < MAX; i++)
{
if(!isPrime(i)) // predefined prime finding func
continue;
//now we have only prime values of i
}

Answer 15

Yo diría que realmente no importa qué método use siempre que cumpla con los siguientes criterios:

• es sensato
• aplica la misma convención en todo su código.

Si está en un equipo de desarrollo, intente acordar una convención entre usted, por algún mecanismo de votación arcano si no puede llegar a un acuerdo de lo contrario y no hay nadie para dictar.