Estilos

ESTILOS DE PROGRAMACIN
(Documento enmarcado en el proyecto de

Plataforma de Desarrollo de Sotware Libre)
Mrida Abril de 2008
AvenidaAlbertoCarnevali,vaLaHechicera,EdificioCENDITEL.Telfono:(0274)2447111.Fax:(0274)2445217.ApartadoPostal:234.
CdigoPostal:5101A.RIF:G200073497.PginaWeb:http://www.cenditel.gob.ve.MridaVenezuela
Licencia de Uso
Copyright (C) <2008> <Plataforma para el Desarrollo de Software

Libre (http://www.cenditel.gob.ve/wikicenditel/doku.php?id=pdsl)>
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 ingls: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
En espaol: http://www.es.gnu.org/modules/content/index.php?id=8
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||FOO;
intF=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*
F/OO/OO);}F_OO()
{
____
_________
____________
______________
_______________
_______________
________________
________________
________________
________________
_______________
_______________
______________
____________
________
____
}
Evidentemente no queremos que nuestro cdigo sea igual de

intentendible 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 posibilidad de corregir errores sin
demasiado esfuerzo.
Capacidad de evolucin: la capacidad de adaptarse a nuevas
necesidades.
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:
floatf(floata,floatb){returna*b;}
typedeffloatlongitud;
typedeffloatarea;
areaarea_rectangulo(longitudbase,longitudaltura){
/*Devuelveelreadeunrectngulodebase`b'yaltura`h'
*/
returnbase*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
C shell (csh)
C++
C#
Ch - interprete C/C++ embebido
ChucK - para programacin de audio
Cilk - concurrente C para programacin paralela de
multihilos
Coyote
Cyclone
D
DINO
E
ECMAScript
ActionScript
DMDScript
E4X
JavaScript
JScript
MDMscript
Ferite
Frink
ICI
Java
Groovy
Join Java
X10
Objective-C
Perl
PHP
Pico
Pike
rc
TSL
UnrealScript
Windows PowerShell
Yorick
QuakeC
Los estilo de indentacin ms importantes se muestran a

continuacin:
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
functionsaludar($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 RR
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
functionsaludar($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
functionsaludar($val){
//AQUIEXISTEUNALINEAQUEEXCEDEELESPACIODEVISION
DELACONSOLA,AQUIEXISTEUNA
LINEAQUEEXCEDE
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 de los

identificadores que dependen del lenguaje a utilizar[8]:
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:
ifa<24andb<60andc<60
returntrue
else
returnfalse
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:
ifhoras<24andminutos<60andsegundos<60
returntrue
else
returnfalse
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 (es decir,

metadatos) sobre el uso de un identificador.
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 la claridad en los casos de posible
ambigedad.
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[refnames]).
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 dromedaryCase: la primera letra
es minscula: dosPalabras.
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 : Estudiantes es una variable del tipo Arreglo.
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.
inti;
for(i=0;i<10;++i){
printf("%d",i*i+i);
}
contra
inti;
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:
//seasigna0alvalorderetornodelafuncin.
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)
{
returntrue;
}
else
{
returnfalse;
}
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("Nopudoabrirsearchivo;findeprograma");
terminaAplicacion()
}
else{
haceAlgo();
}
resulta ms fcil de entender que
if((fileHandle=open("unArchivo",READ_ONLY))==NULL){
printf("Nopudoabrirsearchivo;findeprograma");
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",/*todaviatienelacomadetrasdel*/
};
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 free

encyclopedia, Url:
http://en.wikipedia.org/wiki/Curly_bracket_programming_language
[4] The C Programming Language, Kernighan y Ritchies, Url:

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/editorial-recomendaciones-
de-estilo.html
[6] Naming conventions (programming), Wikipedia, the free

encyclopedia, Url:
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:

http://es.wikipedia.org/wiki/Identificador
[9] Palabra clave, Wikipedia, la enciclopedia libre, Url:

http://es.wikipedia.org/wiki/Palabra_clave
[10] CamelCase, Wikipedia, the free encyclopedia, Url:

http://en.wikipedia.org/wiki/CamelCase
[11] Notacin y estilo en programacin, wiki.siriux.org, Url:

http://wiki.siriux.org/article:programming_style
[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 free encyclopedia, Url:

http://en.wikipedia.org/wiki/Obfuscated_code
[16] International Obfuscated C Code Contest, Wikipedia, the free

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

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

Estilos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estilos

Cargado por

Copyright:

Formatos disponibles

ESTILOS DE PROGRAMACIN

(Documento enmarcado en el proyecto de

Mrida Abril de 2008

Copyright (C) <2008> <Plataforma para el Desarrollo de Software

La Fundacin CENDITEL concede permiso para copiar, distribuir y/o

Este programa se distribuye con la esperanza de que sea til,

Una copia de la licencia en ingls y en espaol puede obtenerse

Dado lo anterior, debera ser clara la motivacin para poner

Las reglas de estilo son flexibles. Esto no significa que

No basta con escribir un programa que funcione. El cdigo

Evidentemente no queremos que nuestro cdigo sea igual de

As, la meta final del programador es construir programas. Y

Las cualidades que se ven beneficiadas de forma ms directa

Algunas consideraciones al momento de programar con estilos [1]:

El estilo del cdigo no es un resultado final, sino algo

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

El estilo no debe promover fragmentos de cdigo que le dan

El estilo de indentacin debe permitir ver la estructura del

El estilo de indentacin debe poder usarse de la misma forma

El estilo de cdigo debe permitir fcilmente realizar

El nombre de un objeto cualquiera del programa (funcin,

En el caso de los lenguajes de computadoras, la claridad

Pero a una persona le transmite mucha ms informacin y

As, la indentacin se utiliza para mejorar la legibilidad

El estilo de indentacin se refiere a una convencin para la

Los estilo de indentacin ms importantes se muestran a

No hay un "estilo correcto", sino que hay muchos.

El estilo K&R es el ms usado en el lenguaje C y PHP. El estilo

El estilo Allman fue definido por Eric Allman. Se trata de crear

Ventaja de este estilo es que la indentacin del codigo

Una desventaja de este estilo es que cada llave de

Tambien conocido como estilo Kernel Normal Form, es la

El estilo Whitesmiths tambien llamado estilo Wishart. Este

Las ventajas obtenidas mediante la implementacin de este

Una desventaja de este estilo podria ser que las llaves

Otro inconveniente podra ser que el la llave de cierre no

El estilo GNU coloca una llave sobre la siguiente linea. Las

Convencin de nombres en identificadores

Los identificadores son smbolos lxicos (tambin llamados

Existen algunas restricciones para la seleccion de los

No se pueden utilizar identificadores que correspondan con

Las selecciones apropiadas para los identificadores se

Por ejemplo, considere el siguiente fragamento de codigo:

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

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

Para proporcionar informacin adicional (es decir,

Identificadores con Multiples Palabras

Al momento de nombrar identificadores es comun que una sola

El enfoque ms comun consiste en definir delimitadores para

Es la prctica de escribir frases o palabras compuestas en

UpperCamelCase, CamelCase o PascalCase: en esta variante la

En el lenguaje Java, se usa la notacin CamelCase en

Durante los aos 1960s, con la estandarizacin del cdigo

Notacin Hngara [12]

La notain Hngara se basa en Camel, aadiendo al principio

fpPrecio: Precio es una variable en punto flotante.

Haciendo un buen uso de espacios entre el codigo de

Comentar el cdigo [5].

No hay absolutamente ninguna excusa para omitir comentar tu

Cuando comentes un mtodo o una funcin, describe qu hace,

Al comentar variables, ten en cuenta que en primera

Con respecto al cdigo empotrado dentro de un

No colocar espacios despus de un operador unario: No debe