ESTILOS DE PROGRAMACIN (Documento enmarcado en el proyecto de Plataforma de Desarrollo de Sotware Libre)

Mrida Abril de 2008 Descargar Documento en Formato PDF

Licencia de Uso
Copyright (C) <2008> <JuanVizcarrondo? (jvizcarrondoARROBAcenditel.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 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||--F-OO--; int F=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 incomprensible que el anterior. El ejemplo anterior corresponde a un estilo de programacin definida como codigo ofuscado |15|, que busca no hacer compresible 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:
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 ;

s, 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:
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 desventaja de este estilo es quela llave final de un bloque toma una linea enterf, el cual podra 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 cdigo 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 ningn cdigo. Este problema era importante cuando un programador programaba cdigo en un terminal que mostraba 24 lineas.

Estilo BSD KNF

Tambin 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 visin 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 tambin 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.
function saludar($val) { 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 cdigo que contiene indentada por 2 espacios adicionales.
function saludar($val) { 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 cdigo difcil de leer y entender. Por ejemplo, considere el siguiente fragmento de cdigo:
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

s, 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 |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 Mltiples Palabras

Al momento de nombrar identificadores es comn que una sola palabra no sea suficiente para dar una idea al lector de su significado en el cdigo. Por ello en muchos casos es necesario nombrar identificadores como la unin de varias palabras. Para esto, en muchos lenguajes de programacin no es permitido escribir el nombre del identificador con espacios en blanco. El enfoque ms comn consiste en definir delimitadores para realizar la unin, tales como el guion (-), y el subrayado (_): (Ejem. dos-palabras, dos_palabras). En algunos lenguajes de programacin el guion es reservado para identificar la operacin de resta. Por lo cual han surgido distintas notaciones para permitir a los programadores la union de palabras en la definicin 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 notacin 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 notacin 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 notacin Hungara 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 podran 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 cdigo de programas es posible facilitar la comprensin de este. Compare las siguientes estructuras sintcticas 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 decisin 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 cdigo:
// se asigna 0 al valor de retorno de la funcin. iValorRetorno = 0;

10

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++; }

en lugar de
while (cadena[i++] != NULL) { haceAlgo(); }

11

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(); }

12

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

13

estardares (includes, images, index.html).

Referencias Bibliograficas
| 1 | Cmo y porqu programar con buen estilo, Daniel F. Moisset. Ubicacin Electrnica. | 2 | Indentacin, Wikipedia, la enciclopedia libre, Url: Ubicacin Electrnica. | 3 | Curly bracket programming language, Wikipedia, the free encyclopedia, Url: Ubicacin Electrnica. | 4 | The C Programming Language, Kernighan y Ritchies, Url: Ubicacin Electrnica. | 5 | Programacin en C++,Editorial: Recomendaciones de estilo Fernando A. Gmez F.
Artculos sobre programacin en C++.

| 6 | Naming conventions (programming), Wikipedia, the free encyclopedia, Ubicacin Electrnica. | 7 | Namespace (computer science), Wikipedia, the free encyclopedia, Ubicacin Electrnica. | 8 | Identificador, Wikipedia, la enciclopedia libre, Ubicacin Electrnica. | 9 | Palabra clave, Wikipedia, la enciclopedia libre, Ubicacin Electrnica. | 10 | CamelCase, Wikipedia, the free encyclopedia, Ubicacin Electrnica. | 11 | Notacin y estilo en programacin, wiki.siriux.org, Ubicacin Electrnica. | 12 | Hungarian notation, Wikipedia, the free encyclopedia, Ubicacin Electrnica. | 13 | Extensin de archivo, Wikipedia, la enciclopedia libre, Ubicacin Electrnica. | 14 | Gua de Estilo para lenguaje C, Instituto de Ingeniera Elctrica, Facultad de Ingeniera. Universidad Mayor de la Repblica. Montevideo, URUGUAY. Abril, 1998, Ubicacin Electrnica. | 15 | Obfuscated code, Wikipedia, the free encyclopedia, Ubicacin Electrnica. | 16 | International Obfuscated C Code Contest, Wikipedia, the free encyclopedia, Ubicacin Electrnica. | 17 | Winning entries, The International Obfuscated C Code Contest, Ubicacin Electrnica.

14