Estilos Programacion

ESTILOS DE PROGRAMACIN
(Documento enmarcado en el proyecto de

Plataforma de Desarrollo de Sotware Libre)
Mrida Julio de 2009
2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Avenida Alberto Carnevali, La Hechicera, Edificio CENDITEL. Telfono: (58)(274) 8084938 6574336 6574958.
Fax: 2451044 Apartado Postal: 078.
Cdigo Postal: 5101. Pgina Web: http://www.cenditel.gob.ve. Mrida-Venezuela
Licencia de Uso
Copyright
(C)
<2009>
<JuanVizcarrondo
(jvizcarrondo@cenditel.gob.ve) - Plataforma para el Desarrollo de
Software
Libre
(http://plataforma.cenditel.gob.ve/)>
de
la
Fundacin CENDITEL.
La Fundacin CENDITEL concede permiso para copiar, distribuir
y/o modificar este programa bajo los trminos de la licencia de
software GPL versin 2.0 de la Free Software Foundation.
Este programa se distribuye con la esperanza de que sea til,
pero SI NINGUNA GARANTA; tampoco las implcitas garantas de
MERCANTILIDAD o ADECUACIN A UN PROPSITO PARTICULAR. Consulte la
licencia
GPL
para
ms
detalles.
Una copia de la licencia en ingls y en espaol puede obtenerse en
los siguientes sitios en Internet:
En
2.0.html
ingls:
http://www.gnu.org/licenses/old-licenses/gpl-
En
http://www.es.gnu.org/modules/content/index.php?id=8
espaol:

Historial de Revisiones
Fecha
Versin
Descripcin
Responsable(s)
Abril de
2008
0,01
Desarrollo
documento.
Julio de
2009
0,1
Adaptacin
de Juan Vizcarrondo
estilos
para
publicacin.
del Juan Vizcarrondo

ESTILOS DE PROGRAMACIN
Licencia de Uso.................................................................................2
Historial de Revisiones.........................................................................3
Estilos de Programacin.........................................................................6
Indentacin....................................................................................10
Estilo K&R.....................................................................................14
Estilo Allman..................................................................................14
Estilo BSD KNF.................................................................................15
Estilo Whitesmiths.............................................................................16
Estilo GNU.....................................................................................17
Convencin de nombres en identificadores.......................................................17
Identificadores con Multiples Palabras.........................................................19
Notacin Camel [10]............................................................................20
Notacin C [11]................................................................................21
Notacin Hngara [12]..........................................................................21
Otras consideraciones..........................................................................22
Uso de Espacios............................................................................................................ ........................22
Comentar el cdigo [5]....................................................................................................... ..................22
Operadores [14]....................................................................................................................... .............23
Lista de Parmetros en Funciones [14]................................................................................ ................24
Desvo en Llamadas a Funciones [14].................................................................................................. .25

Una Sentencia por Linea................................................................................................................... ....26

Comparacin de constantes.......................................................................................................... ........26
Listas................................................................................................................................................. ....26
Nombre y estructura de archivos y directorios.......................................................... ..........................27

Estilos de Programacin
Los lenguajes de programacin tienen la particularidad de
cumplir un doble rol. Por un lado sirven para comunicar humanos
con computadoras. Son la forma de transformar una serie de
abstracciones como algoritmos, mdulos, tipos de datos y sistemas
en algo que una computadora pueda ejecutar. El segundo rol, y que
no se ve tanto a primera vista, es que un lenguaje de programacin
sirve para comunicar humanos con humanos. Por ejemplo, para que
alguien le cuente un algoritmo a otro. O en muchos casos para que
un programador pueda maana recuperar las ideas que volc en
cdigo hoy.
Dado lo anterior, debera ser clara la motivacin para poner
atencin en el estilo de programacin. Los aspectos que
normalmente se denominan "estilo" son aspectos relacionados a los
lenguajes como medio de comunicacin entre personas, y que
usualmente no influyen en la comunicacin humano-mquina.
Las reglas de estilo son flexibles. Esto no significa que uno
va escribiendo y cambiando de estilo. Es muy importante dentro de
un mismo proyecto mantener siempre las mismas reglas rgidas,
aunque estas sean distintas a las que uno usa en otros proyectos.
Incluso, cuando se trabaja sobre un proyecto escrito por otro, es
mejor adaptarse al estilo en que est escrito en vez de
mezclarlos.
No basta con escribir un programa que funcione. El cdigo
tiene que estar bien escrito. El problema del estilo es muy
recurrente en el desarrollo de software. Muchas veces se escribe
el cdigo pensando que la nica persona que lo modificar es el
mismo programador. Y cuando llega alguien ms, y comienza a
revisar el cdigo, comienzan los problemas. Peor an es cuando se
mezclan estilos de programacin. Que si uno usa notacin hngara,
que si otro emplea camelCase, que si otro prefija las variables
con el alcance de la variable, que si para las variables miembro
se les prefija con una m_, o simplemente con el guin bajo, o no
se les prefija. El no tener estilos claros podrian generar en
estructuras como:
#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_
_-_-_-_
}
Evidentemente no se quiere que nuestro cdigo sea igual de

incomprensible que el anterior. El ejemplo anterior corresponde a
un estilo de programacin definida como codigo ofuscado [15], que
busca no hacer compesible el codigo fuente de los programas y
resulto el ganador del International Obfuscated C Code Contest
[16] de 1988 [17].
As, la meta final del programador es construir programas. Y
el ideal es construir "buenos" programas. Hay diversas cualidades
generalmente aceptadas de lo que es un programa "bueno", y
cualquier herramienta, tcnica o mtodo que nos ayude a mejorar
esas cualidades es bienvenida.

Las cualidades que se ven beneficiadas de forma ms directa

por un buen estilo son [1]:
Extensibilidad: La facilidad con que se adapta el
software a cambios de especificacin. Un buen estilo de
cdigo fomenta programas que no slo resuelven el problema,
sino
que
tambin
reflejan
claramente
la
relacin
problema/solucin. Esto tiene como efecto que muchos cambios
simples en el problema reflejen de forma obvio los cambios a
hacer en el programa.
Verificabilidad: la facilidad con que pueden comprobarse

propiedades de un sistema. Si el estilo de cdigo hace obvia
la estructura del programa, eso ayuda a verificar que el
comportamiento sea el esperado.
Reparabilidad: la
demasiado esfuerzo.
posibilidad de corregir errores sin
Capacidad de evolucin:
nuevas necesidades.
la
capacidad
de
adaptarse
Comprensibilidad: la facilidad con que el programa puede

ser comprendido.
Algunas consideraciones al momento de programar con estilos

[1]:
El estilo del cdigo no es un resultado final, sino algo
para preservar a lo largo de toda su escritura. Es cierto que
las primeras veces escribir con estilo requiere un esfuerzo
consciente, una vez que uno se acostumbra al estilo, seguirlo
deja de ser un esfuerzo adicional. Usualmente es ms trabajo
"arreglar un cdigo despus, que escribirlo bien desde el
principio".
El estilo debe ser uniforme en un mismo proyecto. Al leer

un cdigo, uno se acostumbra al estilo usado en una forma que

permite entenderlo con un vistazo general. Si hay cdigo con

estilos mezclados, leer algo con un estilo despus de haberse
acostumbrado a leer algo con otro puede ser confuso. Por
ejemplo, si dos tramos de cdigo usan distintas abreviaturas
para lo mismo, o distintas formas de indentar (que pueden
hacer que dos estructuras de control iguales se vean
diferentes).
El estilo de cdigo debe promover programas que pueden
ser
comprendidos
de
forma
inmediata
(suponiendo
el
conocimiento del problema que ste resuelve). Los problemas
de computacin ya son complejos y no hay motivo para aumentar
su complejidad con cdigo rebuscado. Los programas debern
ser soluciones, no problemas.
El estilo no debe promover fragmentos de cdigo que le

dan demasiada importancia a detalles irrelevantes. Escribir
demasiado, le da relevancia a aspectos no fundamentales, y
ocupa la atencin en aspectos secundarios del programa. Un
buen programa debera enfocar la atencin en lo importante, y
permitir abstraerse de los detalles.
El estilo de indentacin debe permitir ver la estructura

del cdigo sin mirar el cdigo en s (es decir, con solo ver
la distribucin de espacio en blanco y espacio escrito).
Cuando se busca un tramo de programa o se lee rpido, uno
puede visualizar la distribucin de espacio blanco/no blanco
pero no tiene tiempo para ver estructuras, o concordancia de
parntesis/llaves/corchetes.
El estilo de indentacin debe poder usarse de la misma

forma
en
distintos
lenguajes y
verse
similar
(para
construcciones lingusticas similares). Muchas veces es
necesario cambiar de lenguaje (entre un proyecto o entre
varios), y preservar un estilo uniforme permite no tener que
estar fabricando reglas nuevas cada vez.
El estilo de cdigo debe permitir fcilmente realizar

cambios bsicos en el cdigo: agregar una lnea a un bloque,

borrar una lea de un bloque, mover lneas en un bloque. Este

tipo de cambios es muy usual, y si el estilo dificulta
realizarlos interrumpe en la forma de trabajo.
El nombre de un objeto cualquiera del programa (funcin,
variable, tipo), debe permitir identificar el objeto de forma
no ambigua rpidamente dentro del rea de visibilidad del
objeto Un estilo de esta forma permite leer el cdigo sin
tener que detenerse en cada identificador a recordar (o
buscar) donde estaba definido y que era.
Indentacin
En el caso de los lenguajes de computadoras, la claridad
tambin depende de a quien se dirija el lenguaje. Por ejemplo,
para lo computadora son equivalentes las funciones:
float f(float a, float b) {return a*b ;}
typedef float longitud ;
typedef float area ;
area area_rectangulo (longitud base, longitud altura) {
/* Devuelve el rea de un rectngulo de base `b' y altura `h' */
return base*altura ;
}
Pero a una persona le transmite mucha ms informacin y

contenido la segunda funcin. En el sentido inverso, para la
mayora de la gente son iguales:
a=1
b = 2
a = 1 ;

b = 2 ;
As, la indentacin se utiliza para mejorar la legibilidad del

cdigo fuente por parte de los programadores, teniendo en cuenta
que los compiladores o intrpretes raramente consideran los
espacios en blanco entre las sentencias de un programa. Sin
embargo, en ciertos lenguajes de programacin como Haskell, Occam
y Python, la indentacin se utiliza para delimitar la estructura
del programa permitiendo establecer bloques de cdigo. Indentacin
es mover un bloque de texto hacia la derecha insertando espacios o
tabuladores para separarlo del texto adyacente.un estilo de
indentacin es la convencin [2].
El estilo de indentacin se refiere a una convencin para la
forma en que se coloca la indentacin en un programa, usualmente
los basados en la familia curly bracket [3]:
ABCL/c+
Alef o Limbo
AutoHotkey
AWK
BCPL
C shell (csh)
C++
C#
Ch - interprete C/C++ embebido
ChucK - para programacin de audio

Cilk multihilos
concurrente
Coyote
Cyclone
DINO
ECMAScript
ActionScript
DMDScript
E4X
JavaScript
JScript
MDMscript
Ferite
Frink
ICI
Java
Groovy
para
programacin
paralela
de

Join Java
X10
Objective-C
Perl
PHP
Pico
Pike
rc
TSL
UnrealScript
Windows PowerShell
Yorick
QuakeC
Los estilo
continuacin:
de
indentacin
ms
importantes
se
muestran
No
hay
un
"estilo
correcto",
sino
que
hay
muchos.
Definitivamente hay distintos criterios sobre cul de ellos es el
mejor, y discusiones bizantinas al respecto. De todos modos, si
hay un acuerdo bastante generalizado sobre varias cosas que se
consideran "mal estilo".

Estilo K&R
El estilo K&R es el ms usado en el lenguaje C y PHP. El
estilo K&R, fue llamado de esta forma porque fue usado por
Kernighan y Ritchies en su libro The C Programming Language [4].
Se trata de abrir la llave en la misma lnea de declaracin de la
orden, indentando los siguientes pasos al mismo nivel que la llave
y cerrando la llave en el mismo nivel que la declaracin.
Ejemplo:
function saludar($val) {
if($val == 1) {
echo "HOLA";
}
else {
echo "CHAO";
}
}
La ventaja de este estilo es que la llave de apertura no

requiere una linea extra y llave de finalizacin se alinea
conceptualemente a la declaracin conceptual a la que pertenece.
Una desventajade este estilo es quela llave final de un bloque
toma una linea enterf, el cual podria se parcialmente resuelto en
los bloques if/else y do/while
Estilo Allman
El estilo Allman fue definido por Eric Allman. Se trata de
crear una nueva lnea para las llaves, e identar el cdigo debajo
de ellas. La llave de cierre tiene el mismo identado que la de
inicio.
function saludar($val)

{
if($val == 1)
{
echo "HOLA";
}
else
{
echo "CHAO";
}
}
Ventaja de este estilo es que la indentacin del codigo

claramente diferencia las instrucciones de un bloque con la
declaracin condicional.
Una desventaja de este estilo es que cada llave de
finalizacin ocupa una linea entera sin aadir ningun codigo. Este
problema era importante cuando un programador programaba codigo en
un terminal que mostraba 24 lineas.
Estilo BSD KNF
Tambien conocido como estilo Kernel Normal Form, es la manera
ms usada para el codigo de la distribucin del software del
sistema operativo de Berkeley. Es un extensin del estilo K&R. Se
define un tabulador duro (8 espacios) el cual es usado para
indentar bloques de codigo, mientras un tabulador suave (4
espacios) para todas las lineas continuas que exceden el espacio
de vision de la consola.
function saludar($val) {
//AQUI EXISTE UNA LINEA QUE EXCEDE EL ESPACIO DE VISION DE LA
CONSOLA, AQUI EXISTE UNA
LINEA QUE EXCEDE

if($val == 1) {
echo "HOLA";
}
else {
echo "CHAO";
}
}
Estilo Whitesmiths
El estilo Whitesmiths tambien llamado estilo Wishart. Este
estilo coloca las llaves asociadas con la instrucciones de control
indentada en la
siguiente linea. Este estilo pone la llave que
sigue a la declaracin de un bloque se realiza indentada en la
lnea siguiente. Instrucciones dentro del bloque son indentados en
el mismo nivel que la llave.
{
if($val == 1)
{
echo "HOLA";
}
else
{
echo "CHAO";
}
}
Las ventajas obtenidas mediante la implementacin de este

estilo son las mismas del estilo Allman en que los bloques son
claramente separados desde la instruccin de control, Sin embargo
en el estilo Whitesmiths, el bloque est conectado visualmente a
su declaracin de control. Otra ventaja es que la alineacin de
las llaves con el bloque entero es visto como un solo conjunto de

instrucciones. Adems, las llaves hacen hincapi en que el
contenido del bloque estn subordinados a la declaracin de
control.
Una desventaja de este estilo podria ser que las llaves
ocupan una linea entera.
Otro inconveniente podra ser que el la llave de cierre no se
alinea con la declaracin a la que conceptualmente pertenecen,
aunque otros sostienen que el cierre de llaves pertenece a la
llave de apertura y no a la declaracin de control.
Estilo GNU
El estilo GNU coloca una llave sobre la siguiente linea. Las
llaves son indentadas por 2 espacios,y el codigo que contiene
indentada por 2 espacios adicionales.
{
if($val == 1)
{
echo "HOLA";
}
else
{
echo "CHAO";
}
}
Convencin de nombres en identificadores

Los identificadores son smbolos lxicos (tambin llamados
smbolos) que nombran entidades del lenguaje, tales como las
constantes, los tipos de dato, las etiquetas, las subrutinas, los

paquetes y las subrutinas (procedimientos y funciones) [8].
Existen algunas restricciones para la seleccion
identificadores que dependen del lenguaje a utilizar [8]:
de
los
No se pueden utilizar identificadores que correspondan con

palabras claves o reservadas del lenguaje [9] y restricciones en
qu caracteres pueden aparecer en un identificador (Ejem. no est
permitido el uso de espacios en blanco, operadores del lenguaje,
ni acentos, entre otros).
Las selecciones apropiadas para los identificadores se
consideran como la piedra angular para un buen estilo. Un nombre
pobre para el identificador por ejemplo hace el codigo dificil de
leer y entender.
Por ejemplo, considere el siguiente fragamento de codigo:
if a < 24 and b < 60 and c < 60
return true
else
return false
Debido a la eleccin de los nombres de las variables, la

funcin del cdigo es difcil de leer y entender. Sin embargo, si
los nombres de variables se hacen ms descriptivo:
if horas < 24 and minutos < 60 and segundos < 60
return true
else
return false
As, Dado el contexto (es decir, sabiendo de qu trata la

clase), debera ser intuitivo, por el puro nombre, qu hace el
mtodo, o para qu se emplea la variable. Los nombres tienen que
ser claros e intuitivos.
Beneficios: [6]
Para
proporcionar informacin adicional
metadatos) sobre el uso de un identificador.
(es
decir,
Para ayudar a formalizar las expectativas y fomentar la

coherencia dentro de un equipo de desarrollo.
Para permitir el uso de reconstrucciones automatizadas o

herramientas de bsqueda y reemplazo con un mnimo de
posibilidad de error.
Para aumentar
ambigedad.
la
claridad
en
los
casos
de
posible
Para mejorar la esttica y apariencia profesional de los

trabajos(por ejemplo, se desestiman los nombres excesivamente
largos, nombres cmicos o abreviaturas).
Para ayudar a evitar "colisiones de nombres" que podran

ocurrir cuando el resultado del trabajo de las diferentes
organizaciones se combina (namespace [7]).
De proporcionar los datos que se utilizarn en la entrega

de proyectos que requieren la presentacin de cdigo fuente
de los programas y toda la documentacin pertinente.
Identificadores con Multiples Palabras

Al momento de nombrar identificadores es comun que una sola
palabra no sea suficiente para dar una idea al lector de su
significado en el codigo. Por ello en muchos casos es necesario
nombrar identificadores como la unin de varias palabras. Para
esto, en muchos lenguajes de programacion no es permitido escribir
el nombre del identificador con espacios en blanco.

El enfoque ms comun consiste en definir delimitadores para

realizar la union, tales como el guion (-), y el subrayado (_):
(Ejem. dos-palabras, dos_palabras). En algunos lenguajes de
programacin el guion es reservado para identificar la operacion
de resta. Por lo cual han surgido distintas notaciones para
permitir a los programadores la union de palabras en la definicion
de identificadores [6]:
Notacin Camel [10]
Es la prctica de escribir frases o palabras compuestas en el
que las palabras se unen sin espacios y se capitalizan. La
notacin consiste en escribir los identificadores con la primera
letra de cada palabra en maysculas y el resto en minscula:
DosPalabras. Se llama notacin Camel porque los identificadores
recuerdan las jorobas de un camello. Existen dos variantes:
UpperCamelCase, CamelCase o PascalCase: en esta variante
la primera letra tambin es mayscula: DosPalabras.
lowerCamelCase, camelCase o
letra es minscula: dosPalabras.
dromedaryCase:
la
primera
En el lenguaje Java, se usa la notacin CamelCase en

identificadores para clases, y dromedaryCase para mtodos y
variables.

Notacin C [11]
Durante los aos 1960s, con la estandarizacin del cdigo
ASCII, los primeros programadores de C y UNIX utilizaron el
carcter _ como separador: dos_palabras. Esta notacin sigue
siendo la mas utilizada en C y entornos UNIX. Los defensores de
esta notacin argumentan que es mas fcil de leer porque deja un
espacio entre palabras, al contrario que Camel. Adems, en algunos
teclados es mas rpido de escribir el carcter _ que una
mayscula.
Notacin Hngara [12]
La notain Hngara se basa en Camel, aadiendo al principio
del identificador una secuencia de letras en minscula, que indica
alguna caracterstica del identificador, como su tipo en el caso
de variables. Dentro de la notacion Hungara, existen dos tipos; la
de sistemas y la de aplicaciones. La primera, hace referencia a la
tipo de variables utilizadas en el desarrollo de sistemas, tales
como los tipos de datos: unsigned 32-bit interger, double words.
Mientras que la notacion Hunagara para aplicaciones, utiliza
prefijos descriptivos, que indican al igual que en la de sistema
el tipo de dato, pero estas ultimas, son utilizadas para
aplicaciones que se podrian denominar independientes del
sistema.
Por ejemplo:
fpPrecio: Precio es una variable en punto flotante.
rgStudiantes
Arreglo.
Estudiantes
es
una
variable
del
tipo
rgfpBalances:Balances es un arreglo de punto flotante.
OnMouseDown utiliza el prefijo on (sobre)

Otras consideraciones
Uso de Espacios
Haciendo un buen uso de espacios entre el codigo de programas
es posible facilitar la comprensin de este.
Compare las siguientes estructuras sintactica en el lenguaje
C.
int i;
for(i=0;i<10;++i){
printf("%d",i*i+i);
}
contra
int i;
for (i = 0; i < 10; ++i) {
printf("%d", i*i + i);
}
Comentar el cdigo [5].

No hay absolutamente ninguna excusa para omitir comentar tu
cdigo. Pero s hay lmites. Cuando comentas una clase, debes
decir cul es el propsito de la misma, resaltar algunos mtodos
importantes y sus relaciones con otras clases.
Cuando comentes un mtodo o una funcin, describe qu hace, no
cmo lo hace. Informacin sobre los parmetros y el valor que la
funcin regrese siempre es til. Si el mtodo cambia el estado de
la clase, sera bueno que lo indicaras.
Al comentar variables, ten en cuenta que en primera instancia
el nombre de la misma debera ser lo suficientemente clara. Si por
algn motivo no lo es (i.e. la variable se usa para ms de lo que

su nombre indica) es recomendable poner un comentario breve al
respecto.
Con respecto al cdigo empotrado dentro de un mtodo/funcin,
es bueno que se comente algunos pasos importantes, o el por qu se
tom tal o cul desicin de realizar el algoritmo de la forma en
que se lleva a cabo. A veces, para mtodos especialmente largos,
es bueno comentar por bloques los pasos que va haciendo la
funcin. Asimismo, es necesario no realizar una documentacin
excesiva de algunos fragmentos obvios del codigo:
// se asigna 0 al valor de retorno de la funcin.

iValorRetorno = 0;
Operadores [14].
Usar espacios entre operadores binarios: Todos los operadores
que tomen dos parmetros deben tener un espacio antes y otro
despus del operador (Ejemplo: a + b).
No colocar espacios despus de un operador unario: No debe
haber espacio que separe un operador unario del objeto
afectado.(Ejemplo: !a)
Evitar el uso del operador de comparacin condicional: Se
recomienda evitar el uso del comparador condicional ternario "?".
Todo esto se explica en el siguiente ejemplo:
if (abc > xyz) {
zUno = abc;
}
else {
zUno = xyz;
}
es ms fcil de leer que

zUno = (abc > xyz) ? abc : xyz
Usar parntesis para evitar ambigedades de precedencia: Deben

usarse parntesis para eliminar ambigedades que puedan surgir por
desconocimiento de la precedencia de operadores. Por ejemplo, al
incrementar la variable apuntada por el puntero p_NumVeces,
escribir (*p_NumVeces)++ asegura que se est incrementando el
contenido de la direccin y no el puntero.
Operadores Decremento e Incremento: Usar los operadores de
incremento "++" y decremento "--" slo como sufijo, y no como
parte de otra sentencia. Se prefiere esta forma:
while (cadena[i] != NULL) {
haceAlgo();
i++;
}
enlugarde
while (cadena[i++] != NULL) {
haceAlgo();
}
Lista de Parmetros en Funciones [14]

Si la lista de parmetros en la declaracin de una funcion no
caben en una rengln (linea), los renglones de continuacin deben
estar indentados hasta el lugar donde comienza la lista de
parmetros en el primer rengln.Adicionalmente, si una funcin que
devuelve informacin por va de sus parmetros debe devolver en su
nombre solamente informacin de estado.
function (parametro1 = NULL, parametro2 = "Primero",

parametro2 = "Unico", parametro3 = "",
parametro4 = "parametros")
{
if (parametro1)
{
return true;
}
else
{
return false;
}
}
Desvo en Llamadas a Funciones [14]

Cuando un desvo se base en el resultado de un llamado a
funcin, el llamado a funcin debe estar un rengln aparte. La
forma:
p_FileHandle = fopen("unArchivo", READ_ONLY);
if (p_FileHandle == NULL) {
printf("No pudo abrirse archivo; fin de programa");
terminaAplicacion()
}
else {
haceAlgo();
}
resulta ms fcil de entender que

if ((fileHandle = open("unArchivo", READ_ONLY)) == NULL) {

printf("No pudo abrirse archivo; fin de programa");

terminaAplicacion()
}
else {
haceAlgo();
}
Una Sentencia por Linea

Cada sentencia debe ocupar un solo rengln o linea:
a=2;b=3; no es permitido.
Lo correcto es
a = 2;
b = 3;
Comparacin de constantes
Colocar en las estructuras de control las constantes del lado
derecho:
if ( true == $a ) { ... }
if ( $a == true ) { ... }
Listas
Los diferentes elementos de una lista deberian ser colocados
uno por uno separados por un salto de linea, es una buena practica
aadir el separador de elementos despues del final de cada
elemento.
$arreglo[] = {

"item1",
"item2",
"item3",
/* todavia tiene la coma detras de l */
};
Este esquema previene error de sintaxis cuando los elementos

son reoordenados o aadido nuevos.
Nombre y estructura de archivos y directorios
El nombre de los archivos y directorios de un proyectos deben
ser seleccionados al igual que los identificadores, de tal forma
que le den sentido en el proyecto y den una correcta descripcin
de la tarea que realizan en l. As, se suele utilizar las mismas
notaciones que para los identificadores, pero con una nocin
adicional que es el uso de extensiones.
Una extensin de archivo o extensin de fichero, es una cadena
de caracteres anexada al nombre de un archivo, usualmente
antecedida por un punto [13]. Su funcin principal es diferenciar
el contenido del archivo de modo que el sistema que estamos
programando disponga del procedimiento necesario para ejecutarlo o
interpretarlo (Ejm: MiProyecto.py, MiProyecto.js, MiProyecto.css).
En general siempre es una buena idea que la declaracin de una
clase este contenida en un archivo con el mismo nombre de la
clase. As, en proyectos grandes contar con una estructura de
directorios y archivos, permite la divisin de las distintas
tareas que realiza el programa, facilitando la busquedad,
entendimiento, reemplazo, entre otros. Esta estructura no son
unicas, pero algunas se han convertido casi en estardares
(includes, images, index.html).

Referencias Bibliograficas
[1] Cmo y porqu programar con buen estilo, Daniel F. Moisset Url:
http://educa.di.unc.edu.ar/mod/resource/view.php?id=2904
[2]
Indentacin,
Wikipedia,
la
enciclopedia
libre,
Url:
http://es.wikipedia.org/wiki/Indentaci%C3%B3n
[3] Curly bracket programming language, Wikipedia, the

encyclopedia,
Url:http://en.wikipedia.org/wiki/Curly_bracket_programming_language
free
[4]
Url:
The
Programming
Language,
Kernighan
Ritchies,
http://en.wikipedia.org/wiki/The_C_Programming_Language_%28book%29
[5] Programacin en C++ ,Editorial: Recomendaciones de estilo,,

Fernando A. Gmez F. - Artculos sobre programacin en C++ Url:
http://kithkanan-programacionencpp.blogspot.com/2007/02/editorialrecomendaciones-de-estilo.html
[6] Naming conventions

encyclopedia, Url:
(programming),
Wikipedia,
the
free
http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29
[7] Namespace (computer science), Wikipedia, the free encyclopedia

Url: http://en.wikipedia.org/wiki/Namespace_%28computer_science%29
[8]
Identificador,
Wikipedia,
la
enciclopedia
libre,
Url:
enciclopedia
libre,
Url:
http://es.wikipedia.org/wiki/Identificador
[9]
Palabra
clave,
Wikipedia,
http://es.wikipedia.org/wiki/Palabra_clave
[10]
CamelCase,
Wikipedia,
la
the
free
encyclopedia,
Url:
http://en.wikipedia.org/wiki/CamelCase
[11]
Notacin y
estilo
en
programacin,
http://wiki.siriux.org/article:programming_style
wiki.siriux.org, Url:
[12] Hungarian notation, Wikipedia, the free encyclopedia, Url:

http://en.wikipedia.org/wiki/Hungarian_notation
[13]
Extensin de archivo, Wikipedia, la enciclopedia libre, Url:
http://es.wikipedia.org/wiki/Extensi%C3%B3n_de_archivo
[14] Gua de Estilo para lenguaje C, Instituto de Ingeniera

Elctrica, Facultad de Ingeniera. Universidad Mayor de la
Repblica.
Montevideo,
URUGUAY.
Abril,
1998,
Url:
http://iie.fing.edu.uy/ense/asign/str/curso-c/guia-c.htm
[15]
Obfuscated
code,
Wikipedia,
the
http://en.wikipedia.org/wiki/Obfuscated_code
free
encyclopedia,
Url:
[16] International Obfuscated C Code Contest, Wikipedia, the free

encyclopedia,
Url:
http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
[17] Winning entries, The International Obfuscated C Code Contest,

Url: http://www0.us.ioccc.org/years.html#1988


Estilos Programacion

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Estilos Programacion

Diunggah oleh

Hak Cipta:

Format Tersedia

ESTILOS DE PROGRAMACIN

(Documento enmarcado en el proyecto de

Mrida Julio de 2009

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

del Juan Vizcarrondo

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Una Sentencia por Linea................................................................................................................... ....26

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Evidentemente no se quiere que nuestro cdigo sea igual de

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Las cualidades que se ven beneficiadas de forma ms directa

Verificabilidad: la facilidad con que pueden comprobarse

posibilidad de corregir errores sin

Comprensibilidad: la facilidad con que el programa puede

Algunas consideraciones al momento de programar con estilos

El estilo debe ser uniforme en un mismo proyecto. Al leer

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

permite entenderlo con un vistazo general. Si hay cdigo con

El estilo no debe promover fragmentos de cdigo que le

El estilo de indentacin debe permitir ver la estructura

El estilo de indentacin debe poder usarse de la misma

El estilo de cdigo debe permitir fcilmente realizar

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

borrar una lea de un bloque, mover lneas en un bloque. Este

Pero a una persona le transmite mucha ms informacin y

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

As, la indentacin se utiliza para mejorar la legibilidad del

Ch - interprete C/C++ embebido

ChucK - para programacin de audio

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

La ventaja de este estilo es que la llave de apertura no

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Ventaja de este estilo es que la indentacin del codigo

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Las ventajas obtenidas mediante la implementacin de este

las llaves con el bloque entero es visto como un solo conjunto de

Convencin de nombres en identificadores

constantes, los tipos de dato, las etiquetas, las subrutinas, los

No se pueden utilizar identificadores que correspondan con

Debido a la eleccin de los nombres de las variables, la

As, Dado el contexto (es decir, sabiendo de qu trata la

Para ayudar a formalizar las expectativas y fomentar la

Para permitir el uso de reconstrucciones automatizadas o

Para mejorar la esttica y apariencia profesional de los

Para ayudar a evitar "colisiones de nombres" que podran

De proporcionar los datos que se utilizarn en la entrega

Identificadores con Multiples Palabras

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

El enfoque ms comun consiste en definir delimitadores para

En el lenguaje Java, se usa la notacin CamelCase en

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

fpPrecio: Precio es una variable en punto flotante.

rgfpBalances:Balances es un arreglo de punto flotante.

OnMouseDown utiliza el prefijo on (sobre)

2009 Ao de la Soberana Cientfica, Tecnolgica e Industrial

Comentar el cdigo [5].

algn motivo no lo es (i.e. la variable se usa para ms de lo que

// se asigna 0 al valor de retorno de la funcin.

es ms fcil de leer que