Red de conocimiento informático - Espacio del host - Soy un novato y estoy listo para comenzar a aprender informática. Quiero aprender a programar. ¿Alguna vez has aprendido una base de datos? ¿Cómo empezar? ¿Qué conocimientos básicos debo aprender? tú.

Soy un novato y estoy listo para comenzar a aprender informática. Quiero aprender a programar. ¿Alguna vez has aprendido una base de datos? ¿Cómo empezar? ¿Qué conocimientos básicos debo aprender? tú.

[Reimprimir] Estilo de código del programa C

Conexión original: web.net/modules.php?name=Forumsamp; file=viewforumamp;f=4

El siguiente artículo es el archivo Documentación/CodingStyle en el kernel de Linux. Pensé que era bastante interesante, así que lo traduje porque aunque este es solo el estilo de codificación "linux", los estilos de los excelentes programas C son más o menos los mismos. Especialmente cosas relacionadas con emacs, debe haber errores de traducción, corríjame

Código:

Estilo de codificación del kernel de Linux

Este breve artículo describe la codificación preferida del kernel de Linux estilo. El estilo de codificación es algo muy personal y no impondré mis opiniones a nadie. Sin embargo, después de todo, el código del kernel de Linux es algo que debo poder mantener, por lo que prefiero que su estilo de codificación sea el que me gusta. Por favor, al menos considere esto.

Primero, recomiendo imprimir una copia de los Estándares de codificación GNU y no leerla. Quémalo, no es más que un gesto simbólico.

Luego, consulte:

Capítulo 1: Sangría

Las pestañas (tabulaciones) tienen un tamaño de 8 caracteres, por lo que la sangría debe tener un tamaño de 8 caracteres. Algunos rebeldes han intentado hacer que la sangría tenga 4 (¡o incluso 2!) caracteres de longitud, lo que es como tratar de definir PI como 3.

Básico: La idea detrás de la sangría es definir claramente dónde comienza y termina un bloque de control. Especialmente si tienes grandes sangrías después de haber estado mirando la pantalla durante 20 horas seguidas. Verá más fácilmente los beneficios de la sangría.

Ahora, algunas personas dicen que la sangría de 8 caracteres hace que el código esté demasiado a la derecha y sea incómodo de ver en una pantalla de terminal de 80 caracteres de ancho. La respuesta a esta pregunta es: si tienes más de 3 niveles de sangría, estás confundido y debes modificar tu programa.

En resumen, la sangría de 8 caracteres hace que el programa sea más fácil de leer, y cuando ocultas funciones demasiado, la sangría de varios niveles también te dará una advertencia visual. Preste atención a este mensaje de advertencia.

Capítulo 2: Colocación de llaves

Otra cosa importante a considerar en los programas en C es la colocación de llaves. A diferencia del tamaño de la sangría, no existe ninguna razón técnica sobre cómo se deben colocar los tirantes. Sin embargo, el método preferido es el mostrado por los profetas Brain Kernighan y Dennis Ritchie: poner el corchete de apertura al final de la línea y el corchete de cierre al principio de la línea. Es decir:

si (x es verdadero) {

hacemos y

}

Sin embargo, existe otra situación, que es la función: la función debe colocar los corchetes izquierdo y derecho al comienzo de la línea. Es decir:

int function(int x)

{

cuerpo de función

}

Rebelión Hay gente por todas partes. Dijeron que esto llevaría a... bueno, inconsistencias. Pero todas las personas que piensan bien saben que: (1) Kamp; R tiene razón; (2) Kamp R sigue teniendo razón; Además, las funciones no se parecen a nada (no puedes ocultarlas en C).

Tenga en cuenta que la línea donde se encuentra el corchete derecho no debe tener nada más a menos que vaya seguida de un juicio condicional. Es decir, el "mientras" en la declaración do- while y el "otro" en la declaración if-else.

Así:

hacer {

cuerpo del bucle do

} while (condición

y:

);

si (x == y) {

..

} si no (x gt; y) {

...

} else {

....

}

Basado en: Kamp R.

Además, tenga en cuenta que esta colocación de llaves reduce el número de líneas en blanco sin comprometer la legibilidad. Por lo tanto, cuando no puedes tener muchas líneas en blanco en la pantalla (piensa en una pantalla de terminal de 25 líneas), tienes más líneas en blanco para poner comentarios.

Capítulo 3: Nombrar

C es un lenguaje sencillo, y los nombres que utilices también deberían serlo. A diferencia de los programadores de Modula-2 y Pascal, los programadores de C no utilizan nombres "inteligentes" como "ThisVariableIsATemporaryCounter". Los programadores de C deberían llamarlo "tmp", que es más fácil de escribir y no más difícil de entender.

Sin embargo, las cosas se vuelven más complicadas cuando nos enfrentamos a situaciones complejas y es necesario dar a las variables globales un nombre descriptivo. Llamar "foo" a una función global es miope.

Las variables globales (utilizadas sólo cuando realmente las necesitas) deben tener nombres descriptivos, al igual que las funciones globales. Si tiene una función que cuenta el número actual de usuarios, debe llamarse "count_active_user()" o algo similar, no "cntusr()".

Escribir el tipo de función en el nombre de la función (la llamada "nomenclatura húngara") es simplemente un problema mental: el compilador siempre conoce el tipo de función y puede verificarlo, esta nomenclatura solo generará confusión. los propios programadores. No es de extrañar que Microsoft siempre cree programas llenos de errores.

Los nombres de las variables locales deben ser lo más breves posible y directos. Si tiene una variable de contador de bucle entero normal, debe llamarse "i". Llamarlo "loop_counter" no logra nada a menos que se malinterprete (lo cual, por implicación, es aún peor). De manera similar, "tmp" se puede utilizar como nombre de una variable utilizada para almacenar valores temporales de cualquier tipo.

Si tiene miedo de confundir los nombres de las variables locales, se enfrenta a otro problema, también conocido como "síndrome de desequilibrio funcional de la hormona del crecimiento". Consulte el siguiente capítulo.

Capítulo 4: Funciones

Las funciones deben ser breves, agradables y hacer una cosa. Deben llenar 1 o 2 pantallas (como sabemos, el tamaño de pantalla ISO/ANSI es 80X24), hacer una cosa y hacerlo bien.

La longitud máxima de una función es inversamente proporcional a su complejidad y nivel de sangría. Entonces, si tiene una función conceptualmente simple (caso, "simple" significa simple, no fácil), y resulta que contiene una declaración de caso muy larga, entonces tiene que preparar un manejo incomprensible para diferentes situaciones. Entonces, una función tan larga no es problema.

Sin embargo, si tienes una función compleja que sospechas que un estudiante de primer año de secundaria que no sea un genio podría no ser capaz de entender, debes intentar reducirla más cerca del límite máximo de función mencionado anteriormente. Puede utilizar algunas funciones auxiliares y darles nombres descriptivos (si cree que las llamadas a estas funciones auxiliares son críticas para el rendimiento, puede pedirle al compilador que las incluya. Esto suele ser mejor que hacer todo en una sola función).

Existe otra medida de función: el número de variables locales. Esto no debería ser más de 5 a 10 o podrías equivocarte. Esta función debería repensarse y dividirse en pedazos más pequeños. El cerebro humano generalmente puede recordar 7 cosas diferentes al mismo tiempo. Si excedes este número, te confundirás.

Tal vez crea que es muy inteligente, así que comprenda lo que ha estado haciendo en las próximas dos semanas.

Capítulo 5: Comentarios

Los comentarios son útiles, pero demasiados comentarios pueden ser perjudiciales. No intente explicar cómo funciona su código en los comentarios: es mejor tratar cómo funciona el código como algo obvio, y comentar código incorrecto es una pérdida de tiempo.

Generalmente, desea que sus comentarios le digan qué hace el código, no cómo lo hace. Además, trate de evitar hacer comentarios dentro del cuerpo de la función: si la función es compleja, lo más probable es que necesite comentarla por separado, así que regrese al Capítulo 4 para echarle un vistazo. Puede anotar un fragmento de código (hermoso o feo) para llamar la atención o una advertencia, pero no se exceda. En cambio, los comentarios deben colocarse al principio de la función para decirle a la gente qué hace la función, no por qué lo hace.

Capítulo 6: Has hecho un lío

Vale, veamos. Lo más probable es que alguien que haya estado usando UNIX durante mucho tiempo le haya dicho que "GNU emacs" puede formatear automáticamente el código fuente del programa C. Usted habrá notado que esto es cierto, y lo hace, pero por defecto es mucho menos. Útil mucho menos de lo esperado: escribir innumerables monos en GNU emacs nunca producirá un buen programa.

Por lo tanto, puedes eliminar GNU emacs o configurarlo de forma sensata. Para este último, puede pegar la siguiente línea en su archivo .emacs:

(defun linux-c-mode ()

"Modo C con valores predeterminados ajustados para usar con Linux kernel."

(interactivo)

(modo c)

(estilo c-set "Kamp;R")

(setq c-basic-offset Cool)

Esto definirá un comando para hacer que el código C se parezca a Linux al hackear un módulo, si pones "-*- linux-c. -*-". en las dos primeras líneas, este módulo se llamará automáticamente. Además, si planea llamarlo automáticamente cada vez que edite un archivo fuente en /usr/src/linux, tal vez use el siguiente comando:

(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)

auto-mode- alist))

Agréguelo a su archivo .emacs

Pero incluso si no puede lograr que emacs lo formatee correctamente, eso no es todo: Y el programa "sangría".

Bueno, nuevamente, GNU indent tiene el mismo problema que GNU emacs, lo que requiere que le des algunas opciones de línea de comando. Sin embargo, esto no es tan malo, ya que incluso GNU indent reconoce la autoridad de K&R (. La gente de GNU no es un demonio, simplemente son tan estrictos aquí que es engañoso), por lo que puedes darle una opción de sangría como esta: "- kr -i8" (que significa "estilo K&R, sangría de 8 caracteres").

El programa "sangría" tiene muchas opciones, especialmente al comentar programas redistribuidos. Debes leer su manual. Recuerda: "sangría" no es la clave mágica para arreglar un programa incorrecto. p>Capítulo 7: Archivos de configuración

Configuración. Para las opciones (arch/xxx/config.in y todos los archivos Config.in), utilice diferentes estilos de sangría.

Si el nivel de sangría en el código es 3, la opción de configuración debería ser 2, lo que puede implicar dependencias. Este último es solo una opción para bool/tristate (es decir, dos estados/tres estados). Para otras situaciones, utilice el sentido común. Por ejemplo:

if [ "$CONFIG_EXPERIMENTAL" = "y" ]; entonces

tristate 'Aplicar nitroglicerina dentro del teclado (PELIGROSO)' CONFIG_BOOM

if [ "$CONFIG_BOOM" != "n" ]; luego

bool 'Emite mensajes agradables cuando explotas' CONFIG_CHEER

fi

fi

Normalmente CONFIG_EXPERIMENTAL debería aparecer alrededor de todas las opciones inestables. Todas las opciones que se sabe que corrompen datos (como el soporte de escritura experimental del sistema de archivos) deben marcarse (PELIGROSAS) y otras opciones experimentales deben marcarse (EXPERIMENTAL).

Capítulo 8: Estructura de datos

Si la estructura de datos se crea/destruye en el entorno del hilo (caso: el hilo mencionado aquí es una entidad de ejecución, que puede ser un proceso o un hilo del núcleo u otro), entonces todos deberían tener recuentos de referencias. No existe un mecanismo de recolección de basura en el kernel (y la recolección de basura fuera del kernel también es lenta e ineficiente), lo que significa que absolutamente debes hacer referencia al recuento en cada uso.

El recuento de referencias significa que puede evitar bloqueos y permitir que varios subprocesos accedan a la estructura de datos en paralelo, y no tiene que preocuparse de que esto suceda solo porque el subproceso que accede a la estructura de datos durmió durante un tiempo o Estaba haciendo otra cosa. Desaparecerán.

Tenga en cuenta que los bloqueos no reemplazan el recuento de referencias. Los bloqueos se utilizan para mantener la coherencia de las estructuras de datos y el recuento de referencias es una tecnología de gestión de memoria. Generalmente ambos son necesarios y no se confunden entre sí.

Es cierto que muchas estructuras de datos pueden tener dos niveles de recuento de referencias, como cuando los usuarios tienen diferentes "clases". La subclase registra el número de usuarios de esa clase y, cuando llega a cero, el recuento global se reduce en uno.

Un ejemplo de este "recuento de referencias múltiples" se puede encontrar en el subsistema de administración de memoria ("struct mm_struct": mm_users y mm_count), y también se puede encontrar en el código del sistema de archivos. ("struct super_block": s_count y s_active).

Recuerde: si otro hilo puede encontrar su estructura de datos y usted no la ha contado, es casi seguro que se trata de un error.