Lines Matching refs:para
13 puntos de vista sobre nadie, pero esto vale para todo lo que tengo que
14 mantener, y preferiría que para la mayoría de otras cosas también. Por
47 declaración de switch es para alinear el ``switch`` y sus etiquetas
78 No use comas para evitar el uso de llaves:
85 Siempre use llaves para múltiples declaraciones:
99 espacios nunca se utilizan para la sangría, y el ejemplo anterior se rompe
124 Sin embargo, nunca rompa los strings visibles para el usuario, como los
133 técnicas para elegir una estrategia de ubicación sobre la otra, pero la
204 vacías para poner comentarios.
246 El estilo del kernel Linux para el uso de espacios depende (principalmente)
303 nuevas líneas como sea apropiado, para que pueda comenzar a escribir la
327 vistos, los nombres descriptivos para las variables globales son
330 Una variable GLOBAL (para usar solo si **realmente** las necesita) necesita
343 cualquier tipo de variable que se utiliza para contener un valor temporal.
353 Los reemplazos recomendados para 'maestro / esclavo' son:
360 Los reemplazos recomendados para 'backlist / whitelist' son:
364 Las excepciones para la introducción de nuevos usos son mantener en espacio
374 Es un **error** usar typedef para estructuras y punteros. cuando ve un
391 útiles solamente para:
393 (a) objetos totalmente opacos (donde el typedef se usa activamente para
402 mismas. La razón por la que los tenemos para cosas como pte_t, etc.
414 De nuevo - debe haber una **razón** para esto. si algo es
415 ``unsigned long``, entonces no hay razón para hacerlo
423 (c) cuando lo use para crear literalmente un tipo **nuevo** para
429 Aunque sólo costaría un corto período de tiempo para los ojos y
430 cerebro para acostumbrarse a los tipos estándar como ``uint32_t``,
441 (e) Tipos seguros para usar en el espacio de usuario.
443 En ciertas estructuras que son visibles para el espacio de usuario, no
465 declaración de case, donde tiene que hacer un montón de pequeñas cosas para
472 compilador que los alinee si cree que es crítico para el rendimiento, y
499 Linux porque es una forma sencilla de añadir información valiosa para el
512 El orden preferido de elementos para un prototipo de función es:
528 Tenga en cuenta que para una **definición** de función (es decir, el cuerpo
559 La razón para usar gotos es:
602 Normalmente la solución para esto es dividirlo en dos etiquetas de error
613 Idealmente, debería simular errores para probar todas las rutas de salida.
621 comentario: es mucho mejor escribir el código para que el
629 hacer pequeños comentarios para notar o advertir sobre algo particularmente
636 y ``scripts/kernel-doc`` para más detalles.
638 El estilo preferido para comentarios largos (de varias líneas) es:
643 * Este es el estilo preferido para comentarios
651 Para archivos en net/ y drivers/net/, el estilo preferido para comentarios
656 /* El estilo de comentario preferido para archivos en net/ y drivers/net
665 comas para múltiples declaraciones de datos). Esto le deja espacio para un
731 Esto hará que emacs funcione mejor con el estilo de código del kernel para
748 manual. Pero recuerde: ``indent`` no es la solución para una mala
751 Tenga en cuenta que también puede usar la herramienta ``clang-format`` para
752 ayudarlo con estas reglas, para volver a formatear rápidamente partes de su
753 código automáticamente, y revisar archivos completos para detectar errores
755 útil para ordenar ``#includes``, para alinear variables/macros, para
757 :ref:`Documentation/process/clang-format.rst <clangformat>` para más
769 bool "Soporte para auditar"
773 subsistema kernel, como SELinux (que requiere esto para
777 Características seriamente peligrosas (como soporte de escritura para
797 que significa que absolutamente **tiene** para hacer referencia y contar
807 El bloqueo se utiliza para mantener la coherencia de las estructuras de
902 ret es un nombre común para una variable local -es menos probable que
913 Cuide la ortografía de los mensajes del kernel para causar una buena
923 que debe usar para asegurarse de que los mensajes coincidan con el
930 los tiene, pueden ser de gran ayuda para la resolución remota de problemas.
935 definido o se establezca CONFIG_DYNAMIC_DEBUG. Eso es cierto para dev_dbg()
936 también, y una convención relacionada usa VERBOSE_DEBUG para agregar
939 Muchos subsistemas tienen opciones de depuración de Kconfig para activar
950 vzalloc(). Consulte la documentación de la API para obtener más información.
954 La forma preferida para pasar el tamaño de una estructura es la siguiente:
961 la legibilidad, y presenta una oportunidad para un error cuando se cambia
969 La forma preferida para asignar una matriz es la siguiente:
975 La forma preferida para asignar una matriz a cero es la siguiente:
995 medio para reemplazar macros, consulte el Capítulo 12), muy a menudo no lo
998 de icache para la CPU, y sencillamente porque hay menos memoria disponible
999 para el pagecache. Solo piense en esto; un fallo en la memoria caché de la
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
1066 se pueden usar cuando esto sea adecuado. Se recomienda el uso de bool para
1067 mejorar la legibilidad y, a menudo, es una mejor opción que 'int' para
1072 compilada. Las estructuras que son optimizadas para la alineación y el
1079 De manera similar, para los argumentos de función, se pueden consolidar
1108 encabezado para ver qué más ya está definido y que no debe reproducir en su
1140 anularlos. Esto incluye marcadores para sangría y configuración de modo.
1142 método mágico para que la sangría funcione correctamente.
1149 ensamblador en línea para interactuar con funcionalidades de CPU o
1160 en C. Los prototipos de C para el ensamblador deben usar ``asmlinkage``.
1162 Es posible que deba marcar su declaración asm como volátil, para evitar que
1170 para indentar correctamente la siguiente instrucción en la salida en
1185 archivo de encabezado que defina funciones para usar en esos archivos .c,
1188 compilador evitará generar cualquier código para las llamadas restantes,
1202 Dentro del código, cuando sea posible, use la macro IS_ENABLED para
1252 "Soy demasiado perezoso para tener en cuenta los errores" no es una excusa
1253 para usar BUG(). Importantes corrupciones internas sin forma de continuar
1262 el sistema lo suficiente como para que el registro excesivo se convierta en
1268 WARN*() está diseñado para situaciones inesperadas que nunca deberían
1269 suceder. Las macros WARN*() no deben usarse para nada que se espera que
1272 para una condición esperada que vaya a activarse fácilmente, por ejemplo,
1283 es una razón válida para evitar el uso juicioso de WARN*(). Esto se debe a
1286 para afrontar las consecuencias de un sistema que es algo más probable que
1289 Use BUILD_BUG_ON() para aserciones en tiempo de compilación
1308 manuales GCC - en cumplimiento con K&R y este texto - para cpp, gcc,