Lines Matching full:no
12 del kernel Linux. El estilo de código es muy personal y no **forzaré** mi
18 GNU, y NO leerlo. Quémelos, es un gran gesto simbólico.
70 No ponga varias declaraciones en una sola línea a menos que tenga algo que
78 No use comas para evitar el uso de llaves:
102 Consiga un editor decente y no deje espacios en blanco al final de las
114 que exceder las 80 columnas aumente significativamente la legibilidad y no
144 Esto se aplica a todos los bloques de declaraciones que no son funciones
173 especiales de todos modos (no puede anidarlas en C).
202 como el suministro de nuevas líneas en su pantalla no es un recurso
206 No use llaves innecesariamente donde una sola declaración sea suficiente.
222 Esto no aplica si solo una rama de una declaración condicional es una sola
250 generalmente se usan con paréntesis en Linux, aunque no son requeridos en
258 pero no con sizeof, typeof, alignof, o __attribute__. Por ejemplo,
265 No agregue espacios alrededor (dentro) de expresiones entre paréntesis.
275 función y no junto al nombre del tipo. Ejemplos:
301 No deje espacios en blanco al final de las líneas. Algunos editores con
305 editores no eliminan los espacios en blanco si finalmente no termina
321 los programadores de C no usan nombres cuquis como
323 variable ``tmp``, que es mucho más fácil de escribir, y no es mas difícil
333 ``contar_usuarios_activos()`` o similar, **no** debe llamarlo ``cntusr()``.
341 llamarse ``i``. Llamarlo ``loop_counter`` no es productivo, si no hay
373 Por favor no use cosas como ``vps_t``.
390 Mucha gente piensa que los typedefs ``ayudan a la legibilidad``. No. Son
401 La opacidad y las ``funciones de acceso`` no son buenas por sí
415 ``unsigned long``, entonces no hay razón para hacerlo
435 permitidos, aunque no son obligatorios en el nuevo código de su
443 En ciertas estructuras que son visibles para el espacio de usuario, no
469 primer año de secundaria menos que dotado podría no comprender de qué se
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
502 No utilice la palabra clave ``extern`` con declaraciones de función ya que
503 esto hace las líneas más largas y no es estrictamente necesario.
529 real de la función), el compilador no permite atributos de parámetros de
550 Si no se necesita limpieza, entonces simplemente haga return directamente.
563 - errores al no actualizar los puntos de salida individuales al hacer
625 Generalmente, desea que sus comentarios digan QUÉ hace su código, no CÓMO.
660 * pero no hay una línea inicial casi en blanco.
734 Pero incluso si no logra que emacs realice un formateo correcto, no todo
739 opciones de línea de comando. Sin embargo, eso no es tan malo, porque
741 de GNU no es mala, solo están gravemente equivocados en este asunto), por
748 manual. Pero recuerde: ``indent`` no es la solución para una mala
774 registro de salida de mensajes avc). No hace auditoría de llamadas al
795 contadores de referencia. En el kernel, la recolección de basura no existe
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.
809 memoria. Por lo general, ambos son necesarios, y no deben confundirse entre
822 Recuerde: si otro hilo puede encontrar su estructura de datos y usted no
866 función de ``llamada``; no rompa los analizadores internos de aquellos que
914 impresión. No utilice contracciones incorrectas como ``dont``; use
918 Los mensajes del kernel no tienen que terminar con un punto.
920 Imprimir números entre paréntesis (%d) no agrega valor y debe evitarse.
926 no están asociados con un dispositivo particular, <linux/printk.h> define
932 diferente a la impresión de otros mensajes que no son de depuración.
934 pr_debug() no lo hace; se compila fuera por defecto, a menos que DEBUG sea
963 se pasa a un asignador de memoria no.
986 que no sirve de nada emitir un mensaje de fallo adicional cuando se
995 medio para reemplazar macros, consulte el Capítulo 12), muy a menudo no lo
1003 Una razonable regla general es no poner funciones inline que tengan más de
1011 estáticas y se usan solo una vez, es siempre una victoria ya que no hay
1030 errores por nosotros... pero no lo hace. Para ayudar a prevenir tales
1041 dispositivo coincidente o 0 si no es así.
1045 (estáticas) no lo necesitan, pero es recomendado que lo hagan.
1048 lugar de una indicación de si el cómputo tuvo éxito, no están sujetas a
1060 !! no se necesita construcción, lo que elimina una clase de errores.
1070 No use bool si el diseño de la línea de caché o el tamaño del valor son
1073 tamaño no debe usar bool.
1087 18) No reinvente las macros del kernel
1108 encabezado para ver qué más ya está definido y que no debe reproducir en su
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
1150 plataforma. No dude en hacerlo cuando sea necesario. Sin embargo, no use
1158 Las funciones de ensamblador grandes y no triviales deben ir en archivos .S,
1163 GCC la elimine si GCC no nota ningún efecto secundario. No siempre es
1182 Siempre que sea posible, no use condicionales de preprocesador (#if,
1213 excluirá el bloque de código al igual que con un #ifdef, por lo que esto no
1218 hace referencia a símbolos que no existirán si no se cumple la condición.
1220 Al final de cualquier bloque #if o #ifdef no trivial (más de unas pocas
1230 22) No rompa el kernel
1241 durante el arranque y no puede continuar.
1246 No agregue código nuevo que use cualquiera de las variantes BUG(), como
1249 El código de recuperación no es requerido si no hay una forma razonable de
1252 "Soy demasiado perezoso para tener en cuenta los errores" no es una excusa
1265 No haga WARN a la ligera
1269 suceder. Las macros WARN*() no deben usarse para nada que se espera que
1270 suceda durante un funcionamiento normal. No hay "checkeos" previos o
1271 posteriores a la condición, por ejemplo. De nuevo: WARN*() no debe usarse
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
1293 en tiempo de compilación, que no tiene efecto en tiempo de ejecución.