viernes, 4 de junio de 2010

Reglas de Programación y Programa invento

* jive [libro.c]
* jive [estudio.c]

ent a,b,c.

inicio()
{
imp//”Dame valor A”.
alm%a.
Iip//Dame valor B”.
alm%b.
c=a+b.
imp//c.
}
Reglas claves con las que se cumple:
3-6 se cumple al utilizar nombres de variables que realizan funciones similares
4-1 escribe una sentencia por línea

Reglas claves con las que no se cumple:
1-2 no cumple ya que el .c se encuentra en la parte pública y no en la privada

Por lo tanto para que cumpla el programa con las reglas, solo se tendra que cambiar en las librerías el .c por el .h


Reglas de Programación del libro Elementos de Estilo en C

Capítulo 1: Estilo y Organización de Programas

Regla 1-1: Organiza los programas para legibilidad, al igual que esperarías que un autor organizaría un libro.

Regla 1-2: Divide cada módulo en un parte pública (lo que se requiere para usar el módulo) y una parte privada (lo que se requiere para hacer el trabajo). La parte pública va en un archivo .h mientras que la parte privada va en un archivo .c .

Regla 1-3: Usa espacios en blanco para separar una función en párrafos.

Regla 1-4: Coloca cada sentencia en su propia línea.

Regla 1-5: Evita sentencias muy largas. Usa en su lugar sentencias múltiples más cortas.


Capítulo 2: Fundamentos de Archivos, Comentarios, y Encabezados de Programas

Regla 2-1: Mantén los archivos de programas no mayores a 2,000 ó 3,000 líneas.

Regla 2-2: Mantén todas las líneas de tu programa debajo de 72 caracteres o menos.

Regla 2-3: Usa paradas de tabuladores de 8 caracteres.

Regla 2-4: Usa solamente los 95 caracteres ASCII estándar en tus programas. Evita caracteres exóticos. (Los caracteres extranjeros pueden ser usados si estás escribiendo comentarios en una lengua extranjera.)

Regla 2-5: Incluye un comentario de cabecera al comienzo de cada archivo que explique el archivo.

Regla 2-6: Deja fuera los comentarios innecesarios si ellos requieren mantenimiento y no estás dispuesto a dárselo.

Regla 2-7: Comenta tu código mientras lo escribes.


Capítulo 3: Nombres de Variables

Regla 3-1: Usa nombres de variable simples y descriptivos.

Regla 3-2: Los buenos nombres de variable se crean usando una palabra o juntando dos o tres palabras, separadas por "_" (guión bajo).

Regla 3-3: Nunca uses l (L minúscula) o O (O mayúscula) como nombres de variables o constantes.

Regla 3-4: No uses los nombres de funciones o de constantes de biblioteca existentes.

Regla 3-5: No uses nombres de variables que difieran por uno o dos caracteres. Haz cada nombre obviamente diferente de cada uno de los demás.

Regla 3-6: Usa nombres similares para variables que realizan funciones similares.

Regla 3-7: Cuando crees un nombre de variable de dos palabras donde las palabras puedan ser puestas en cualquier orden, siempre coloca de primero la más importante.

Regla 3-8: Los prefijos y sufijos estándar son _ptr, _p, _file, _fd, y n_.

Regla 3-9: Los nombres cortos tales como x, y, y i son aceptables cuando su significado es claro y cuando un nombre largo no añadiría información o claridad adicional.

Rule 3-10: Use argc para el número de argumentos de la línea de comandos y argv para la lista de argumentos. No uses esos nombres para nada más.

Regla 3-11: Sigue cada declaración de variable con un comentario que la defina.

Regla 3-12: Cuando sea posible, incluye las unidades de medida en la descripción de una variable.

Regla 3-13: Nombra y comenta cada campo de una estructura o unión igual que una variable.

Regla 3-14: Inicia cada definición de estructura o unión con un comentario multilínea describiéndola.

Regla 3-15: Coloca al menos una línea en blanco antes y después de la definición de una estructura o unión.

Regla 3-16: Cuando no puedas poner un comentario descriptivo al final de una declaración de variable, colócalo en una línea separada arriba de ella. Usa líneas en blanco para separar el par declaración/comentario del resto del código.

Regla 3-17: Agrupa variables similares juntas. Cuando sea posible, usa la misma estructura para cada grupo.

Regla 3-18: No uses variables escondidas.

Regla 3-19: Usa los nombres INT16, INT32, UINT16, y UINT32 para aplicaciones portables.

Regla 3-20: Los números de punto flotante deben tener al menos un dígito a ambos lados del punto decimal.

Regla 3-21: El exponente en un número de punto flotante debe ser una e minúscula. Esta es siempre seguida por un signo.

Regla 3-22: Empieza los números hexadecimales con Ox. (x minúscula solamente.)

Regla 3-23: Usa letras mayúsculas de la A a la F cuando construyas constantes hexadecimales.

Regla 3-24: Las constantes largas deberían terminar con una L mayúscula.


Capítulo 4: Formateo de Sentencias

Regla 4-1: Escribe una sentencia por línea.

Regla 4-2: Coloca espacios antes y después de cada operador aritmético, al igual que colocas espacios entre las palabras cuando escribes.

Regla 4-3: Cambia una sentencia larga y compleja por varias sentencias más pequeñas y más simples.

Regla 4-4: En una sentencia que consiste de dos o más líneas, cada línea excepto la primera debe indentarse un nivel extra para indicar que es una continuación de la primera.

Regla 4-5: Cuando escribas sentencias multilíneas, coloca los operadores aritméticos y lógicos al final de cada línea.

Regla 4-6: Cuando dividas una línea, el punto preferido de división es donde el anidamiento de los paréntesis sea menor.

Regla 4-7: Alinea verticalmente los niveles de paréntesis.

Regla 4-8: Divide las sentencias for largas en los límites de sus sentencias.

Regla 4-9: Siempre divide una sentencia for en tres líneas.

Regla 4-10: Escribe las sentencias switch en una línea independiente.

Regla 4-11: Mantén los condicionales en una única línea si es posible.

Regla 4-12: Cuando dividas una cláusula condicional (?:), escríbela en tres líneas: la línea de la condición, la línea del valor verdadero, y la línea del valor falso. Indenta la segunda y la tercera línea un nivel extra.

Regla 4-13: Evita los efectos colaterales.

Regla 4-14: Coloca los operadores ++ y -- en sus propias líneas. No uses ++ y -- dentro de otras sentencias.

Regla 4-15: Nunca coloques una sentencia de asignación dentro de otra sentencia.

Regla 4-16: Si el colocar dos o más sentencias en una misma línea mejora la claridad del programa, entonces hazlo así.

Regla 4-17: Cuando uses más de una sentencia por línea, organiza las sentencias en columnas.

Regla 4-18: Indenta un nivel para cada nuevo nivel de lógica.

Regla 4-19: El mejor tamaño de indentación es de cuatro espacios.


Capítulo 5: Detalles de Sentencias

Regla 5-1: Coloca siempre un comentario en la sentencia nula, aún si es la única.

Regla 5-2: En las expresiones en C, puedes asumir que *, /, y % vienen después de + y -. Coloca paréntesis alrededor de todo lo demás.

Regla 5-3: Usa declaraciones de funciones estilo ANSI siempre que sea posible.

Regla 5-4: Cuando uses parámetros tipo K&R (Kernighan&Ritchie), declara un tipo para cada parámetro.

Regla 5-5: Cuando uses parámetros tipo K&R (Kernighan&Ritchie), coloca la declaración de tipo de los parámetros en el mismo orden en que aparecen en la cabecera de la función.

Regla 5-6: Siempre declara un tipo para la función.

Regla 5-7: Siempre declara funciones que no retornan un valor como void.

Regla 5-8: No permitas más de 5 parámetros para una función.

Regla 5-9: Evita usar variables globales cuando los parámetros de la función pueden bastar.

Regla 5-10: Evita las listas de parámetros de longitud variable. Son difíciles de programar y fácilmente pueden causar problemas.

Regla 5-11: Cuando un if afecta a más de una línea, enciérralas entre llaves.

Regla 5-12: En una cadena de if, trata las palabras else if como una única palabra clave.

Regla 5-13: Nunca uses el operador coma cuando en su lugar puedas usar llaves.

Regla 5-14: Cuando crees ciclos infinitos, usa while (1) en lugar de for(;;).

Regla 5-15: Evita usar do/while. Usa en su lugar while y break.

Regla 5-16: Usa el operador coma dentro de una sentencia for solamente para poner juntas dos sentencias. Nunca lo uses para combinar tres sentencias.

Regla 5-17: Usa un printf por línea de salida.

Regla 5-18: A menos que se garantice la extrema eficiencia, usa printf en lugar de puts y putc.

Regla 5-19: Empieza las etiquetas goto en la primer columna.

Regla 5-20: Termina cada case en un switch con un break o el comentario /* El flujo continúa en el siguiente case */.

Regla 5-21: Siempre coloca un break al final del último case en una sentencia switch.

Regla 5-22: Siempre incluye un caso default en cada switch, aún cuando no contenga más que la sentencia nula.


Capítulo 6: Preprocesador

Regla 6-1: Las constantes #define se declaran como variables. Siempre coloca un comentario que describa a la constante después de cada declaración.

Regla 6-2: Los nombres de constantes son todos en mayúsculas.

Regla 6-3: Si el valor de una constante es algo más que un simple número, enciérralo entre paréntesis.

Regla 6-4: El uso de const se prefiere sobre #define para especificar constantes.

Regla 6-5: Cuando sea posible, usa typedef en lugar de #define.

Regla 6-6: No uses #define para definir nuevos elementos de lenguaje.

Regla 6-7: Nunca uses #define para redefinir palabras claves o funciones estándar de C.

Regla 6-8: Encierra las macros parametrizadas entre paréntesis.

Regla 6-9: Encierra cada argumento para una macro parametrizada entre paréntesis.

Regla 6-10: Siempre encierra las macros que definen múltiple sentencias de C entre llaves.

Regla 6-11: Si una macro contiene más de una sentencia, usa una estructura do/while para encerrar la macro. (No olvides dejar el punto y coma de la sentencia).

Regla 6-12: Cuando crees macros multilíneas, alinea los caracteres de continuación diagonal inversa (\) en una columna.

Regla 6-13: Comenta siempre cualquier macro parametrizada que se vea como una función.

Regla 6-14: Las directivas #include vienen justo después de los comentario de encabezado. Coloca primero las inclusiones del sistema, seguidas de las inclusiones locales.

Regla 6-15: No uses rutas absolutas en las directivas #include. Deja que la opción -I haga el trabajo.

Regla 6-16: Comenta las directivas #else y #endif con el símbolo usado en el #ifdef inicial o la directiva #endif.

Regla 6-17: Usa prudentemente la compilación condicional. No permitas que los condicionales oscurezcan el código.

Regla 6-18: Define (o no definas) el control de compilación de símbolo condicional en el código en lugar de usar la opción -D para el compilador.

Regla 6-19: Coloca las sentencias #define y #undef para control de compilación de símbolos al comienzo del programa.

Regla 6-20: No comentes código no utilizado. Usa la compilación condicional (#ifdef #undef) para deshacerte del código no deseado.

Regla 6-21: Usa #ifdef QQQ para eliminar código temporalmente durante la depuración.


Capítulo 7: Estilo de Organización de Directorio y Makefile

Regla 7-1: Siempre que sea posible, coloca todos los archivos para un programa o biblioteca en un mismo directorio.


Capítulo 8: Programación Amistosa con el Usuario

Regla 8-1: Ley de la Menor Sorpresa: El programa debería actuar de la manera que menos sorprenda al usuario.

Regla 8-2: Empieza cada mensaje de error con el rótulo Error:. Inicia cada mensaje de advertencia con Advertencia:.

Mi Lenguaje

* jive [libro.c]
* jive [estudio.c]

ent a,b,c.

inicio()
{
imp//”Dame valor A”.
alm%a.
Iip//Dame valor B”.
alm%b.
c=a+b.
imp//c.
}

Reglas claves con las que se cumple:
3-6 se cumple al utilizar nombres de variables que realizan funciones similares
4-1 escribe una sentencia por línea

Reglas claves con las que no se cumple:
1-2 no cumple ya que el .c se encuentra en la parte pública y no en la privada

Por lo tanto para que cumpla el programa con las reglas, solo se tendra que cambiar en las librerías el .c por el .h


Reglas de Programación del libro Elementos de Estilo en C

Capítulo 1: Estilo y Organización de Programas

Regla 1-1: Organiza los programas para legibilidad, al igual que esperarías que un autor organizaría un libro.

Regla 1-2: Divide cada módulo en un parte pública (lo que se requiere para usar el módulo) y una parte privada (lo que se requiere para hacer el trabajo). La parte pública va en un archivo .h mientras que la parte privada va en un archivo .c .

Regla 1-3: Usa espacios en blanco para separar una función en párrafos.

Regla 1-4: Coloca cada sentencia en su propia línea.

Regla 1-5: Evita sentencias muy largas. Usa en su lugar sentencias múltiples más cortas.


Capítulo 2: Fundamentos de Archivos, Comentarios, y Encabezados de Programas

Regla 2-1: Mantén los archivos de programas no mayores a 2,000 ó 3,000 líneas.

Regla 2-2: Mantén todas las líneas de tu programa debajo de 72 caracteres o menos.

Regla 2-3: Usa paradas de tabuladores de 8 caracteres.

Regla 2-4: Usa solamente los 95 caracteres ASCII estándar en tus programas. Evita caracteres exóticos. (Los caracteres extranjeros pueden ser usados si estás escribiendo comentarios en una lengua extranjera.)

Regla 2-5: Incluye un comentario de cabecera al comienzo de cada archivo que explique el archivo.

Regla 2-6: Deja fuera los comentarios innecesarios si ellos requieren mantenimiento y no estás dispuesto a dárselo.

Regla 2-7: Comenta tu código mientras lo escribes.


Capítulo 3: Nombres de Variables

Regla 3-1: Usa nombres de variable simples y descriptivos.

Regla 3-2: Los buenos nombres de variable se crean usando una palabra o juntando dos o tres palabras, separadas por "_" (guión bajo).

Regla 3-3: Nunca uses l (L minúscula) o O (O mayúscula) como nombres de variables o constantes.

Regla 3-4: No uses los nombres de funciones o de constantes de biblioteca existentes.

Regla 3-5: No uses nombres de variables que difieran por uno o dos caracteres. Haz cada nombre obviamente diferente de cada uno de los demás.

Regla 3-6: Usa nombres similares para variables que realizan funciones similares.

Regla 3-7: Cuando crees un nombre de variable de dos palabras donde las palabras puedan ser puestas en cualquier orden, siempre coloca de primero la más importante.

Regla 3-8: Los prefijos y sufijos estándar son _ptr, _p, _file, _fd, y n_.

Regla 3-9: Los nombres cortos tales como x, y, y i son aceptables cuando su significado es claro y cuando un nombre largo no añadiría información o claridad adicional.

Rule 3-10: Use argc para el número de argumentos de la línea de comandos y argv para la lista de argumentos. No uses esos nombres para nada más.

Regla 3-11: Sigue cada declaración de variable con un comentario que la defina.

Regla 3-12: Cuando sea posible, incluye las unidades de medida en la descripción de una variable.

Regla 3-13: Nombra y comenta cada campo de una estructura o unión igual que una variable.

Regla 3-14: Inicia cada definición de estructura o unión con un comentario multilínea describiéndola.

Regla 3-15: Coloca al menos una línea en blanco antes y después de la definición de una estructura o unión.

Regla 3-16: Cuando no puedas poner un comentario descriptivo al final de una declaración de variable, colócalo en una línea separada arriba de ella. Usa líneas en blanco para separar el par declaración/comentario del resto del código.

Regla 3-17: Agrupa variables similares juntas. Cuando sea posible, usa la misma estructura para cada grupo.

Regla 3-18: No uses variables escondidas.

Regla 3-19: Usa los nombres INT16, INT32, UINT16, y UINT32 para aplicaciones portables.

Regla 3-20: Los números de punto flotante deben tener al menos un dígito a ambos lados del punto decimal.

Regla 3-21: El exponente en un número de punto flotante debe ser una e minúscula. Esta es siempre seguida por un signo.

Regla 3-22: Empieza los números hexadecimales con Ox. (x minúscula solamente.)

Regla 3-23: Usa letras mayúsculas de la A a la F cuando construyas constantes hexadecimales.

Regla 3-24: Las constantes largas deberían terminar con una L mayúscula.


Capítulo 4: Formateo de Sentencias

Regla 4-1: Escribe una sentencia por línea.

Regla 4-2: Coloca espacios antes y después de cada operador aritmético, al igual que colocas espacios entre las palabras cuando escribes.

Regla 4-3: Cambia una sentencia larga y compleja por varias sentencias más pequeñas y más simples.

Regla 4-4: En una sentencia que consiste de dos o más líneas, cada línea excepto la primera debe indentarse un nivel extra para indicar que es una continuación de la primera.

Regla 4-5: Cuando escribas sentencias multilíneas, coloca los operadores aritméticos y lógicos al final de cada línea.

Regla 4-6: Cuando dividas una línea, el punto preferido de división es donde el anidamiento de los paréntesis sea menor.

Regla 4-7: Alinea verticalmente los niveles de paréntesis.

Regla 4-8: Divide las sentencias for largas en los límites de sus sentencias.

Regla 4-9: Siempre divide una sentencia for en tres líneas.

Regla 4-10: Escribe las sentencias switch en una línea independiente.

Regla 4-11: Mantén los condicionales en una única línea si es posible.

Regla 4-12: Cuando dividas una cláusula condicional (?:), escríbela en tres líneas: la línea de la condición, la línea del valor verdadero, y la línea del valor falso. Indenta la segunda y la tercera línea un nivel extra.

Regla 4-13: Evita los efectos colaterales.

Regla 4-14: Coloca los operadores ++ y -- en sus propias líneas. No uses ++ y -- dentro de otras sentencias.

Regla 4-15: Nunca coloques una sentencia de asignación dentro de otra sentencia.

Regla 4-16: Si el colocar dos o más sentencias en una misma línea mejora la claridad del programa, entonces hazlo así.

Regla 4-17: Cuando uses más de una sentencia por línea, organiza las sentencias en columnas.

Regla 4-18: Indenta un nivel para cada nuevo nivel de lógica.

Regla 4-19: El mejor tamaño de indentación es de cuatro espacios.


Capítulo 5: Detalles de Sentencias

Regla 5-1: Coloca siempre un comentario en la sentencia nula, aún si es la única.

Regla 5-2: En las expresiones en C, puedes asumir que *, /, y % vienen después de + y -. Coloca paréntesis alrededor de todo lo demás.

Regla 5-3: Usa declaraciones de funciones estilo ANSI siempre que sea posible.

Regla 5-4: Cuando uses parámetros tipo K&R (Kernighan&Ritchie), declara un tipo para cada parámetro.

Regla 5-5: Cuando uses parámetros tipo K&R (Kernighan&Ritchie), coloca la declaración de tipo de los parámetros en el mismo orden en que aparecen en la cabecera de la función.

Regla 5-6: Siempre declara un tipo para la función.

Regla 5-7: Siempre declara funciones que no retornan un valor como void.

Regla 5-8: No permitas más de 5 parámetros para una función.

Regla 5-9: Evita usar variables globales cuando los parámetros de la función pueden bastar.

Regla 5-10: Evita las listas de parámetros de longitud variable. Son difíciles de programar y fácilmente pueden causar problemas.

Regla 5-11: Cuando un if afecta a más de una línea, enciérralas entre llaves.

Regla 5-12: En una cadena de if, trata las palabras else if como una única palabra clave.

Regla 5-13: Nunca uses el operador coma cuando en su lugar puedas usar llaves.

Regla 5-14: Cuando crees ciclos infinitos, usa while (1) en lugar de for(;;).

Regla 5-15: Evita usar do/while. Usa en su lugar while y break.

Regla 5-16: Usa el operador coma dentro de una sentencia for solamente para poner juntas dos sentencias. Nunca lo uses para combinar tres sentencias.

Regla 5-17: Usa un printf por línea de salida.

Regla 5-18: A menos que se garantice la extrema eficiencia, usa printf en lugar de puts y putc.

Regla 5-19: Empieza las etiquetas goto en la primer columna.

Regla 5-20: Termina cada case en un switch con un break o el comentario /* El flujo continúa en el siguiente case */.

Regla 5-21: Siempre coloca un break al final del último case en una sentencia switch.

Regla 5-22: Siempre incluye un caso default en cada switch, aún cuando no contenga más que la sentencia nula.


Capítulo 6: Preprocesador

Regla 6-1: Las constantes #define se declaran como variables. Siempre coloca un comentario que describa a la constante después de cada declaración.

Regla 6-2: Los nombres de constantes son todos en mayúsculas.

Regla 6-3: Si el valor de una constante es algo más que un simple número, enciérralo entre paréntesis.

Regla 6-4: El uso de const se prefiere sobre #define para especificar constantes.

Regla 6-5: Cuando sea posible, usa typedef en lugar de #define.

Regla 6-6: No uses #define para definir nuevos elementos de lenguaje.

Regla 6-7: Nunca uses #define para redefinir palabras claves o funciones estándar de C.

Regla 6-8: Encierra las macros parametrizadas entre paréntesis.

Regla 6-9: Encierra cada argumento para una macro parametrizada entre paréntesis.

Regla 6-10: Siempre encierra las macros que definen múltiple sentencias de C entre llaves.

Regla 6-11: Si una macro contiene más de una sentencia, usa una estructura do/while para encerrar la macro. (No olvides dejar el punto y coma de la sentencia).

Regla 6-12: Cuando crees macros multilíneas, alinea los caracteres de continuación diagonal inversa (\) en una columna.

Regla 6-13: Comenta siempre cualquier macro parametrizada que se vea como una función.

Regla 6-14: Las directivas #include vienen justo después de los comentario de encabezado. Coloca primero las inclusiones del sistema, seguidas de las inclusiones locales.

Regla 6-15: No uses rutas absolutas en las directivas #include. Deja que la opción -I haga el trabajo.

Regla 6-16: Comenta las directivas #else y #endif con el símbolo usado en el #ifdef inicial o la directiva #endif.

Regla 6-17: Usa prudentemente la compilación condicional. No permitas que los condicionales oscurezcan el código.

Regla 6-18: Define (o no definas) el control de compilación de símbolo condicional en el código en lugar de usar la opción -D para el compilador.

Regla 6-19: Coloca las sentencias #define y #undef para control de compilación de símbolos al comienzo del programa.

Regla 6-20: No comentes código no utilizado. Usa la compilación condicional (#ifdef #undef) para deshacerte del código no deseado.

Regla 6-21: Usa #ifdef QQQ para eliminar código temporalmente durante la depuración.


Capítulo 7: Estilo de Organización de Directorio y Makefile

Regla 7-1: Siempre que sea posible, coloca todos los archivos para un programa o biblioteca en un mismo directorio.


Capítulo 8: Programación Amistosa con el Usuario

Regla 8-1: Ley de la Menor Sorpresa: El programa debería actuar de la manera que menos sorprenda al usuario.

Regla 8-2: Empieza cada mensaje de error con el rótulo Error:. Inicia cada mensaje de advertencia con Advertencia:.