coding-style - guide - psr-2 español
¿Tratas de hacer que tu código luzca bonito? (30)
La alineación de los parámetros verticalmente se ve bien, sin embargo, para mí no me permite escanear la declaración como una declaración.
He cortado y pegado un fragmento de mí con total obsesión:
public static String intArrayToString( final int[] array ) {
if ( array.length == 0 ) {
return "[]" ;
}
StringBuffer sb = new StringBuffer() ;
sb.append( "[ " ).append( array[ 0 ] ) ;
if ( array.length > 1 ) {
for ( int i = 1 ; i < array.length ; i++ ) {
sb.append( ", " ).append( array[ i ] ) ;
}
}
return sb.append( " ]" ).toString() ;
}
Mucho espacio: esto se debe a que se escribe mucho código de ejemplo, y es un rollover de la escritura puramente para la legibilidad.
Espero que la forma de su segundo ejemplo sea la norma, me enseñaron en el equipo universitario a escribir estas comparaciones como si estuvieran en una línea numérica:
if ( 0 < n && n < 10 ) {
doSomething() ;
}
Y en cuanto al último ejemplo, omitiría la comparación booleana. Un caso verdadero y luego falso
if ( afflicted ) {
doSomething() ;
} else {
doSomethingElse() ;
}
Podría ser un programador anal, pero me gusta el código que se ve bien desde la distancia. Acabo de encontrarme alineando un estilo CSS para que en lugar de esto:
#divPreview {
text-align: center;
vertical-align: middle;
border: #779 1px solid;
overflow: auto;
width: 210px;
height: 128px;
background-color: #fff"
}
ahora se ve así:
#divPreview {
width: 210px;
height: 128px;
overflow: auto;
text-align: center;
vertical-align: middle;
border: #779 1px solid;
background-color: #fff";
}
Casi siempre escribiré comparaciones numéricas en orden de tamaño como
if (0 < n && n < 10)
en lugar de
if (0 < n && 10 > n)
y finalmente tenderé a organizar el código if-then-else para que la parte THEN sea más pequeña que la parte ELSE (porque las cosas más pesadas van hacia abajo, ¿no?)
if (afflicted == true) {
GetSome();
HelpRight();
}
else {
NowPlease();
}
ugh!
if (afflicted == false) {
HowMuchTrouble();
}
else {
IsItToDo();
ThisReally();
}
aahhh
Podría seguir y seguir con más ejemplos, pero entiendes la idea ...
Pregunta: ¿Estoy solo en mi neurosis aquí? ¿Cuál es tu problema de codificación?
Condición positiva primero en una declaración if-else, siempre. La belleza se encuentra dentro.
if (afflicted) {
GetSome();
HelpRight();
} else {
NowPlease();
}
Creo que es absolutamente necesario que el buen código se vea bien y se comente bien. No puedo soportarlo cuando la gente me pide que depure el código sin estructura.
El código debe ser de estilo legible, mantenible y consistente. Personalmente, encuentro que el código con espaciado arbitrario es difícil de leer. ¿Por qué obligar al lector a escanear el código en la pantalla / página para juntar las partes de la declaración? El orden de los bloques de código en la instrucción debe colocarse en orden de lógica, legibilidad y, a veces, ajustado para la optimización. Sin necesidad, espaciar las cosas es una pérdida de tiempo, y hace que el código sea más difícil de leer, no más fácil. ¿Alguien ha leído a McConnell?
El código debe ser fácil de leer y mantener. "Pretty" es completamente coherente con esos requisitos, siempre y cuando no te pongas demasiado mono.
En cierto modo yo soy. Pero estoy más interesado en minimizar. Css es definitivamente mi ejemplo. Es demasiado largo para agregar aquí, pero básicamente, lo ordeno todo.
¿Por qué?
Porque tengo que hacer cambios sobre la marcha mucho más de lo que quiero. La ordenación alfa de todo lo que hay allí me permite simplemente desplazarme rápidamente y llegar a lo que necesita el cambio, todo en una agrupación, en lugar de utilizar la búsqueda y encontrarla en todas partes.
Puede ser nano segundos para todos pero me ahorra mucha frustración y tiempo perdido más tarde.
En mi experiencia, el código bonito generalmente funciona muy bien, mientras que el código feo a menudo se rompe en formas difíciles de detectar. Es cierto que el tipo de mente que presta atención a detalles como el aspecto del código es también el tipo de mente que presta atención a detalles más importantes.
Dicho esto, reordenar los elementos en un estilo CSS para que vayan de corto a largo es un ******** loco.
Es importante hacer que el código se vea "bien", por lo que tenemos convenciones y pautas de estilo. El objetivo es hacer que el código sea fácil de leer y que el código incorrecto se vea mal. Diría que algunos de los ejemplos aquí van más allá y agregan poco valor.
Orden de las propiedades de CSS
#divPreview {
width: 210px;
height: 128px;
overflow: auto;
text-align: center;
vertical-align: middle;
border: #779 1px solid;
background-color: #fff";
}
Me resultaría más útil ser coherente en el orden de las propiedades en lugar de asegurarme de que estén ordenadas en longitud ascendente para cada selector. Esa convención hace que sea más fácil encontrar la que está buscando.
Orden de condicionales
Tu ejemplo aquí tiene sentido para mí porque muestra claramente n está entre 0 y 10.
if (0 < n && n < 10)
Orden de bloques if / else
y finalmente tenderé a organizar el código if-then-else para que la parte THEN sea más pequeña que la parte ELSE (porque las cosas más pesadas van hacia abajo, ¿no?)
Creo que tiene más sentido tener primero la condición positiva (o la condición más esperada). Y el bit "== verdadero" es redundante.
if (afflicted) {
GetSome();
HelpRight();
}
else {
NowPlease();
}
Lo veo un poco diferente. El código debe ser formateado para su legibilidad, no necesariamente "Pretness", aunque esos dos pueden ser lo mismo.
pero como un caso contrario,
if(x != null)
y=x.getParam();
else
y=0;
es más legible que el más bonito:
y = x == null ? 0 : x.getParam();
Sé que el punto es discutible, lo entiendo totalmente y me encanta ese operador y todo, pero para el 95% de los programadores (incluyendo el siguiente para leer su código) va a tomar un poco más analizar.
De hecho, incluso tuve problemas con Ruby''s bastante elegante:
y = x.getParam() if x
Simplemente porque estoy tan acostumbrado a ver las declaraciones de control escaneando la línea izquierda del código.
Debo admitir que me puse un poco débil en las rodillas cuando vi esta sintaxis (creo que es de hascal)
y = x?getParam();
Ese es un nivel de elegancia que incluso puede dominar mis perniciosas percepciones.
Finalmente, aunque el formateo puede ser realmente útil para mostrar patrones en su código, si usted TENÍA patrones en su código, probablemente no lo está haciendo bien.
Siempre que tenga patrones en su código, busque una oportunidad de refactorización. Intente identificar los datos y extráigalos, luego factore las partes repetidas del patrón para que sean un bucle de algún tipo que consuma los datos.
Por cierto, su primer ejemplo fueron los datos, no el código; los datos también necesitan mucho formato, tal vez incluso más.
Me gusta que mi código sea bonito también, pero no donde interfiere con la legibilidad.
Prefiero poner "ruta de acceso feliz" primero en una declaración if, seguida de rutas de excepción. Si espero que una ruta determinada ocurra con más frecuencia que otras, va primero. No necesita ser una condición "positiva" como lo prefiere krosenvold. De esta manera, se lee como mis casos de uso.
(blizpasta me golpeó hasta el golpe con el camino feliz que precede a los caminos de excepción. Menciona la optimización donde deliberadamente lo evité ... Prefiero mi código bastante y legible. La optimización viene en último lugar).
Y en CSS, prefiero los atributos "estructurales" o de diseño primero para poder ver rápidamente dónde va a terminar algo, y solo entonces cómo se verá. Reorganizaría tu primer ejemplo de CSS para que se pareciera a tu segundo, pero por mis motivos, no por el tuyo. :)
Muchas cosas son contextuales para mí.
Espacio o no al espacio ...
puts "ragu"+"pattabi"
puts "ragu " +"pattabi"
puts "ragu " + " pattabi"
Cuánto doblar ...
hr = my_intf->do_the_thing_with( i_1,
i_2,
i_3 );
hr = my_intf->do_the_thing_with( "enter_the_dragon", 1965,
"return_of_the_dragon", 1972 );
hr = my_intf->do_the_thing_with( "enter_the_dragon", "bruce lee", "chinese" );
Tuve que ''tomar muchas decisiones como estas cuando codifico. Sobre todo ayuda, pero mi mente no me deja avanzar más sin acertar con esto. Me estoy recuperando :-)
No estás solo :-) Utilizo a menudo la práctica de alineación (como en la respuesta de Steve):
foo = egg + spam
foobar = sausage + spam
Cuanto más fácil de leer, mejor.
Otra pequeña cosa que trato de hacer sistemáticamente es agrupar los términos en una expresión de acuerdo con la precedencia del operador, es decir,
if (a<b && c<d) ...
x = a*b + c*d
en lugar de
if (a < b && c < d) ...
x = a*b+c*d
No veo el punto en tu ejemplo css ... Steve tiene un ejemplo más legible.
En cuanto a las declaraciones if, no veo rima o razón para poner el más pesado en la parte inferior. Usualmente pongo la situación más comúnmente esperada primero.
Normalmente no hay daño en hacer que se vea "bonita", pero como en la mayoría de las cosas, use moderación. Por ejemplo, preferiría mantener los artículos en el mismo orden cada vez que los artículos similares se agrupen en lugar de clasificarlos. Alinear los operadores y los valores están bien, pero no cambian el orden.
En cuanto a la declaración "si". Siempre pongo el esperado en primer lugar y el excepcional en el último.
Prefiero mantener el estilo de formateo simple. Sangría en bloques, y ordene por lógica / optimización. Uso el formateador del IDE (al menos en Visual Studio, Eclipse y Netbeans) Con CSS, sin embargo, una línea para cada estilo con sangría de niños:
#header {}
#header h1 {}
#header h2 {}
#nav {}
#nav ul {}
#nav li {}
#nav li a {}
#nav li a:hover {}
#content {}
#content p {}
#footer {}
class A {
private int b = 3;
private int c = 2;
public void method(string str) {
if(str != null && str.length > 5)
DoStuffWithString();
else
ShowInvalidError();
}
}
Pretty para mí es legible.
int anInt = 10;
float aFloat = 1.2155;
MyOwnClass myObject = null;
se ve hermosa pero es doloroso leer un código así después de algún tiempo. Y agregar nuevas variables es un dolor en este caso.
Me detengo con
int anInteger = 10;
float aFloat = 1.2155;
MyOwnClass myObject = null;
Mis obsesiones son: un espacio antes y después de los operadores de comparación y una nueva línea antes de un paréntesis de apertura (es extraño por qué las personas no usan de esta manera y prefieren el método de abrir la llave con la misma línea).
Siempre hago que mi código se vea bonito. Me resulta más fácil de leer. Formateo todas las variables y sus valores para que se alineen, y uso espacios en blanco para agrupar lógicamente las cosas. También trato de declarar las variables en el orden en que se usan y en la parte superior del alcance al que pertenecen.
También hago la comparación numérica porque me parece más matemática y es más fácil para mí visualizarla como una recta numérica.
Sin embargo, algunos de sus estilos idiosincrásicos no serán optimizados. Por ejemplo, si tuviera que organizar los casos en una instrucción switch de acuerdo con el número de instrucciones en un caso, no podrá optimizarlo colocando los casos más probables en la parte superior.
No hago programación web, pero supongo que está bien reorganizar el código CSS de la manera en que lo hiciste, ya que el orden en el que aparecen no debería importar. Sin embargo, el orden de ejecución importa en la programación no web, hay que tener cuidado con los efectos secundarios al reorganizar las declaraciones.
Tu ejemplo debería haber sido:
#divPreview {
width: 210px;
height: 128px;
border: #779 1px solid;
overflow: auto;
text-align: center;
vertical-align: middle;
background-color: #fff";
}
Siguiendo el ancho del nombre y no el ancho de línea general. ;)
Pero, sí, estás loco. :PAG
Voy por la borda con mi formato OCD, pero sigo pensando que es importante mantener el código lo más legible posible a menos que tenga una razón realmente convincente para no hacerlo. La razón más importante: el código que escribió hace más de 6 meses puede haber sido escrito por otra persona. Hágase un favor y mantenga su código limpio y consistente.
Yo también sufro de un TOC cuando se trata de formato de código. Estoy con Steve, tabular tus propiedades es el camino a seguir.
var myObj = {
anInt: 3993,
aFunction: function() {alert(''woot'');},
aString: "Random",
aBool: false
}
Eso me lastima un poco. Puede que a algunos no les guste, pero esto me hace sentir mucho mejor:
var myObj = {
anInt: 3993,
aBool: false,
aString: "Random",
aFunction: function() {
alert(''woot'');
}
}
En mi opinión, si paso mucho tiempo en una determinada sección de código, preferiría que no molestara mi sensibilidad visual y me distrajera de la tarea que tenía entre manos. Además, creo que le da al código un toque limpio y profesional que ayuda a agilizar futuras mejoras.
debería ser
if (!afflicted)
{
HowMuchTrouble();
}
else
{
IsItToDo();
ThisReally();
}
compre una bonita impresora y reciba tratamiento por TOC ;-)
Sé que leeré ese código probablemente cerca de 15 veces antes de que se ponga en producción. Pasar el tiempo formateando el código, tal vez parezca que solo estoy haciendo que el código se vea bonito, pero a mí me da un par de segundos pensar en el código antes de pasar al siguiente.
El código que no está estructurado clara y consistentemente es una advertencia para mí, que el desarrollador no entendió el problema lo suficiente como para mostrar sus intenciones con claridad, o al desarrollador que hizo ese código simplemente no le importó. Prefiero no trabajar con un individuo así si tengo una opción. Creo que fue Steve McConnell quien dijo que el compilador realmente no ve cómo se ve el código, pero es un mecanismo para nosotros, los humanos, para trabajar dentro de los límites y limitaciones del cerebro.
Cualquier persona puede escribir código que se ve complejo. Pero se necesita un gran desarrollador para tomar una pieza compleja de código y convertirlo en algo que todo el mundo lo señala y decir, oh sí, eso es fácil y simple de entender.
Para mí, escribir un código legible es lo mejor. No importa cómo sea el formato, siempre y cuando sea legible para otros programadores cuando / si se hacen cargo de la programación, es bonito.
Y siempre tengo comentarios.
Probablemente iría más lejos y haría esto:
#divPreview {
width : 210px;
height : 128px;
overflow : auto;
text-align : center;
vertical-align : middle;
border : #779 1px solid;
background-color : #fff";
}
La única cosa con la que varío en la publicación original sería el condicional. No me veo como un condicional como una cuestión de preferencia de estilo, sino más bien uno lógico. El caso más común sería el primer caso, y pasaría al caso menos común. Se aplica tanto a las sentencias if como a las declaraciones switch en mi código.
Mucha gente mencionó que las herramientas diff mostrarán diffs innecesarios si intenta formatear su código manualmente. Sin embargo, las buenas herramientas de diferencia ignoran los espacios en blanco, por lo que esto no es un problema.
Un punto más importante es que el código escrito por una persona debe ser leído por una persona. Por lo tanto, intente que sea lo más legible posible. Si las piezas blancas adicionales pueden aclarar su código, hágalo. La mayoría de los espacios en blanco se utilizan para la lectura de todos modos. Por ejemplo, la sangría es puramente estética en la mayoría de los idiomas.
Me gusta asegurarme de que haya un espacio adecuado entre las líneas de código, y tengo comentarios que explican las cosas. Ese es el grado de mi limpieza.
En Visual Studio, utilizo Ctrl + K y luego Ctrl + D (código de formato automático) con prudencia para tener todo alineado / espaciado correctamente. Aunque no soy tan OCD como tú :)
El orden alfabético escalas mejor; su beneficio en un archivo CSS complejo es mucho mayor que en un archivo pequeño.
Cualquier estilo de código que te haga reordenar cosas cuando el código cambie es malo.
Sería arruinar diffs. Estás utilizando un sistema de control de versiones ¿no?
Hay algunas otras cosas que harían que tu código fuera más bonito, pero arruinas los diffs.
Imagina este código:
int foo = 42;
int fooBar = 1024;
Ahora vamos a hacerlo más bonito alineando los signos =
int foo = 42;
int fooBar = 1024;
Pero luego agregamos otra variable:
int foo = 42;
int fooBar = 1024;
String nowLetsBeEvil = 6400;
Ahora bien, si hiciste una diferencia, las 3 líneas han cambiado, cuando solo la última.
Y hay más, alinear params entre métodos es malo
sqrt(x + y, x - z);
sqrt(x , x );
La coma y el punto y coma están bien alineados, pero si alguna vez cambias el código, tendrás que reformatear manualmente todas las líneas sqrt que están juntas y arruinar las diferencias de nuevo.
Básicamente, nunca hagas el formateo manual. Haga cumplir siempre los estilos de código usando un IDE o una bonita impresora. Pero tampoco elija nunca un estilo de código donde el formato cambiará cuando su código no lo haga
EDITAR:
Como se afirma en los comentarios, algunas herramientas de diff pueden ignorar espacios en blanco dentro de las líneas. Esto es genial, pero no todas las herramientas de diff pueden hacer esto. Si alinea campos o params, asegúrese de estar:
- No hacerlo manualmente
- Su herramienta diff puede ignorar los cambios en el espacio en blanco