sp_SP/process/coding-style.rst

8 Estilo en el código del kernel Linux
11 Este es un breve documento que describe el estilo preferido en el código
29 definir el valor de PI como 3.
37 el código se mueva demasiado a la derecha y dificulta la lectura en una
47 declaración de switch es para alinear el ``switch`` y sus etiquetas
78 No use comas para evitar el uso de llaves:
99 espacios nunca se utilizan para la sangría, y el ejemplo anterior se rompe
117 Los descendientes siempre son sustancialmente más cortos que el padre y
124 Sin embargo, nunca rompa los strings visibles para el usuario, como los
131 El otro problema que siempre surge en el estilo C es la colocación de
170 Gente hereje de todo el mundo ha afirmado que esta inconsistencia es...
200 Además, tenga en cuenta que esta colocación de llaves también minimiza el
202 como el suministro de nuevas líneas en su pantalla no es un recurso
246 El estilo del kernel Linux para el uso de espacios depende (principalmente)
251 el idioma, como en: ``sizeof info`` después de que ``struct fileinfo info;``
274 el uso preferido de ``*`` es adyacente al nombre del dato o nombre de la
332 una función que cuenta el número de usuarios activos, debe llamar a esta
335 Codificar el tipo de una función en el nombre (lo llamado notación húngara)
336 es estúpido: el compilador conoce los tipos de todos modos y puede
347 función-crecimiento-desequilibrio-de-hormona. Vea el capítulo 6 (Funciones).
367 términos. Para nuevas especificaciones, traduzca el uso de la terminología
381 en el código fuente, ¿qué significa?
393  (a) objetos totalmente opacos (donde el typedef se usa activamente para
394      **ocultar** cuál es el objeto).
435      permitidos, aunque no son obligatorios en el nuevo código de su
441  (e) Tipos seguros para usar en el espacio de usuario.
443      En ciertas estructuras que son visibles para el espacio de usuario, no
444      podemos requerir tipos C99 y o utilizat el ``u32`` anterior. Por lo
459 caber en una o dos pantallas de texto (el tamaño de pantalla ISO/ANSI es
463 complejidad y el nivel de sangría de esa función. Entonces, si tiene una
472 compilador que los alinee si cree que es crítico para el rendimiento, y
475 Otra medida de la función es el número de variables locales. Estas no deben
498 de datos. Aunque esto no es requerido por el lenguaje C, se prefiere en
499 Linux porque es una forma sencilla de añadir información valiosa para el
505 Al escribir prototipos de funciones, mantenga el `orden de los elementos regular
528 Tenga en cuenta que para una **definición** de función (es decir, el cuerpo
529 real de la función), el compilador no permite atributos de parámetros de
531 tras los atributos de clase (por ejemplo, tenga en cuenta el cambio de
532 posición de ``__printf(4, 5)`` a continuación, en comparación con el
544 Aunque desaprobado por algunas personas, el equivalente de la instrucción
552 Elija nombres de etiquetas que digan qué hace el goto o por qué existe el
562 - se reduce el anidamiento
565 - ahorra el trabajo del compilador de optimizar código redundante ;)
619 Los comentarios son buenos, pero también existe el peligro de comentar
621 comentario: es mucho mejor escribir el código para que el
630 inteligente (o feo), pero trate de evitar el exceso. En su lugar, ponga los
634 Al comentar las funciones de la API del kernel, utilice el formato
643 	* Este es el estilo preferido para comentarios
644 	* multilínea en el código fuente del kernel Linux.
647 	* Descripción: Una columna de asteriscos en el lado izquierdo,
651 Para archivos en net/ y drivers/net/, el estilo preferido para comentarios
659 	* Es casi lo mismo que el estilo de comentario generalmente preferido,
731 Esto hará que emacs funcione mejor con el estilo de código del kernel para
756 redistribuir texto y otras tareas similares. Vea el archivo
763 Para todos los archivos de configuración de Kconfig* en todo el árbol
765 ``config`` están indentadas con una tabulación, mientras que el texto de
787 consulte el archivo Documentation/kbuild/kconfig-language.rst.
794 solo subproceso en el que son creadas y destruidas, siempre debe tener
795 contadores de referencia. En el kernel, la recolección de basura no existe
800 El conteo de referencias significa que puede evitar el bloqueo y permite
806 Tenga en cuenta que el bloqueo **no** reemplaza el recuento de referencia.
814 subclases cuenta el número de usuarios de la subclase y disminuye el conteo
815 global solo una vez, cuando el recuento de subclases llega a cero.
855 1) macros que afectan el flujo de control:
867 leerán el código.
875 puede parecer algo bueno, pero es confuso como el infierno cuando uno lee
876 el código, y es propenso a romperse por cambios aparentemente inocentes.
907 en el kernel.
923 que debe usar para asegurarse de que los mensajes coincidan con el
924 dispositivo correcto y driver, y están etiquetados con el nivel correcto:
940 -DDEBUG en el Makefile correspondiente; en otros casos, los archivos
954 La forma preferida para pasar el tamaño de una estructura es la siguiente:
960 La forma alternativa donde se deletrea el nombre de la estructura perjudica
962 el tipo de variable de puntero, pero el tamaño correspondiente de eso que
965 Convertir el valor devuelto, que es un puntero vacío, es redundante. La
966 conversión desde el puntero vacío a cualquier otro tipo de puntero está
981 Ambos casos verifican el desbordamiento en el tamaño de asignación n *
994 Mientras que el uso de inlines puede ser apropiado (por ejemplo, como un
995 medio para reemplazar macros, consulte el Capítulo 12), muy a menudo no lo
997 que a su vez ralentiza el sistema en su conjunto, debido a una mayor huella
999 para el pagecache. Solo piense en esto; un fallo en la memoria caché de la
1006 como resultado de esto, usted *sabe*, el compilador podrá optimizar la
1013 incorporarlos automáticamente sin ayuda, y esta el problema de
1014 mantenimiento de eliminar el inline, cuando un segundo usuario supera el
1028 errores difíciles de encontrar. Si el lenguaje C incluyera una fuerte
1029 distinción entre enteros y booleanos, el compilador encontraría estos
1033 	Si el nombre de una función es una acción o un comando imperativo,
1034 	la función debe devolver un número entero de código de error. si el nombre
1047 Las funciones cuyo valor devuelto es el resultado real de un cálculo, en
1048 lugar de una indicación de si el cómputo tuvo éxito, no están sujetas a
1051 punteros; estos usan NULL o el mecanismo ERR_PTR para informar de fallos.
1056 El tipo bool del kernel Linux es un alias para el tipo C99 _Bool. Los
1058 explícita a bool convierte automáticamente el valor en verdadero o falso.
1066 se pueden usar cuando esto sea adecuado. Se recomienda el uso de bool para
1070 No use bool si el diseño de la línea de caché o el tamaño del valor son
1072 compilada. Las estructuras que son optimizadas para la alineación y el
1084 De lo contrario, el uso limitado de bool en estructuras y argumentos puede
1099 De manera similar, si necesita calcular el tamaño de algún miembro de la
1148 En el código específico de arquitectura, es posible que deba usar
1151 ensamblador en línea de forma gratuita cuando C puede hacer el trabajo.
1152 Puede y debe empujar el hardware desde C cuando sea posible.
1156 variaciones. Recuerde que el ensamblador en línea puede usar parámetros C.
1160 en C. Los prototipos de C para el ensamblador deben usar ``asmlinkage``.
1183 #ifdef) en archivos .c; de lo contrario, el código es más difícil de leer y
1186 proporcionando versiones de código auxiliar sin operación en el caso #else,
1194 y aplique el condicional a esa función.
1197 una configuración en particular, y el compilador advertiría sobre su
1212 El compilador "doblará"" constantemente el condicional e incluirá o
1213 excluirá el bloque de código al igual que con un #ifdef, por lo que esto no
1215 enfoque todavía permite que el compilador de C vea el código dentro del
1217 etc.). Por lo tanto, aún debe usar un #ifdef si el código dentro del bloque
1230 22) No rompa el kernel
1233 En general, la decisión de romper el kernel pertenece al usuario, más que
1236 Evite el panic()
1239 panic() debe usarse con cuidado y principalmente solo durante el arranque
1241 durante el arranque y no puede continuar.
1261 veces. Esto puede llenar el registro del kernel, e incluso puede ralentizar
1262 el sistema lo suficiente como para que el registro excesivo se convierta en
1273 mediante acciones en el espacio del usuario. pr_warn_once() es una
1283 es una razón válida para evitar el uso juicioso de WARN*(). Esto se debe a
1311 WG14 es el grupo de trabajo de estandarización internacional de la