EstilosProgramacion

ESTILOS DE PROGRAMACIÓN

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

Mérida Julio de 2009

2009 “Año de la Soberanía Científica, Tecnológica e Industrial”Avenida Alberto Carnevali, La Hechicera, Edificio CENDITEL. Teléfono: (58)(274) 8084938 – 6574336 – 6574958.

Fax: 2451044 Apartado Postal: 078.Código Postal: 5101. Página Web: http://www.cenditel.gob.ve. Mérida-Venezuela

Licencia de Uso

Copyright (C) <2009> <JuanVizcarrondo ([email protected]) - Plataforma para el Desarrollo de Software Libre (http://plataforma.cenditel.gob.ve/)> de la Fundación CENDITEL.

La Fundación CENDITEL concede permiso para copiar, distribuir y/o modificar este programa bajo los términos de la licencia de software GPL versión 2.0 de la Free Software Foundation.

Este programa se distribuye con la esperanza de que sea útil, pero SI NINGUNA GARANTÍA; tampoco las implícitas garantías de MERCANTILIDAD o ADECUACIÓN A UN PROPÓSITO PARTICULAR. Consulte la licencia GPL para más detalles.Una copia de la licencia en inglés y en español puede obtenerse en los siguientes sitios en Internet:

En inglés: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

En español: http://www.es.gnu.org/modules/content/index.php?id=8



mailto:[email protected]

Historial de Revisiones

Fecha Versión Descripción Responsable(s)

Abril de 2008

0,01 Desarrollo del documento.

Juan Vizcarrondo

Julio de 2009

0,1 Adaptación de estilos para publicación.

Juan Vizcarrondo



ESTILOS DE PROGRAMACIÓN

Licencia de Uso.................................................................................2

Historial de Revisiones.........................................................................3

Estilos de Programación.........................................................................6

Indentación....................................................................................10

Estilo K&R.....................................................................................14

Estilo Allman..................................................................................14

Estilo BSD KNF.................................................................................15

Estilo Whitesmiths.............................................................................16

Estilo GNU.....................................................................................17

Convención de nombres en identificadores.......................................................17

Identificadores con Multiples Palabras.........................................................19

Notación Camel [10]............................................................................20

Notación C [11]................................................................................21

Notación Húngara [12]..........................................................................21

Otras consideraciones..........................................................................22

Uso de Espacios............................................................................................................ ........................22

Comentar el código [5]....................................................................................................... ..................22

Operadores [14]....................................................................................................................... .............23

Lista de Parámetros en Funciones [14]................................................................................ ................24

Desvío en Llamadas a Funciones [14].................................................................................................. .25



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

Comparación de constantes.......................................................................................................... ........26

Listas................................................................................................................................................. ....26

Nombre y estructura de archivos y directorios.......................................................... ..........................27



Estilos de Programación

Los lenguajes de programación 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, módulos, 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 programación 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 mañana recuperar las ideas que volcó en código hoy.

Dado lo anterior, debería ser clara la motivación para poner atención en el estilo de programación. Los aspectos que normalmente se denominan "estilo" son aspectos relacionados a los lenguajes como medio de comunicación entre personas, y que usualmente no influyen en la comunicación humano-máquina.

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 rígidas, 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 código tiene que estar bien escrito. El problema del estilo es muy recurrente en el desarrollo de software. Muchas veces se escribe el código pensando que la única persona que lo modificará es el mismo programador. Y cuando llega alguien más, y comienza a revisar el código, comienzan los problemas. Peor aún es cuando se mezclan estilos de programación. Que si uno usa notación húngara, 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 guión 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 código sea igual de incomprensible que el anterior. El ejemplo anterior corresponde a un estilo de programación 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, técnica o método que nos ayude a mejorar esas cualidades es bienvenida.



Las cualidades que se ven beneficiadas de forma más directa por un buen estilo son [1]:

● Extensibilidad: La facilidad con que se adapta el software a cambios de especificación. Un buen estilo de código fomenta programas que no sólo resuelven el problema, sino que también reflejan claramente la relación problema/solución. 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 código 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 evolución: 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 código 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 más trabajo "arreglar un código después, que escribirlo bien desde el principio".

● El estilo debe ser uniforme en un mismo proyecto. Al leer un código, uno se acostumbra al estilo usado en una forma que



permite entenderlo con un vistazo general. Si hay código con estilos mezclados, leer algo con un estilo después de haberse acostumbrado a leer algo con otro puede ser confuso. Por ejemplo, si dos tramos de código 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 código debe promover programas que pueden ser comprendidos de forma inmediata (suponiendo el conocimiento del problema que éste resuelve). Los problemas de computación ya son complejos y no hay motivo para aumentar su complejidad con código rebuscado. Los programas deberín ser soluciones, no problemas.

● El estilo no debe promover fragmentos de código que le dan demasiada importancia a detalles irrelevantes. Escribir demasiado, le da relevancia a aspectos no fundamentales, y ocupa la atención en aspectos secundarios del programa. Un buen programa debería enfocar la atención en lo importante, y permitir abstraerse de los detalles.

● El estilo de indentación debe permitir ver la estructura del código sin mirar el código en sí (es decir, con solo ver la distribución de espacio en blanco y espacio escrito). Cuando se busca un tramo de programa o se lee rápido, uno puede visualizar la distribución de espacio blanco/no blanco pero no tiene tiempo para ver estructuras, o concordancia de paréntesis/llaves/corchetes.

● El estilo de indentación debe poder usarse de la misma forma en distintos lenguajes y verse similar (para construcciones linguísticas 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 código debe permitir fácilmente realizar cambios básicos en el código: agregar una línea a un bloque,



borrar una líea de un bloque, mover líneas 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 (función, variable, tipo), debe permitir identificar el objeto de forma no ambigua rápidamente dentro del área de visibilidad del objeto Un estilo de esta forma permite leer el código sin tener que detenerse en cada identificador a recordar (o buscar) donde estaba definido y que era.

Indentación

En el caso de los lenguajes de computadoras, la claridad también 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 rectángulo de base `b' y altura `h' */

return base*altura ;

}

Pero a una persona le transmite mucha más información y contenido la segunda función. En el sentido inverso, para la mayoría de la gente son iguales:

a = 1

b = 2

a = 1 ;



b = 2 ;

Así, la indentación se utiliza para mejorar la legibilidad del código fuente por parte de los programadores, teniendo en cuenta que los compiladores o intérpretes raramente consideran los espacios en blanco entre las sentencias de un programa. Sin embargo, en ciertos lenguajes de programación como Haskell, Occam y Python, la indentación se utiliza para delimitar la estructura del programa permitiendo establecer bloques de código. Indentación es mover un bloque de texto hacia la derecha insertando espacios o tabuladores para separarlo del texto adyacente.un estilo de indentación es la convención [2].

El estilo de indentación se refiere a una convención para la forma en que se coloca la indentación 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 programación de audio



● Cilk - concurrente C para programación 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 indentación más importantes se muestran a continuación:

No hay un "estilo correcto", sino que hay muchos. Definitivamente hay distintos criterios sobre cuál 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 más 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 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.

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 finalización se alinea conceptualemente a la declaración 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 línea para las llaves, e identar el código 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 indentación del codigo claramente diferencia las instrucciones de un bloque con la declaración condicional.

Una desventaja de este estilo es que cada llave de finalización ocupa una linea entera sin añadir 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 más usada para el codigo de la distribución del software del sistema operativo de Berkeley. Es un extensión 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 declaración de un bloque se realiza indentada en la línea 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 implementación de este estilo son las mismas del estilo Allman en que los bloques son claramente separados desde la instrucción de control, Sin embargo en el estilo Whitesmiths, el bloque está conectado visualmente a su declaración de control. Otra ventaja es que la alineación de



las llaves con el bloque entero es visto como un solo conjunto de instrucciones. Además, las llaves hacen hincapié en que el contenido del bloque están subordinados a la declaración de control.

Una desventaja de este estilo podria ser que las llaves ocupan una linea entera.

Otro inconveniente podría ser que el la llave de cierre no se alinea con la declaración a la que conceptualmente pertenecen, aunque otros sostienen que el cierre de llaves pertenece a la llave de apertura y no a la declaración 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";

}

}

Convención de nombres en identificadores

Los identificadores son símbolos léxicos (también llamados símbolos) 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:

if a < 24 and b < 60 and c < 60

return true

else

return false

Debido a la elección de los nombres de las variables, la función del código es difícil de leer y entender. Sin embargo, si los nombres de variables se hacen más 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), debería ser intuitivo, por el puro nombre, qué hace el método, o para qué se emplea la variable. Los nombres tienen que ser claros e intuitivos.



Beneficios: [6]

● Para proporcionar información 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 búsqueda y reemplazo con un mínimo de posibilidad de error.

● Para aumentar la claridad en los casos de posible ambigüedad.

● Para mejorar la estética y apariencia profesional de los trabajos(por ejemplo, se desestiman los nombres excesivamente largos, nombres cómicos o abreviaturas).

● Para ayudar a evitar "colisiones de nombres" que podrían ocurrir cuando el resultado del trabajo de las diferentes organizaciones se combina (namespace [7]).

● De proporcionar los datos que se utilizarán en la entrega de proyectos que requieren la presentación de código fuente de los programas y toda la documentación 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 unión de varias palabras. Para esto, en muchos lenguajes de programacion no es permitido escribir el nombre del identificador con espacios en blanco.



El enfoque más 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 programación 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]:

Notación Camel [10]

Es la práctica de escribir frases o palabras compuestas en el que las palabras se unen sin espacios y se capitalizan. La notación consiste en escribir los identificadores con la primera letra de cada palabra en mayúsculas y el resto en minúscula: DosPalabras. Se llama notación “Camel” porque los identificadores recuerdan las jorobas de un camello. Existen dos variantes:

● UpperCamelCase, CamelCase o PascalCase: en esta variante la primera letra también es mayúscula: DosPalabras.

● lowerCamelCase, camelCase o dromedaryCase: la primera letra es minúscula: dosPalabras.

En el lenguaje Java, se usa la notación CamelCase en identificadores para clases, y dromedaryCase para métodos y variables.



Notación C [11]

Durante los años 1960s, con la estandarización del código ASCII, los primeros programadores de C y UNIX utilizaron el carácter _ como separador: dos_palabras. Esta notación sigue siendo la mas utilizada en C y entornos UNIX. Los defensores de esta notación argumentan que es mas fácil de leer porque deja un espacio entre palabras, al contrario que Camel. Además, en algunos teclados es mas rápido de escribir el carácter _ que una mayúscula.

Notación Húngara [12]

La notaión Húngara se basa en Camel, añadiendo al principio del identificador una secuencia de letras en minúscula, que indica alguna característica 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 comprensión 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 código [5].

No hay absolutamente ninguna excusa para omitir comentar tu código. Pero sí hay límites. Cuando comentas una clase, debes decir cuál es el propósito de la misma, resaltar algunos métodos importantes y sus relaciones con otras clases.

Cuando comentes un método o una función, describe qué hace, no cómo lo hace. Información sobre los parámetros y el valor que la función regrese siempre es útil. Si el método cambia el estado de la clase, sería bueno que lo indicaras.

Al comentar variables, ten en cuenta que en primera instancia el nombre de la misma debería ser lo suficientemente clara. Si por



algún motivo no lo es (i.e. la variable se usa para más de lo que su nombre indica) es recomendable poner un comentario breve al respecto.

Con respecto al código empotrado dentro de un método/función, es bueno que se comente algunos pasos importantes, o el por qué se tomó tal o cuál desición de realizar el algoritmo de la forma en que se lleva a cabo. A veces, para métodos especialmente largos, es bueno comentar por bloques los pasos que va haciendo la función. Asimismo, es necesario no realizar una documentación excesiva de algunos fragmentos obvios del codigo:

// se asigna 0 al valor de retorno de la función.

iValorRetorno = 0;

Operadores [14].

Usar espacios entre operadores binarios: Todos los operadores que tomen dos parámetros deben tener un espacio antes y otro después del operador (Ejemplo: a + b).

No colocar espacios después de un operador unario: No debe haber espacio que separe un operador unario del objeto afectado.(Ejemplo: !a)

Evitar el uso del operador de comparación 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 más fácil de leer que

zUno = (abc > xyz) ? abc : xyz

Usar paréntesis para evitar ambigüedades de precedencia: Deben usarse paréntesis para eliminar ambigüedades 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 dirección y no el puntero.

Operadores Decremento e Incremento: Usar los operadores de incremento "++" y decremento "--" sólo 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();

}

Lista de Parámetros en Funciones [14]

Si la lista de parámetros en la declaración de una funcion no caben en una renglón (linea), los renglones de continuación deben estar indentados hasta el lugar donde comienza la lista de parámetros en el primer renglón.Adicionalmente, si una función que devuelve información por vía de sus parámetros debe devolver en su nombre solamente información de estado.



function (parametro1 = NULL, parametro2 = "Primero",

parametro2 = "Unico", parametro3 = "",

parametro4 = "parametros")

{

if (parametro1)

{

return true;

}

else

{

return false;

}

}

Desvío en Llamadas a Funciones [14]

Cuando un desvío se base en el resultado de un llamado a función, el llamado a función debe estar un renglón 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 más fácil 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 renglón o linea:

a = 2; b =3; no es permitido.

Lo correcto es

a = 2;

b = 3;

Comparación 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 añadir 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 añadido 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 descripción de la tarea que realizan en él. Así, se suele utilizar las mismas notaciones que para los identificadores, pero con una noción adicional que es el uso de extensiones.

Una extensión de archivo o extensión de fichero, es una cadena de caracteres anexada al nombre de un archivo, usualmente antecedida por un punto [13]. Su función 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 declaración 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 división 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] Cómo y porqué programar con buen estilo, Daniel F. Moisset Url: http://educa.di.unc.edu.ar/mod/resource/view.php?id=2904

[2] Indentación, 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] Programación en C++ ,Editorial: Recomendaciones de estilo,, Fernando A. Gómez F. - Artículos sobre programación 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] Notación y estilo en programación, 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



http://educa.di.unc.edu.ar/mod/resource/view.php?id=2904

http://en.wikipedia.org/wiki/Naming_conventions_(programming)

http://en.wikipedia.org/wiki/Curly_bracket_programming_language

http://en.wikipedia.org/wiki/Hungarian_notation

http://wiki.siriux.org/article:programming_style

http://en.wikipedia.org/wiki/CamelCase

http://es.wikipedia.org/wiki/Palabra_clave

http://es.wikipedia.org/wiki/Identificador

http://en.wikipedia.org/wiki/Namespace_(computer_science)



http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)

http://es.wikipedia.org/wiki/Indentaci?n

[13] Extensión de archivo, Wikipedia, la enciclopedia libre, Url: http://es.wikipedia.org/wiki/Extensi%C3%B3n_de_archivo

[14] Guía de Estilo para lenguaje C, Instituto de Ingeniería Eléctrica, Facultad de Ingeniería. Universidad Mayor de la República. 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_Contest

[17] Winning entries, The International Obfuscated C Code Contest, Url: http://www0.us.ioccc.org/years.html#1988



http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest

http://en.wikipedia.org/wiki/Obfuscated_code

http://en.wikipedia.org/wiki/Obfuscated_code

http://iie.fing.edu.uy/ense/asign/str/curso-c/guia-c.htm

http://es.wikipedia.org/wiki/Extensi?n_de_archivo

EstilosProgramacion

Documents

Transcript of EstilosProgramacion