Los estándares de codificación pueden ahorrarle mucho tiempo y esfuerzo, y mucha menos frustración por perseguir problemas triviales.
Los estándares de codificación pueden ahorrarle mucho tiempo y esfuerzo, y mucha menos frustración por perseguir problemas triviales.
Un amigo de Barr Group me acaba de decir que un estándar de codificación que elimina errores en el lenguaje de programación C ahora está disponible gratuitamente en formato HTML o PDF.puede Accede a ambos formatos aquí.
Ahora tengo que admitir que no soy un programador profesional. Soy ingeniero de diseño de hardware de profesión, pero como la mayoría de los ingenieros, me aventuro en el mundo de la programación de vez en cuando.
No hace falta decir que si eres parte de un equipo grande, tiene sentido que todos usen estándares comunes. Incluso si a usted personalmente no le gusta parte de ese estándar, debe aceptar que usarlo hace que el código de los demás sea mucho más fácil de entender y mantener.
Por supuesto, existe el viejo dicho: “Los estándares son geniales. ¡Todo el mundo debería tenerlos!” El problema es que todo el mundo tiende a tenerlo en la práctica. Incluso si trabaja como contratista independiente, si está escribiendo un código de misión crítica o de seguridad crítica, está obligado a seguir ciertas prácticas de codificación.
Solo los programadores aficionados son 100 % libres de seguir a Muse. Dicho esto, apegarse a los estándares puede ayudarlo a hacer su vida más fácil a largo plazo.
De hecho, leí el estándar de Barr Group hace algún tiempo y obtuve muchos consejos, sugerencias y trucos útiles y lo incorporé a mi “estándar Max”.
La razón por la que me estoy rascando la cabeza con todo esto aquí es porque con solo mirar el código escrito por uno de los jóvenes pasantes de la planta baja en la bahía se me llenaron los ojos de lágrimas (estamos hablando, basta con decir que no lo es). lagrimas de alegria). Por lo tanto, decidí compartir algunas de las convenciones de codificación que sigo actualmente de la siguiente manera.
#define
Utilice siempre caracteres alfanuméricos en mayúsculas y guiones bajos para los nombres constantes. Por ejemplo:
#define START_COUNT 0 #define END_COUNT 100
Racional: esto facilita la identificación de constantes globales en el cuerpo de su programa.
Nombre de la variable
En general, use mayúsculas y minúsculas para nombres de variables. Esto significa que las palabras o frases compuestas se escriben de tal manera que cada palabra en el medio de la frase se escribe en mayúscula sin espacios intermedios ni puntuación. Por ejemplo:
int mainLoopCounter = START_COUNT; bool doneCounting = false;
Racional: me gusta el aspecto del estuche camel y transmite mucha información en un formato fácil de leer.
Nota: yo caja de camello inferior La primera letra (‘m’ en mainLoopCounter y ‘d’ en doneCounting arriba) está en minúsculas. Algunas personas prefieren usar el caso Upper Camel (también conocido como caso Pascal) con la primera letra en mayúscula.
variable global
Siempre prefijo las variables globales con una ‘g’, una o más letras adicionales para indicar el tipo y un guión bajo. Por ejemplo, “gi_” (entero global) y “gb_” (booleano global) como se muestra a continuación.
int gi_mainLoopCounter = START_COUNT; bool gb_doneCounting = false;
Racional: no me gusta especialmente este aspecto, pero la parte “g_” facilita saber si estás usando una variable local o una variable global. La letra adicional ayuda a garantizar que esté asignando el tipo adecuado a la variable de interés.
nombre de la función
Si tiene una función que activa una secuencia de autodestrucción, es una práctica común anteponer la función con la palabra “hacer” y usar mayúsculas y minúsculas para el resto del nombre. Por ejemplo:
void doActivateDestructSequence ()
{
// Statements go here
}En comparación, si tiene una función cuya tarea principal es realizar alguna prueba y devolver algún estado o valor, generalmente le agrega el prefijo apropiado como “hecho” y usa mayúsculas y minúsculas para el resto del nombre Para hacer. Por ejemplo:
bool doneCountingDown ()
{
// Statements go here
}Racional: Para mí, esto hace que el cuerpo del código sea mucho más fácil de leer y entender lo que está pasando.
Nota: observe el espacio entre el nombre de la función y los corchetes “()” en los dos ejemplos anteriores. En comparación, cuando llama a una función en el cuerpo de su programa, no incluye este espacio. Por ejemplo:
gb_doneCounting = doneCountingDown();
if (gb_doneCounting)
{
doActivateDestructSequence();
}Racional: esto facilita encontrar el código para la instancia en la que se llamó a la función (sin espacios) y la función en sí (con espacios).
{ } Uso de
Algunas personas colocan la apertura ‘{‘ inmediatamente después del paréntesis cuando declaran una función. Por ejemplo:
void doActivateDestructSequence () {
// Statements go here
}En comparación, prefiero poner la apertura ‘{‘ en su propia línea justo encima del ‘}’ correspondiente como vimos en el tema “Nombres de función” anterior. Por ejemplo:
void doActivateDestructSequence ()
{
// Statements go here
}Siga el mismo método para las sentencias condicionales. Por ejemplo:
if (gb_doneCounting)
{
doActivateDestructSequence();
}Racional: con declaraciones anidadas, rápidamente puede volverse difícil determinar qué ‘{‘ va con qué ‘}’. Colocar la apertura ‘{‘ en la línea justo encima del ‘}’ correspondiente hace que sea mucho más fácil entender lo que está pasando. .
Además, para declaraciones condicionales que tienen solo una declaración de acción asociada, tendemos a omitir ‘{‘ y ‘}’ juntos. Por ejemplo:
if (gb_doneCounting) doActivateDestructSequence();
or
if (gb_doneCounting)
doActivateDestructSequence();En comparación, como puede ver en los ejemplos anteriores (y según la lectura del estándar de Barr Group), siempre usan ‘{‘ y ‘}’ incluso cuando solo hay una declaración de acción. Por ejemplo:
if (gb_doneCounting)
{
doActivateDestructSequence();
}
Racional: desde el principio, esto hace que su código sea más fácil de leer. Además, al depurar código, a menudo quiero agregar declaraciones adicionales. Tener el ‘{‘ y ‘}’ ya en su lugar hace que este proceso sea mucho más fácil.
sangría
Como muchos programadores de C, usé dos espacios para la sangría. Por ejemplo:
void doStopButton (int whatState)
{
if (whatState == BUTTON_PULSE_OFF)
{
doUpdateColor(g_idStopOutline, ST_LINE_OFF);
doUpdateColor(g_idStopBox, ST_BOX_OFF);
doUpdateColor(g_idStopText, ST_TEXT_OFF);
}
else if (whatState == BUTTON_PULSE_ON)
{
doUpdateColor(g_idStopOutline, ST_LINE_ON);
doUpdateColor(g_idStopBox, ST_BOX_ON);
doUpdateColor(g_idStopText, ST_TEXT_ON);
}
else
{
}
}
Pero ahora se basa tanto en mi lectura del estándar de Barr Group como en mi experiencia con Python (consulte la reseña de mi libro). Aprende a programar con Minecraft por Craig Richardson), prefiero sangrar usando 4 espacios. Por ejemplo:
void doStopButton (int whatState)
{
if (whatState == BUTTON_PULSE_OFF)
{
doUpdateColor(g_idStopOutline, ST_LINE_OFF);
doUpdateColor(g_idStopBox, ST_BOX_OFF);
doUpdateColor(g_idStopText, ST_TEXT_OFF);
}
else if (whatState == BUTTON_PULSE_ON)
{
doUpdateColor(g_idStopOutline, ST_LINE_ON);
doUpdateColor(g_idStopBox, ST_BOX_ON);
doUpdateColor(g_idStopText, ST_TEXT_ON);
}
else
{
}
}
Razonable: el uso de sangría de 4 espacios hace que su código sea más fácil de leer y comprender, tanto para el autor como para cualquier persona en el futuro que deba descubrir qué significa en algún momento.
tú
Las anteriores son solo algunas de las prácticas de codificación que sigo actualmente, pero debo decir que usarlas me ahorra mucho tiempo y esfuerzo, y mucha menos frustración al rastrear problemas triviales. No tomamos atajos.
y tú ¿Está de acuerdo o en desacuerdo con las técnicas presentadas aquí y tiene sus propios consejos y trucos que le gustaría compartir?