Puede preguntarte qué se entiende por el título. El código es código, correcto? Es importante estar libre de errores y eso es eso, qué más? El desarrollo es más que escribir código y probarlo. Imagina que tienes que leer el trabajo de otra persona, y supongo que ya has hecho eso, y todas las variables se llaman Foo, Bar, Baz, Var, etc. Y el código no se comenta ni se documenta. Probablemente sentirás la repentina necesidad de invocar dioses desconocidos, luego ir al pub local y ahogar tus penas. Dicen que no debe hacer a los demás lo que no desea que le haga, por lo que esta parte se centrará en las pautas de codificación general, además de ideas específicas de GNU que lo ayudarán a que se acepte su código. Se supone que debe haber leído y entendido las partes anteriores de esta serie, así como resolver todos los ejercicios y, preferiblemente, leer y haber escrito el mayor código posible.

Recomendaciones

Antes de comenzar, tome nota del significado real de la palabra anterior. De ninguna manera, no quiero decirle cómo escribir su código, ni estoy inventando estas recomendaciones. Estos son el resultado de años de trabajo de programadores experimentados, y muchos no solo se aplicarán a C, sino a otros idiomas, interpretados o compilados.

Supongo que la primera regla que quiero estresar es: comentar su código, luego verifique si comentó lo suficiente y luego comenta un poco más. Esto no es beneficioso para otros que leerán/usarán su código, sino también para usted. Convencer que no recordará qué quiso escribir exactamente después de dos o tres meses, ni sabrá qué int ghrqa34; se suponía que significaba, si algo. Los buenos desarrolladores comentan (casi) cada línea de su código lo más a fondo posible, y la recompensa es más de lo que podría darse cuenta al principio, a pesar del mayor tiempo que lleva escribir el programa. Otra ventaja es que al comentar, porque así es como funciona nuestro cerebro, lo que deseamos hacer será mejor recordado, por lo que nuevamente no verá su código, avanzando unos meses, preguntándose quién escribió su código. O por qué.

Al analizador C no le importa cómo se ordene su código. Eso significa que puede escribir un programa típico de "hola, mundo" como este, y aún así compilaría:

#include int main () printf ("Hola, mundo!"); return 0; 

Parece mucho más legible como lo escribimos la primera vez, ¿no?? Las reglas generales con respecto al formato son: una instrucción por línea, elija el ancho de su pestaña y sea consistente con ella, pero asegúrese de que cumpla con las pautas del proyecto, si está trabajando en una, también hace un uso liberal de líneas en blanco, para Delimitar varias partes del programa, junto con los comentarios, y finalmente, aunque esto no está necesariamente codificando el estilo, antes de comenzar a codificar seriamente, encuentre un editor que le guste y aprenda a usarlo bien. Pronto publicaremos un artículo sobre editores, pero hasta entonces Google lo ayudará con algunas alternativas. Si escucha personas en foros, listas de correo, etc. diciendo "Editor X apesta, editor y FTW!", ingnóralos. Este es un asunto muy subjetivo y lo que es bueno para mí podría no ser tan bueno para usted, así que al menos pruebe algunos de los editores disponibles para Linux durante unos días cada uno antes de comenzar a intentar crear alguna opinión.

Ser consistente en el nombre de variable. También asegúrese de que los nombres se ajusten a los demás, para que haya armonía dentro de todo el programa. Esto se aplica incluso si usted es el único autor del software, será más fácil mantener más tarde. Cree una lista de prefijos y sufijos usados ​​(E.gramo. max, min, get, set, es, cnt) y vaya con ellos, a menos que se le pregunte lo contrario. La consistencia es la palabra clave aquí.

Pautas específicas de GNU

Lo que sigue es un resumen de los estándares de codificación de GNU, porque sabemos que no te gusta leer tales cosas. Entonces, si está escribiendo un código que le gustaría encajar en el ecosistema GNU, este es el documento para leer. Incluso si no lo hace, sigue siendo una buena lectura sobre cómo escribir el código adecuado.

Vale la pena leer este documento en su totalidad si está creando o manteniendo el software GNU, pero encontrará las partes más importantes a continuación. Un primer problema que vale la pena mencionar es cómo lidiar con los prototipos de funciones. Vuelva a la parte que trata con eso si tiene algún problema. La idea es "Si tiene sus propias funciones, use una declaración de prototipo antes de Main (), luego defina la función cuando sea necesario."Aquí hay un ejemplo:

#include int func (int, int) int main () [...] int func (int x, int z) [...] 

Use la sangría adecuada y constante. Esto no puede ser enfatizado suficientemente. Programadores experimentados con años y años de código detrás lo tomarán muy mal cuando envíe código con sangría inadecuada. En nuestro caso, la mejor manera de acostumbrarse a cómo lo hace GNU es mediante el uso de emacs de GNU (aunque esto no es de ninguna forma para decirle que “GNU emacs es bueno para usted, úselo.", Como somos proponentes del libre albedrío y elección), donde el comportamiento predeterminado para el código C es la sangría establecida en dos espacios y aparatos ortopédicos en una línea para ellos mismos. Que nos lleva a otro tema importante. Algunas personas usan aparatos ortopédicos como este:

mientras (var == 1) código ... 

... mientras que otros, incluida la gente de GNU, lo hagan así:

mientras (var == 1) código ...

Por supuesto, esto también se aplica a expresiones condicionales, funciones y cada ocasión en la que necesite usar aparatos ortopédicos en el código C. En cuanto a que se note, esta elección es algo muy específico de GNU, y cuánto de esto respeta depende únicamente de su gusto y postura sobre el tema.

Nuestro próximo problema es técnico y una promesa que tuve que conservar: el problema malloc (). Además de escribir mensajes de error pertinentes y significativos, a diferencia de los que todos hemos visto en otros sistemas operativos, verifique que Malloc () y los amigos siempre devuelvan cero. Estos son problemas muy serios, y obtendrá algunas palabras lección sobre malloc () y cuándo usarlo. A estas alturas ya sabes qué es asignar la memoria de forma automática o estadística. Pero estos métodos no cubren todas las bases. Cuando necesita asignar memoria y tener más control sobre la operación, hay malloc () y amigos, para la asignación dinámica. Su propósito es asignar la memoria disponible desde el montón, Luego, el programa usa la memoria a través de un puntero que regresa Malloc (), luego dijo que la memoria debe ser gratuita () D. Y "imprescindible" se escribirá con capitales en letras de 2 pies con un color rojo ardiente. Eso es todo con Malloc (), y las razones ya han sido expuestas anteriormente en la parte anterior.

Se le insta a utilizar una interfaz consistente en todos sus programas de línea de comandos. Si ya es un usuario experimentado de GNU/Linux, ha notado que casi todos los programas tienen -versión y -help, además, por ejemplo, -v para verbosa, si tal es el caso. No nos meteremos en todo aquí; Tome una copia de los estándares de codificación de GNU, la necesitará de todos modos.

Aunque personalmente tiendo a pasar por alto esto, y para muchos es un problema menor, mejorará la legibilidad de su código, porque, nuevamente, así es como funciona nuestro cerebro. La idea es: cuando tengas dudas sobre el uso de espacios, úsalos. Por ejemplo:

int func (var1, var2); int func (var1, var2);

Hay algunos que dicen que no puedes evitar los ifs anidados. Hay otros que dicen "¿por qué evitar los IF anidados??"Y hay otros que simplemente no usan IFS anidados. Creará su propia opinión sobre esto a medida que pase el tiempo y las líneas de código que escribe. La idea es que, si los usa, hágalos tan legibles como sea humanamente posible, ya que pueden conducir fácilmente a un código casi-espagueti, difícil de leer y mantener. Y de nuevo, usa comentarios.

El estándar de codificación de GNU dice que es bueno que su código sea lo más portátil posible, "pero no supremo". En cuanto a hardware portátil? Que depende del propósito del programa y de las máquinas que tenga a su disposición. Nos referimos más al lado del software, a saber, la portabilidad entre los sistemas UNIX, el código abierto o no. Evite IFDEFS si puede, evite suposiciones con respecto a las ubicaciones de los archivos (E.gramo. Solaris instala software de terceros en /OPT, mientras que BSD y GNU /Linux no lo hacen), y generalmente apunta a un código limpio. Hablando de supuestos, ni siquiera asuma que un byte es de ocho bits o que el espacio de direcciones de una CPU debe ser un número uniforme.

Documentar su código, en forma de páginas manuales y lecturas bien escritas, etc., es otro aspecto primordial del desarrollo de software. Sí, es una tarea tediosa, pero si no tiene un escritor de documentación en su equipo, es su responsabilidad hacerlo, ya que cada buen programador hace su trabajo de A a Z.

Conclusión

La próxima vez continuaremos desde donde lo dejamos aquí: pasar de la idea a un programa completo, con makfiles, documentación, ciclos de lanzamiento y todas las cosas divertidas. El único ejercicio que tengo para usted es pasar por los estándares de codificación de GNU y modificar su código para conformarse. Y prepárate, la próxima vez que sea divertido!

Esto es lo que puede esperar a continuación:

• I. C Desarrollo en Linux - Introducción
• II. Comparación entre C y otros lenguajes de programación
• III. Tipos, operadores, variables
• IV. Control de flujo
• V. Funciones
• VI. Punteros y matrices
• VII. Estructuras
• VIII. E/S básica
• Ix. Estilo de codificación y recomendaciones
• X. Construyendo un programa
• Xi. Embalaje para Debian y Fedora
• Xii. Obtener un paquete en los repositorios oficiales de Debian

Tutoriales de Linux relacionados:

• Tutorial de depuración de GDB para principiantes
• Instale Arch Linux en VMware Workstation
• Una introducción a la automatización, herramientas y técnicas de Linux
• Cosas para instalar en Ubuntu 20.04
• Expresiones regulares de Python con ejemplos
• Cómo construir una aplicación Tkinter utilizando un objeto orientado ..
• Bash Regex avanzado con ejemplos
• Bash Loops con ejemplos
• Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
• Bucles anidados en guiones Bash