Lines Matching refs:que
11 Este es un breve documento que describe el estilo preferido en el código
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
27 tienen 8 caracteres. Hay movimientos heréticos que intentan hacer sangría
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
70 No ponga varias declaraciones en una sola línea a menos que tenga algo que
108 El estilo de código tiene todo que ver con la legibilidad y la
114 que exceder las 80 columnas aumente significativamente la legibilidad y no
117 Los descendientes siempre son sustancialmente más cortos que el padre y
131 El otro problema que siempre surge en el estilo C es la colocación de
144 Esto se aplica a todos los bloques de declaraciones que no son funciones
170 Gente hereje de todo el mundo ha afirmado que esta inconsistencia es...
171 bueno... inconsistente, pero todas las personas sensatas saben que
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
249 typeof, alignof y __attribute__, que parecen algo así como funciones (y
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::
273 Al declarar datos de puntero o una función que devuelve un tipo de puntero,
303 nuevas líneas como sea apropiado, para que pueda comenzar a escribir la
307 resultado, termina con líneas que contienen espacios en blanco al final.
309 Git le advertirá sobre los parches que introducen espacios en blanco al
311 usted; sin embargo, si se aplica una serie de parches, esto puede hacer que
323 variable ``tmp``, que es mucho más fácil de escribir, y no es mas difícil
326 SIN EMBARGO, mientras que los nombres de mayúsculas y minúsculas están mal
331 tener un nombre descriptivo, al igual que las funciones globales. Si tiene
332 una función que cuenta el número de usuarios activos, debe llamar a esta
343 cualquier tipo de variable que se utiliza para contener un valor temporal.
346 problema, que se denomina síndrome de
366 hardware o protocolo existente (a partir de 2020) que requiere esos
390 Mucha gente piensa que los typedefs ``ayudan a la legibilidad``. No. Son
396 Ejemplo: ``pte_t`` etc. objetos opacos a los que solo puede acceder
402 mismas. La razón por la que los tenemos para cosas como pte_t, etc.
403 es que hay real y absolutamente **cero** información accesible de
410 aunque encajan en la categoría (d) mejor que aquí.
426 (d) Nuevos tipos que son idénticos a los tipos estándar C99, en ciertas
434 equivalentes con signo, que son idénticos a los tipos estándar son
438 Al editar código existente que ya usa uno u otro conjunto de tipos,
443 En ciertas estructuras que son visibles para el espacio de usuario, no
445 tanto, usamos __u32 y tipos similares en todas las estructuras que se
449 NUNCA JAMÁS use un typedef a menos que pueda coincidir claramente con una
452 En general, un puntero o una estructura que tiene elementos que pueden
464 función conceptualmente simple que es solo una larga (pero simple)
465 declaración de case, donde tiene que hacer un montón de pequeñas cosas para
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
472 compilador que los alinee si cree que es crítico para el rendimiento, y
473 probablemente lo hará mejor de lo que usted hubiera hecho).
479 elemento más y se confunde. Usted sabe que es brillante, pero tal vez le
480 gustaría entender lo que hizo dentro de 2 semanas.
502 No utilice la palabra clave ``extern`` con declaraciones de función ya que
515 teniendo en cuenta que ``__always_inline`` es técnicamente un atributo
523 teniendo en cuenta que los nombres de los parámetros siempre deben
528 Tenga en cuenta que para una **definición** de función (es decir, el cuerpo
552 Elija nombres de etiquetas que digan qué hace el goto o por qué existe el
555 nombres GW-BASIC como ``err1:`` y ``err2:``, ya que tendría que volver a
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.
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.
621 comentario: es mucho mejor escribir el código para que el
625 Generalmente, desea que sus comentarios digan QUÉ hace su código, no CÓMO.
627 si la función es tan compleja que necesita comentar por separado partes de
631 comentarios al principio de la función, diga a la gente lo que hace y
659 * Es casi lo mismo que el estilo de comentario generalmente preferido,
672 haya dicho que ``GNU emacs`` formatea automáticamente las fuentes C por
673 usted, y ha notado que sí, lo hace, pero los por defecto que tiene son
674 menos que deseables (de hecho, son peores que los aleatorios) escribiendo -
731 Esto hará que emacs funcione mejor con el estilo de código del kernel para
734 Pero incluso si no logra que emacs realice un formateo correcto, no todo
738 muerte cerebral que GNU emacs tiene, por lo que necesita darle algunas
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
747 comentar reformateos, es posible que desee echar un vistazo a la página del
751 Tenga en cuenta que también puede usar la herramienta ``clang-format`` para
765 ``config`` están indentadas con una tabulación, mientras que el texto de
772 Habilita la infraestructura de auditoría que se puede usar con otro
773 subsistema kernel, como SELinux (que requiere esto para
793 Las estructuras de datos que tienen visibilidad fuera del contexto de un
794 solo subproceso en el que son creadas y destruidas, siempre debe tener
797 que significa que absolutamente **tiene** para hacer referencia y contar
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
806 Tenga en cuenta que el bloqueo **no** reemplaza el recuento de referencia.
808 datos, mientras que la referencia y contar es una técnica de gestión de
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
840 Generalmente, las funciones en línea son preferibles a las macros que se
855 1) macros que afectan el flujo de control:
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:
878 3) macros con argumentos que se usan como valores l: FOO(x) = y; le van
881 4) olvidarse de la precedencia: las macros que definen constantes usando
891 locales en macros que se asemejan a funciones:
902 ret es un nombre común para una variable local -es menos probable que
906 gcc también cubre RTL, que se usa frecuentemente con lenguaje ensamblador
918 Los mensajes del kernel no tienen que terminar con un punto.
923 que debe usar para asegurarse de que los mensajes coincidan con el
925 dev_err(), dev_warn(), dev_info(), y así sucesivamente. Para mensajes que
932 diferente a la impresión de otros mensajes que no son de depuración.
933 Mientras que las otras funciones pr_XXX() se imprimen incondicionalmente,
934 pr_debug() no lo hace; se compila fuera por defecto, a menos que DEBUG sea
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
986 que no sirve de nada emitir un mensaje de fallo adicional cuando se
992 Parece haber una común percepción errónea de que gcc tiene una magica
994 Mientras que el uso de inlines puede ser apropiado (por ejemplo, como un
997 que a su vez ralentiza el sistema en su conjunto, debido a una mayor huella
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
1005 que se sabe que un parámetro es una constante en tiempo de compilación, y
1010 A menudo, la gente argumenta que agregar funciones en línea que son
1011 estáticas y se usan solo una vez, es siempre una victoria ya que no hay
1015 valor potencial de la pista que le dice a gcc que haga algo que habría
1022 lo más común es un valor que indica si la función tuvo éxito o ha fallado.
1044 al igual que todas las funciones publicas. Las funciones privadas
1045 (estáticas) no lo necesitan, pero es recomendado que lo hagan.
1050 de resultados. Los ejemplos típicos serían funciones que devuelven
1060 !! no se necesita construcción, lo que elimina una clase de errores.
1067 mejorar la legibilidad y, a menudo, es una mejor opción que 'int' para
1071 importantes, ya que su tamaño y la alineación varía según la arquitectura
1072 compilada. Las estructuras que son optimizadas para la alineación y el
1091 que debe usar, en lugar de programar explícitamente alguna variante de
1106 También hay macros min() y max() que realizan una verificación estricta de
1108 encabezado para ver qué más ya está definido y que no debe reproducir en su
1132 Vim interpreta los marcadores que se ven así:
1142 método mágico para que la sangría funcione correctamente.
1148 En el código específico de arquitectura, es posible que deba usar
1154 Considere escribir funciones auxiliares simples que envuelvan bits comunes
1156 variaciones. Recuerde que el ensamblador en línea puede usar parámetros C.
1162 Es posible que deba marcar su declaración asm como volátil, para evitar que
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,
1185 archivo de encabezado que defina funciones para usar en esos archivos .c,
1196 Si tiene una función o variable que puede potencialmente quedar sin usar en
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
1216 bloque, y verifique que sea correcto (sintaxis, tipos, símbolo, referencias,
1218 hace referencia a símbolos que no existirán si no se cumple la condición.
1233 En general, la decisión de romper el kernel pertenece al usuario, más que
1246 No agregue código nuevo que use cualquiera de las variantes BUG(), como
1260 común que una condición de advertencia dada, si ocurre, ocurra varias
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,
1279 Algunas palabras más sobre panic_on_warn: Recuerde que ``panic_on_warn`` es
1280 una opción disponible del kernel, y que muchos usuarios configuran esta
1281 opción. Esta es la razón por la que hay un artículo de "No haga WARN a la
1284 que quien habilita panic_on_warn, explícitamente pidió al kernel que
1286 para afrontar las consecuencias de un sistema que es algo más probable que
1293 en tiempo de compilación, que no tiene efecto en tiempo de ejecución.