Lines Matching full:de
12 del kernel Linux. El estilo de código es muy personal y no **forzaré** mi
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
17 En primer lugar, sugeriría imprimir una copia de los estándares de código
20 De todos modos, aquí va:
28 de 4 (¡o incluso 2!) caracteres de longitud, y eso es similar a tratar de
29 definir el valor de PI como 3.
31 Justificación: La idea detrás de la sangría es definir claramente dónde
32 comienza y termina un bloque de control. Especialmente, cuando ha estado
36 Bueno, algunas personas dirán que tener sangrías de 8 caracteres hace que
38 pantalla de terminal de 80 caracteres. La respuesta a eso es que si
39 necesita más de 3 niveles de sangría, está en apuros de todos modos y
42 En resumen, las sangrías de 8 caracteres facilitan la lectura y tienen la
43 ventaja añadida de advertirle cuando está anidando sus funciones demasiado
46 La forma preferida de facilitar múltiples niveles de sangría en una
47 declaración de switch es para alinear el ``switch`` y sus etiquetas
48 ``case`` subordinadas en la misma columna, en lugar de hacer ``doble
78 No use comas para evitar el uso de llaves:
94 Tampoco ponga varias asignaciones en una sola línea. El estilo de código
98 Aparte de los comentarios, la documentación y excepto en Kconfig, los
102 Consiga un editor decente y no deje espacios en blanco al final de las
108 El estilo de código tiene todo que ver con la legibilidad y la
111 El límite preferido en la longitud de una sola línea es de 80 columnas.
113 Las declaraciones de más de 80 columnas deben dividirse en partes, a menos
119 descendientes a un paréntesis de función abierto.
121 Estas mismas reglas se aplican a los encabezados de funciones con una larga
122 lista de argumentos.
125 mensajes printk, porque eso rompe la capacidad de grep a estos.
128 3) Colocación de llaves y espacios
131 El otro problema que siempre surge en el estilo C es la colocación de
132 llaves. A diferencia del tamaño de la sangría, existen pocas razones
133 técnicas para elegir una estrategia de ubicación sobre la otra, pero la
135 la llave de apertura en la línea, y colocar la llave de cierre primero,
144 Esto se aplica a todos los bloques de declaraciones que no son funciones
161 de apertura al comienzo de la siguiente línea, así:
167 cuerpo de la función
170 Gente hereje de todo el mundo ha afirmado que esta inconsistencia es...
173 especiales de todos modos (no puede anidarlas en C).
175 Tenga en cuenta que la llave de cierre está vacía en su línea propia,
176 **excepto** en los casos en que es seguida por una continuación de la misma
200 Además, tenga en cuenta que esta colocación de llaves también minimiza el
201 número de líneas vacías (o casi vacías), sin pérdida de legibilidad. Así,
202 como el suministro de nuevas líneas en su pantalla no es un recurso
203 renovable (piense en pantallas de terminal de 25 líneas), tienes más líneas
222 Esto no aplica si solo una rama de una declaración condicional es una sola
234 Además, use llaves cuando un bucle contenga más de una declaración simple:
246 El estilo del kernel Linux para el uso de espacios depende (principalmente)
247 del uso de función versus uso de palabra clave. Utilice un espacio después
248 de (la mayoría de) las palabras clave. Las excepciones notables son sizeof,
251 el idioma, como en: ``sizeof info`` después de que ``struct fileinfo info;``
254 Así que use un espacio después de estas palabras clave::
265 No agregue espacios alrededor (dentro) de expresiones entre paréntesis.
273 Al declarar datos de puntero o una función que devuelve un tipo de puntero,
274 el uso preferido de ``*`` es adyacente al nombre del dato o nombre de la
284 Use un espacio alrededor (a cada lado de) la mayoría de los operadores
285 binarios y ternarios, como cualquiera de estos::
289 pero sin espacio después de los operadores unarios::
293 sin espacio antes de los operadores unarios de incremento y decremento del
298 y sin espacio alrededor de los operadores de miembros de estructura ``.`` y
301 No deje espacios en blanco al final de las líneas. Algunos editores con
302 ``inteligente`` sangría insertarán espacios en blanco al comienzo de las
304 siguiente línea de código de inmediato. Sin embargo, algunos de estos
306 poniendo una línea de código allí, como si dejara una línea en blanco. Como
311 usted; sin embargo, si se aplica una serie de parches, esto puede hacer que
312 los parches posteriores de la serie fallen al cambiar sus líneas de
319 C es un lenguaje espartano, y sus convenciones de nomenclatura deberían
320 seguir su ejemplo. A diferencia de los programadores de Modula-2 y Pascal,
321 los programadores de C no usan nombres cuquis como
322 EstaVariableEsUnContadorTemporal. Un programador de C lo llamaría
323 variable ``tmp``, que es mucho más fácil de escribir, y no es mas difícil
324 de comprender.
326 SIN EMBARGO, mientras que los nombres de mayúsculas y minúsculas están mal
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
339 Los nombres de las variables LOCALES deben ser breves y directos. Si usted
340 tiene algún contador aleatorio de tipo entero, probablemente debería
342 posibilidad de ser mal entendido. De manera similar, ``tmp`` puede ser casi
343 cualquier tipo de variable que se utiliza para contener un valor temporal.
345 Si tiene miedo de mezclar los nombres de las variables locales, tiene otro
346 problema, que se denomina síndrome de
347 función-crecimiento-desequilibrio-de-hormona. Vea el capítulo 6 (Funciones).
349 Para nombres de símbolos y documentación, evite introducir nuevos usos de
350 'master / slave' (maestro / esclavo) (o 'slave' independientemente de
364 Las excepciones para la introducción de nuevos usos son mantener en espacio
365 de usuario una ABI/API, o al actualizar la especificación del código de un
366 hardware o protocolo existente (a partir de 2020) que requiere esos
367 términos. Para nuevas especificaciones, traduzca el uso de la terminología
368 de la especificación al estándar de código del kernel donde sea posible.
397 usando las funciones de acceso adecuadas.
401 La opacidad y las ``funciones de acceso`` no son buenas por sí
403 es que hay real y absolutamente **cero** información accesible de
414 De nuevo - debe haber una **razón** para esto. si algo es
419 pero si hay una razón clara de por qué bajo ciertas circunstancias
424 comprobación de tipos.
429 Aunque sólo costaría un corto período de tiempo para los ojos y
431 algunas personas se oponen a su uso de todos modos.
433 Por lo tanto, los tipos ``u8/u16/u32/u64`` específicos de Linux y sus
435 permitidos, aunque no son obligatorios en el nuevo código de su
438 Al editar código existente que ya usa uno u otro conjunto de tipos,
441 (e) Tipos seguros para usar en el espacio de usuario.
443 En ciertas estructuras que son visibles para el espacio de usuario, no
446 comparten con espacio de usuario.
450 de estas reglas.
459 caber en una o dos pantallas de texto (el tamaño de pantalla ISO/ANSI es
462 La longitud máxima de una función es inversamente proporcional a la
463 complejidad y el nivel de sangría de esa función. Entonces, si tiene una
465 declaración de case, donde tiene que hacer un montón de pequeñas cosas para
466 un montón de diferentes casos, está bien tener una función más larga.
468 Sin embargo, si tiene una función compleja y sospecha que un estudiante de
469 primer año de secundaria menos que dotado podría no comprender de qué se
470 trata la función, debe adherirse a los límites máximos tanto más de
473 probablemente lo hará mejor de lo que usted hubiera hecho).
475 Otra medida de la función es el número de variables locales. Estas no deben
476 exceder de 5 a 10, o está haciendo algo mal. Piense de nuevo en la función
478 realiza un seguimiento de aproximadamente 7 cosas diferentes, cualquier
480 gustaría entender lo que hizo dentro de 2 semanas.
484 después de la función de cierre de línea de llave. Por ejemplo:
494 6.1) Prototipos de funciones
497 En los prototipos de funciones, incluya nombres de parámetros con sus tipos
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
502 No utilice la palabra clave ``extern`` con declaraciones de función ya que
505 Al escribir prototipos de funciones, mantenga el `orden de los elementos regular
507 Por ejemplo, usando este ejemplo de declaración de función::
512 El orden preferido de elementos para un prototipo de función es:
514 - clase de almacenamiento (a continuación, ``static __always_inline``,
517 - atributos de clase de almacenamiento (aquí, ``__init`` -- es decir,
518 declaraciones de sección, pero también cosas como ``__cold``)
519 - tipo de retorno (aquí, ``void *``)
520 - atributos de tipo de retorno (aquí, ``__must_check``)
521 - nombre de la función (aquí, ``action``)
522 - parámetros de la función (aquí, ``(enum magic value, size_t size, u8 count, char *fmt, ...)``,
523 teniendo en cuenta que los nombres de los parámetros siempre deben
525 - atributos de parámetros de función (aquí, ``__printf(4, 5)``)
526 - atributos de comportamiento de la función (aquí, ``__malloc``)
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
530 función después de parámetros de la función. En estos casos, deberán ir
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
533 ejemplo de **declaración** anterior)::
541 7) Salida centralizada de funciones
544 Aunque desaprobado por algunas personas, el equivalente de la instrucción
545 goto es utilizado con frecuencia por los compiladores, en forma de
546 instrucción de salto incondicional.
552 Elija nombres de etiquetas que digan qué hace el goto o por qué existe el
553 goto. Un ejemplo de un buen nombre podría ser ``out_free_buffer:``
556 numerarlos si alguna vez agrega o elimina rutas de salida, y hacen que sea
557 difícil de verificar que sean correctos, de todos modos.
561 - Las declaraciones incondicionales son más fáciles de entender y seguir.
563 - errores al no actualizar los puntos de salida individuales al hacer
565 - ahorra el trabajo del compilador de optimizar código redundante ;)
591 Un tipo común de error a tener en cuenta es "un error de error" que es algo
601 El error en este código es que en algunas rutas de salida, ``foo`` es NULL.
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.
619 Los comentarios son buenos, pero también existe el peligro de comentar
620 demasiado. NUNCA trate de explicar CÓMO funciona su código en un
622 **funcionamiento** sea obvio y es una pérdida de tiempo explicar código mal
626 Además, trate de evitar poner comentarios dentro del cuerpo de una función:
627 si la función es tan compleja que necesita comentar por separado partes de
630 inteligente (o feo), pero trate de evitar el exceso. En su lugar, ponga los
631 comentarios al principio de la función, diga a la gente lo que hace y
634 Al comentar las funciones de la API del kernel, utilice el formato
638 El estilo preferido para comentarios largos (de varias líneas) es:
647 * Descripción: Una columna de asteriscos en el lado izquierdo,
656 /* El estilo de comentario preferido para archivos en net/ y drivers/net
659 * Es casi lo mismo que el estilo de comentario generalmente preferido,
664 derivados. Para este fin, use solo una declaración de datos por línea (sin
665 comas para múltiples declaraciones de datos). Esto le deja espacio para un
671 Está bien, todos lo hacemos. Probablemente un antiguo usuario de Unix le
674 menos que deseables (de hecho, son peores que los aleatorios) escribiendo -
675 un número infinito de monos escribiendo en GNU emacs nunca harán un buen
678 Por lo tanto, puede deshacerse de GNU emacs o cambiarlo y usar valores más
731 Esto hará que emacs funcione mejor con el estilo de código del kernel para
737 Ahora bien, de nuevo, la sangría de GNU tiene la misma configuración de
739 opciones de línea de comando. Sin embargo, eso no es tan malo, porque
740 incluso los creadores de GNU indent reconocen la autoridad de K&R (la gente
741 de GNU no es mala, solo están gravemente equivocados en este asunto), por
742 lo que simplemente de a la sangría las opciones ``-kr -i8`` (significa
743 ``K&R, guiones de 8 caracteres``), o use ``scripts/Lindent``, que indenta
746 ``indent`` tiene muchas opciones, y especialmente cuando se trata de
752 ayudarlo con estas reglas, para volver a formatear rápidamente partes de su
754 de estilo del código, errores tipográficos y posibles mejoras. También es
760 10) Archivos de configuración de Kconfig
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
766 ayuda tiene una sangría adicional de dos espacios. Ejemplo::
772 Habilita la infraestructura de auditoría que se puede usar con otro
774 registro de salida de mensajes avc). No hace auditoría de llamadas al
777 Características seriamente peligrosas (como soporte de escritura para
778 ciertos filesystems) deben anunciar esto de forma destacada en su cadena de
786 Para obtener la documentación completa sobre los archivos de configuración,
790 11) Estructuras de datos
793 Las estructuras de datos que tienen visibilidad fuera del contexto de un
795 contadores de referencia. En el kernel, la recolección de basura no existe
796 (y fuera, la recolección de basura del kernel es lenta e ineficiente), lo
800 El conteo de referencias significa que puede evitar el bloqueo y permite
801 que múltiples usuarios tengan acceso a la estructura de datos en paralelo -
802 y no tengan que preocuparse de que la estructura, de repente, desaparezca
803 debajo de su control, solo porque durmieron o hicieron otra cosa por un
806 Tenga en cuenta que el bloqueo **no** reemplaza el recuento de referencia.
807 El bloqueo se utiliza para mantener la coherencia de las estructuras de
808 datos, mientras que la referencia y contar es una técnica de gestión de
812 De hecho, muchas estructuras de datos pueden tener dos niveles de conteo de
813 referencias, cuando hay usuarios de diferentes ``clases``. El conteo de
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.
817 Se pueden encontrar ejemplos de este tipo de ``recuento de referencias de
818 niveles múltiples`` en la gestión de memoria (``struct mm_struct``:
819 mm_users y mm_count), y en código del sistema de archivos
822 Recuerde: si otro hilo puede encontrar su estructura de datos y usted no
823 tiene un recuento de referencias, es casi seguro que tiene un error.
828 Los nombres de macros que definen constantes y etiquetas en enumeraciones
837 Se aprecian los nombres de macro en MAYÚSCULAS, pero las macros que se
855 1) macros que afectan el flujo de control:
865 es una **muy** mala idea. Parece una llamada de función pero sale de la
866 función de ``llamada``; no rompa los analizadores internos de aquellos que
869 2) macros que dependen de tener una variable local con un nombre mágico:
881 4) olvidarse de la precedencia: las macros que definen constantes usando
890 5) colisiones de espacio de nombres ("namespace") al definir variables
905 El manual de cpp trata las macros de forma exhaustiva. El manual interno de
913 Cuide la ortografía de los mensajes del kernel para causar una buena
922 Hay varias modelos de macros de diagnóstico de driver en <linux/dev_printk.h>
923 que debe usar para asegurarse de que los mensajes coincidan con el
929 Crear buenos mensajes de depuración puede ser todo un desafío; y una vez
930 los tiene, pueden ser de gran ayuda para la resolución remota de problemas.
931 Sin embargo, la impresión de mensajes de depuración se maneja de manera
932 diferente a la impresión de otros mensajes que no son de depuración.
939 Muchos subsistemas tienen opciones de depuración de Kconfig para activar
941 usan #define DEBUG. Y cuando un mensaje de depuración debe imprimirse
942 incondicionalmente, por ejemplo si es ya dentro de una sección #ifdef
948 El kernel proporciona los siguientes asignadores de memoria de propósito
950 vzalloc(). Consulte la documentación de la API para obtener más información.
951 a cerca de ellos. :ref:`Documentation/core-api/memory-allocation.rst
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
963 se pasa a un asignador de memoria no.
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 *
984 Todas estas funciones de asignación genéricas emiten un volcado de pila
985 (" stack dump") en caso de fallo cuando se usan sin __GFP_NOWARN, por lo
986 que no sirve de nada emitir un mensaje de fallo adicional cuando se
989 15) La enfermedad de inline
992 Parece haber una común percepción errónea de que gcc tiene una magica
993 opción "hazme más rápido" de aceleración, llamada ``inline`` (en línea).
994 Mientras que el uso de inlines puede ser apropiado (por ejemplo, como un
996 es. El uso abundante de la palabra clave inline conduce a una mayor kernel,
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
1000 página provoca una búsqueda de disco, que tarda fácilmente 5 milisegundos.
1001 Hay MUCHOS ciclos de CPU que puede entrar en estos 5 milisegundos.
1003 Una razonable regla general es no poner funciones inline que tengan más de
1004 3 líneas de código en ellas. Una excepción a esta regla son los casos en
1005 que se sabe que un parámetro es una constante en tiempo de compilación, y
1006 como resultado de esto, usted *sabe*, el compilador podrá optimizar la
1007 mayor parte de su función en tiempo de compilación. Para un buen ejemplo de
1012 perdida de espacio. Mientras esto es técnicamente correcto, gcc es capaz de
1013 incorporarlos automáticamente sin ayuda, y esta el problema de
1014 mantenimiento de eliminar el inline, cuando un segundo usuario supera el
1015 valor potencial de la pista que le dice a gcc que haga algo que habría
1016 hecho de todos modos.
1021 Las funciones pueden devolver valores de muchos tipos diferentes, y uno de
1023 Dicho valor se puede representar como un número entero de código de error
1025 de cero = éxito).
1027 La mezcla de estos dos tipos de representaciones es una fuente fértil de
1028 errores difíciles de encontrar. Si el lenguaje C incluyera una fuerte
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
1038 agregar_trabajo() devuelve 0 en caso de éxito o -EBUSY en caso de fracaso.
1039 De la misma manera, ``dispositivo PCI presente`` es un predicado, y la
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
1050 de resultados. Los ejemplos típicos serían funciones que devuelven
1051 punteros; estos usan NULL o el mecanismo ERR_PTR para informar de fallos.
1060 !! no se necesita construcción, lo que elimina una clase de errores.
1063 verdadera y falsa, en lugar de 1 y 0.
1065 Los tipos de devolución de función bool y las variables de pila siempre
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
1076 consolidarlos en un bitfield con miembros de 1 bit, o usando un tipo de
1079 De manera similar, para los argumentos de función, se pueden consolidar
1081 'flags' a menudo, puede ser una alternativa de argumento más legible si los
1082 sitios de llamada tienen constantes desnudas de tipo verdaderas/falsas.
1084 De lo contrario, el uso limitado de bool en estructuras y argumentos puede
1090 El archivo de cabecera include/linux/kernel.h contiene una serie de macros
1091 que debe usar, en lugar de programar explícitamente alguna variante de
1092 estos por usted mismo. Por ejemplo, si necesita calcular la longitud de una
1099 De manera similar, si necesita calcular el tamaño de algún miembro de la
1106 También hay macros min() y max() que realizan una verificación estricta de
1107 tipos si lo necesita. Siéntase libre de leer detenidamente ese archivo de
1114 Algunos editores pueden interpretar la información de configuración
1138 No incluya ninguno de estos en los archivos fuente. La gente tiene sus
1139 propias configuraciones del editor, y sus archivos de origen no deben
1140 anularlos. Esto incluye marcadores para sangría y configuración de modo.
1148 En el código específico de arquitectura, es posible que deba usar
1149 ensamblador en línea para interactuar con funcionalidades de CPU o
1151 ensamblador en línea de forma gratuita cuando C puede hacer el trabajo.
1155 de ensamblador, en lugar de escribirlos repetidamente con ligeras
1158 Las funciones de ensamblador grandes y no triviales deben ir en archivos .S,
1159 con su correspondientes prototipos de C definidos en archivos de encabezado
1160 en C. Los prototipos de C para el ensamblador deben usar ``asmlinkage``.
1167 Al escribir una sola declaración de ensamblador en línea que contiene
1182 Siempre que sea posible, no use condicionales de preprocesador (#if,
1183 #ifdef) en archivos .c; de lo contrario, el código es más difícil de leer y
1184 la lógica más difícil de seguir. En cambio, use dichos condicionales en un
1185 archivo de encabezado que defina funciones para usar en esos archivos .c,
1186 proporcionando versiones de código auxiliar sin operación en el caso #else,
1189 produciendo resultados idénticos, pero la lógica es fácil de seguir.
1191 Prefiera compilar funciones completas, en lugar de porciones de funciones o
1192 porciones de expresiones. En lugar de poner un ifdef en una expresión,
1193 divida la totalidad de la expresión con una función de ayuda independiente
1198 definición sin usar, marque la definición como __maybe_unused en lugar de
1203 convertir un símbolo Kconfig en una expresión booleana de C, y utilícelo en
1204 un condicional de C normal:
1213 excluirá el bloque de código al igual que con un #ifdef, por lo que esto no
1214 agregará ningún tiempo de gastos generales en ejecución. Sin embargo, este
1215 enfoque todavía permite que el compilador de C vea el código dentro del
1220 Al final de cualquier bloque #if o #ifdef no trivial (más de unas pocas
1221 líneas), incluya un comentario después de #endif en la misma línea,
1233 En general, la decisión de romper el kernel pertenece al usuario, más que
1243 Use WARN() en lugar de BUG()
1246 No agregue código nuevo que use cualquiera de las variantes BUG(), como
1248 preferiblemente WARN_ON_ONCE(), y posiblemente con código de recuperación.
1249 El código de recuperación no es requerido si no hay una forma razonable de
1253 para usar BUG(). Importantes corrupciones internas sin forma de continuar
1256 Use WARN_ON_ONCE() en lugar de WARN() o WARN_ON()
1260 común que una condición de advertencia dada, si ocurre, ocurra varias
1271 posteriores a la condición, por ejemplo. De nuevo: WARN*() no debe usarse
1274 alternativa posible, si necesita notificar al usuario de un problema.
1276 No se preocupe sobre panic_on_warn de usuarios
1281 opción. Esta es la razón por la que hay un artículo de "No haga WARN a la
1282 ligera", arriba. Sin embargo, la existencia de panic_on_warn de usuarios no
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
1292 El uso de BUILD_BUG_ON() es aceptable y recomendado, porque es una aserción
1293 en tiempo de compilación, que no tiene efecto en tiempo de ejecución.
1309 detalles de gcc y sangría, todo disponible en https://www.gnu.org/manual/
1311 WG14 es el grupo de trabajo de estandarización internacional de la