Costumbres del código: Uso de las llaves en programación { } – Parte 2
Publicado el 28 de mayo de 2008El post anterior sobre costumbres del código tuvo bastante participación por parte de los lectores, que se animaron a compartir sus opiniones en los comentarios. Así que como se fue largo el tema escribo a modo de continuación.
Gracias a un post de Algoritmática(el sitio ya no existe lamentablemente), “Código más bonito”, del que nos comentaba Eduardo, aprendí un poco más respecto a la indentación. Como dice en su blog, existen varios estilos reconocidos mundialmente de indentación. Entre ellos, la forma a la que me refería que me gustaba escribir el código lleva el nombre de Estilo K&R y BSD KNF:
El estilo K&R es el más usado en el lenguaje C y PHP. Se trata de abrir la llave en la misma línea de declaración de la orden, indentando los siguientes pasos al mismo nivel que la llave y cerrando la llave en el mismo nivel que la declaración. Normalmente las tabulaciones en windows son de 4 espacios, cuando las tabulaciones tienen 8 espacios se trata del estilo BSD o KNF, muy usado en Linux.
Y muestra como ejemplo:
function saludar($val){ if($val == 1) { echo "Hola!"; } else { echo "Chau!"; } } |
También están el Estilo Allman (el que aparentemente utiliza la mayoría) y el Estilo GNU (parecido pero con diferencias en la indentación de espacios).
Respecto a si el estilo K&R queda más aglutinado o fácil de leer, es cuestión de costumbre. No pienso que por no dejar una línea con una llave nada más el código sea menos legible, al contrario. Es más, cuando veo código así, lo corrijo, para leerlo mejor por mi parte. Pero tenemos casos por ejemplo el de Diego que comenta que usa un estilo específico no por comodidad, sino por un estándar en su trabajo.
Por cierto, este tema es hablando de ahorrar líneas en el sentido de organización y facilidad para la lectura del código, no de espacio. Obviamente hoy en día un salto de línea más o menos no afecta en los recursos o el espacio.
También a veces hago como comenta Menda, que usa una sola línea para los if simples:
if (condicion) printf (“yes!”); |
Si es algo bastante sencillo, no es necesario seguir toda la estructura ni siquiera usar las llaves para que quede legible.
Sí estoy a favor de dejar un salto de línea entre bloques importantes, por ejemplo entre dos funciones deberíamos dejar por lo menos un salto de línea vacío para identificar donde termina una y comienza la otra. Y la idea de agregar un comentario con la definición del comienzo de una función en el cierre de bloques también resulta práctica.
Hoy en el trabajo modifiqué las opciones del VS para que no agregue el salto de línea innecesario que les hablaba.
Blaxter, Marto, Omar, DonPiluso, Lino, FaCuZ, Pablo, Edder, kbza, Diego, Marto, Leandro, dm, Menda y eduardomatica, muchas gracias por sus aportes y un saludo para todos! Fue muy interesante este intercambio.
17 comentarios en este post
Feed de comentarios-
Costumbres del código: Uso de las llaves en programación { } | Picando Código |
3 junio. 2008 - 04:42
[…] web, software libre, videojuegos y más « Weezer: Porks and Beans – Culto al geek Costumbres del código: Uso de las llaves en programación { } – Parte 2 » Wed May […]
-
UnLugar » Blog Archive » Programando con estilo |
11 junio. 2008 - 20:21
[…] este post el algorítmica (al que llegué por este post de Picando Código) me encuentro con los nombres de las distintas formas de indentar el código fuente de un […]
-
Costumbres del código: [Lenguaje del teclado] | Picando Código |
25 junio. 2008 - 10:58
[…] vez de . y “Shift 7“). También los corchetes rectos y las llaves, de las cuales mucho hablamos… La arroba se hace con Shift 2, más práctico también que “Alt 2” o “Alt […]
pablo 29 mayo. 2008 - 08:57
Si usaras python no perderias el tiempo planteandote este dilema.
Federico Wagner 29 mayo. 2008 - 11:48
Cuando programaba en C me acostumbre al estilo de K&R, pero ahora prefiero el estilo de Python
def saludar(val):
if val == 1:
print “Hola!”
else:
print “Chau!”
Federico Wagner 29 mayo. 2008 - 11:49
Va de nuevo el código, sorry
def saludar(val):
if val == 1:
print "Hola!"
else:
print "Chau!"
Menda 29 mayo. 2008 - 12:57
¡Fue un placer Fernando!
Leo mucho tu blog y me parece fenomenal. ¡Sigue así!
Eduardo 29 mayo. 2008 - 15:56
Un gusto Fernando el que te haya gustado el artículo 😀 .
Yo también suelo cambiar el estilo si el código es de otro, y está en K&R lo cambio por Allman agregandole las lineas xD
Es una manía jejeje, por lo que por ejemplo, vos y yo no podríamos trabajar bien en equipo 😀 yo cambiando tu codigo y vos el mio xD (claro habría que hacer lo que hacen en el laburo de Diego, pero ¿cuál elegiriamos y con qué argumentos?)
No creo que sea solo cuestión de gustos, algún transfondo teórico/psicológico debe haber en todo esto 🙂
Salu2 amigo.
Carlos Antelo 29 mayo. 2008 - 16:30
y… mientras no programes en Perl, podes usar indent u otro programa ( solo perl puede parsear Perl ) para mi lo mejor es plantearse unas reglas generales de estilo para todo el equipo cuando arrancan y seguirlas, no creo que haya un método universal para sangrar que sea perfecto, cada lenguaje, cada proyecto, cada persona, tiene sus costumbres, gustos y necesidades, cada programa va a tener su propio sabor.
fernando 29 mayo. 2008 - 16:43
pablo:
No es un dilema, simplemente planteamos una discusión amena y estudiamos el tema para conocer otras perspectivas.
Todavía no le he entrado a Python, aunque pienso estudiarlo más a fondo ni bien pueda. De todas formas, C y su sintaxis siempre están presentes, por lo que difícilmente nos deshagamos de las llaves {}
Eduardo: Estaría bueno hacer un análisis psicológico detrás de cada programador y porqué usa cada estilo. Aunque creo que encontraríamos cosas que podrían herir la sensibilidad de los demás mortales… mejor no!
Cuando se trabaja en equipo siempre se preestablece un estándar para que todos hagan lo mismo. De todas formas, uno siempre le corrige esas manías al otro 😛 (me pasó).
Carlos: Así es,”cada maestro con su librito” dicen.
¿Porqué querría programar en perl? 😀
Perl: -1
Federico Wagner 29 mayo. 2008 - 18:03
En cuanto puedas entrale a python, vale la pena.
En cuanto a mi comentario anterior, la gracia estaba en que se viera la identación de python, como no es posible mostrarlo en los comentarios públique un post que me permite mostrar la pieza de código correctamente (y con resaltado de sintaxys), lo pueden ver en http://www.proximamente.org/blog/?p=28
Diego Gadola 29 mayo. 2008 - 19:15
Hay casos en los que no esta bueno lo que decis de hacer if simples en una linea, un ejemplo es cuando queres contar las lineas logicas de tu programa, esto se utiliza para poder tener una idea(por silmilitud del programa, etc) para estimar tiempo al crear proximos programas y funciona ya que se puede correlacionar las lineas logicas de un programa con el tiempo que te lleva en desarrollarlo. En ese caso hay que elegir un estandar de codificacion, que te permita contar lineas logicas de manera facil, o sea una linea logica por linea fisica de codigo.
Aca dejo un link donde puden ver algo mas explicado del tema, por si no se entiende lo que puse… 🙁
Este es mi primer comentario en el blog!, epero que aporte algo…
saludos
fernando 30 mayo. 2008 - 01:25
Federico, ya ví tu post, gracias! Voy a probar de instalar algún otro plugin para la sintaxis, porque el hecho de no respetarte las indentaciones no existe!
Diego: Gracias por tu primer comentario, bienvenido! Muy valioso tu aporte, un punto de vista que no se había considerado en la discusión.
Saludos!
yny 26 septiembre. 2008 - 13:01
nadamas les pido ayuda necesito un programa que cuente las lieas logicas y fisicas del mismo programa porfavor ayuda¡¡¡¡¡¡¡¡ en java
fernando 26 septiembre. 2008 - 13:53
yny:
Puedes pedir ayuda en el foro de programacion.
a 9 junio. 2012 - 07:29
La defensa que se hace de Phyton empieza a parecerme al talibanismo de los que defienden linux.
Ricardo 4 marzo. 2018 - 18:08
Amigos, se supone que un lenguaje de programación debe ser una herramienta de gran ayuda, amistosa, simple, poderosa de sintaxis simple para todos y no geroglifico egipcio para los escogidos por los dioses.