Resumen Capitulo - 5 - y - 6

5 Reglas de tipo de datos
Los nuevos tipos de datos, incluidas las estructuras, las uniones y las enumeraciones de la
fórmula 1 , consistirán solo en caracteres en minúscula y guiones bajos internos, y terminarán
con ‘_t’. Las nuevas estructuras, uniones y enumeraciones se nombrarán mediante un typedef.
C. Tambien el timer_reg_shadow puede usarse para crear una copia oculta de los registros del
temporizador.
Siempre que el ancho, en bits o bytes, de un valor entero sea importante en el programa, se
utilizará uno de los tipos de datos de ancho fijo como 8, 16, 32 bits. Cuando sea números
enteros con signos se deberá poner uint8_t y cuando sea sin signo int8_t . Los campos de bits,
en particular, sufren graves problemas de portabilidad, incluida la falta de un pedido de bits
estándar y no hay soporte oficial para los tipos de enteros de ancho fijo con los que a menudo
llaman para ser utilizados.
En la fórmula 2 es necesario saber lasreglas para poder ejecutar algunas acciones :
No se utilizarán las palabras clave short y long.
El uso de la palabra clave char se limitará a la declaración y las operaciones relacionadas con
las cadenas. Además, los resultados de mezclar enteros con y sin signo pueden conducir a
resultados dependientes de datos como el del código anterior.
Formula 3 Evite el uso de constantes y variables de coma flotante siempre que sea posible. Las
matemáticas de punto fijo pueden ser una alternativa. Para poder operar el punto flotante
necesitamos unas condiciones las cuales son :
Utilice los nombres de tipo C99 float32_t, float64_t y float128_t. ii) Agregue una "f" a todas las
constantes de precisión simple (por ejemplo, pi = 3.141592f).
Asegúrese de que el compilador admite doble precisión, si su matemática depende de ello.
Nunca pruebe la igualdad o desigualdad de los valores de coma flotante.
Siempre invoque la macro isfinite () para verificar que los cálculos anteriores no hayan dado
como resultado INFINITY ni NAN.
En la fórmula 4 necesitaremos una serie de reglas booleanas las cuales son: Las variables
booleanas se declararán como tipo bool. si. Los valores no booleanos se convertirán a
booleanos mediante el uso de operadores relacionales (por ejemplo, <o! =), No a través de
conversiones. Los programadores de C han tratado ampliamente cualquier valor entero distinto
de cero como verdadero.
Formula 1
typedef struct
{ uint16_t count;
uint16_t max_count;
uint16_t _unused;
uint16_t control;
} timer_reg_t;
Formula 2
uint16_t unsigned_a = 6u;
int16_t signed_b = -9;
if (unsigned_a + signed_b < 4)
{ // Execution of this block appears reliably logical, as -9 + 6 is -3
...
} // ...
but compilers with 16-bit int may legally perform (0xFFFF – 9) + 6.
Formula 3
#include <límites.h>
#if (DBL_DIG <10) // Asegúrese de que el compilador admite doble precisión.
# error "¡La precisión doble no está disponible!"
#terminara si
Fórmula 4
#include <stdbool.h>
...

bool b_in_motion = (0! = velocidad_en_mph);
6 Reglas de procedimiento
6.1 Convenciones de nombres
Reglas:
Ningún procedimiento tendrá un nombre que sea una palabra clave de ningún estándar
versión del lenguaje de programación C o C ++. Nombres restringidos incluye interrupción, en
línea, clase, verdadero, falso, público, privado, amigo, protegido y muchos otros.
Ningún procedimiento tendrá un nombre que se superponga a una función en el C Biblioteca

estándar Ejemplos de tales nombres incluyen strlen, atoi, y memset.
Ningún procedimiento tendrá un nombre que comience con un guión bajo.
Ningún nombre de procedimiento tendrá más de 31 caracteres.
Ningún nombre de función deberá contener letras mayúsculas.
Ningún nombre de macro contendrá letras minúsculas.
Los guiones bajos se utilizarán para separar palabras en los nombres de procedimientos.
El nombre de cada procedimiento debe ser descriptivo de su propósito. Tenga en cuenta que
los procedimientos encapsulan las "acciones" de un programa y, por lo tanto, se benefician de
uso de verbos en sus nombres (por ejemplo, adc_read ()); esta palabra "sustantivo-verbo" Se
recomienda ordenar. Alternativamente, los procedimientos pueden ser nombrados de acuerdo
con la pregunta que responden (por ejemplo, led_is_on ()).
Los nombres de todas las funciones públicas irán precedidos de su nombre de módulo. Y un
guión bajo (p. ej., sensor_read ()).
Razonamiento: los buenos nombres de funciones facilitan la revisión y el mantenimiento del

código (y, por lo tanto, más barato). Los datos (variables) en los programas son sustantivos. Las
funciones manipulan datos y, por lo tanto, son verbos.
El uso de prefijos de módulos está en consonancia con el objetivo importante de la

encapsulación y ayuda a evitar la superposición de nombres de procedimientos.
Cumplimiento: El cumplimiento de estas reglas de nomenclatura se establecerá en la fase de
diseño detallado y se aplicará durante las revisiones del código.
6.2 Funciones
Reglas:
a) Se realizarán todos los esfuerzos razonables para mantener limitada la duración de cada
función a una página impresa, o un máximo de 100 líneas.
b) Siempre que sea posible, todas las funciones deben comenzar en la parte superior de una
página impresa, excepto cuando varias funciones pequeñas pueden caber en una sola página.
c) Es una práctica preferida que todas las funciones tengan un solo punto de salida y sea a
través de un retorno en la parte inferior de la función.
d) Se declarará un prototipo para cada función pública en el archivo de encabezado del módulo.
e) Todas las funciones privadas se declararán estáticas.
f) Cada parámetro se declarará explícitamente y se nombrará de manera significativa.
Razonamiento: las revisiones de código se realizan a nivel de función y, a menudo, en papel.

Por lo tanto, cada función debería ser idealmente visible en una sola página impresa, de modo
que voltear documentos de un lado a otro no distraiga a los revisores.
Las declaraciones de retorno múltiples solo deben usarse cuando mejora la legibilidad del
código.
Cumplimiento: El cumplimiento de estas reglas se verificará durante las revisiones de código.
6.3 Macros con funciones similares
Reglas:
a) Las macros parametrizadas no se utilizarán si se puede escribir una función para lograr el
mismo comportamiento.
b) Si se usan macros parametrizadas por alguna razón, se aplican estas reglas:
1. Rodee todo el cuerpo macro con paréntesis.

2. Encierre cada uso de un parámetro entre paréntesis.
3. Use cada parámetro no más de una vez para evitar efectos secundarios.
4. Nunca incluya una transferencia de control (por ejemplo, palabra clave de retorno).
Razonamiento: Existen muchos riesgos asociados con el uso de definiciones de preprocesador,

y muchos de ellos se relacionan con la creación de macros parametrizadas. El uso extensivo de
paréntesis (como se muestra en el ejemplo) es importante, pero no elimina la posibilidad de
doble incremento no intencionado de una llamada como MAX (i ++, j ++).
Otros riesgos del mal uso macro incluyen la comparación de datos firmados y no firmados o
cualquier prueba de datos de punto flotante.
Para empeorar las cosas, las macros son invisibles en tiempo de ejecución y, por lo tanto,
imposibles de ingresar en el depurador.
Cuando el rendimiento es importante, tenga en cuenta que C99 agregó la palabra clave en línea
de C ++.
Cumplimiento: estas reglas se aplicarán durante las revisiones de código.
6.4 Subprocesos de ejecución
Reglas:
a) Todas las funciones que encapsulan subprocesos de ejecución (a.k.a., tareas, procesos)
recibirán nombres que terminen en "_thread" (o "_task", "_process").
Razonamiento: cada tarea en un sistema operativo en tiempo real (RTOS) es como un mini-
main (), que generalmente se ejecuta para siempre en un bucle infinito. Es valioso identificar
fácilmente estas funciones importantes y asíncronas durante las revisiones de código y las
sesiones de depuración.
Cumplimiento: esta regla se seguirá durante la fase de diseño detallado y se aplicará durante
las revisiones de código.
6.5 Rutinas de servicio de interrupción
Reglas:
a) Las rutinas de servicio de interrupción (ISR) no son funciones ordinarias. El compilador debe
ser informado de que la función es un ISR por medio de #pragma o palabra clave específica del
compilador, como "__interrupt".
b) Todas las funciones que implementan ISR deberán recibir nombres que terminen en "_isr".
c) Para garantizar que los ISR no se llamen inadvertidamente desde otras partes del software
(pueden dañar la CPU y la pila de llamadas si esto sucede), cada función ISR se declarará
estática y / o se ubicará al final del módulo de controlador asociado según lo permitido por la
plataforma de destino.
d) Se debe instalar un trozo o ISR predeterminado en la tabla de vectores en la ubicación de

todas las fuentes de interrupción inesperadas o no manejadas. Cada tal trozo podría intentar
deshabilitar futuras interrupciones del mismo tipo, digamos en el controlador de
interrupciones, y afirmar ().

Resumen Capitulo - 5 - y - 6

Cargado por

Copyright:

Formatos disponibles

Resumen Capitulo - 5 - y - 6

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

Resumen Capitulo - 5 - y - 6

Cargado por

Copyright:

Formatos disponibles

5 Reglas de tipo de datos

En la fórmula 2 es necesario saber lasreglas para poder ejecutar algunas acciones :

No se utilizarán las palabras clave short y long.

uint16_t unsigned_a = 6u;

int16_t signed_b = -9;

if (unsigned_a + signed_b < 4)

{ // Execution of this block appears reliably logical, as -9 + 6 is -3

but compilers with 16-bit int may legally perform (0xFFFF – 9) + 6.

#if (DBL_DIG <10) // Asegúrese de que el compilador admite doble precisión.

# error "¡La precisión doble no está disponible!"

bool b_in_motion = (0! = velocidad_en_mph);

Ningún procedimiento tendrá un nombre que se superponga a una función en el C Biblioteca

Ningún procedimiento tendrá un nombre que comience con un guión bajo.

Ningún nombre de procedimiento tendrá más de 31 caracteres.

Ningún nombre de función deberá contener letras mayúsculas.

Ningún nombre de macro contendrá letras minúsculas.

Razonamiento: los buenos nombres de funciones facilitan la revisión y el mantenimiento del

El uso de prefijos de módulos está en consonancia con el objetivo importante de la

e) Todas las funciones privadas se declararán estáticas.

f) Cada parámetro se declarará explícitamente y se nombrará de manera significativa.

Razonamiento: las revisiones de código se realizan a nivel de función y, a menudo, en papel.

Cumplimiento: El cumplimiento de estas reglas se verificará durante las revisiones de código.

6.3 Macros con funciones similares

b) Si se usan macros parametrizadas por alguna razón, se aplican estas reglas:

1. Rodee todo el cuerpo macro con paréntesis.

Razonamiento: Existen muchos riesgos asociados con el uso de definiciones de preprocesador,

Cumplimiento: estas reglas se aplicarán durante las revisiones de código.

6.4 Subprocesos de ejecución

d) Se debe instalar un trozo o ISR predeterminado en la tabla de vectores en la ubicación de

También podría gustarte