Lines Matching +full:non +full:- +full:l
1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/coding-style.rst <codingstyle>`
12 il kernel Linux. Lo stile di codifica è molto personale e non voglio
14 dev'essere usato per qualsiasi cosa che io sia in grado di mantenere, e l'ho
19 di codifica GNU e di NON leggerla. Bruciatela, è un grande gesto simbolico.
24 ---------------
27 alcuni movimenti di eretici che vorrebbero l'indentazione a 4 (o perfino 2!)
29 pi-greco a 3.
31 Motivazione: l'idea dell'indentazione è di definire chiaramente dove un blocco
42 In breve, l'indentazione ad 8 caratteri rende più facile la lettura, e in
46 Al fine di facilitare l'indentazione del costrutto switch, si preferisce
51 .. code-block:: c
70 A meno che non vogliate nascondere qualcosa, non mettete più istruzioni sulla
73 .. code-block:: c
78 Non usate le virgole per evitare le parentesi:
80 .. code-block:: c
87 .. code-block:: c
94 Non mettete nemmeno più assegnamenti sulla stessa riga. Lo stile del kernel
99 spazi non vengono mai usati per l'indentazione, e l'esempio qui sopra è
102 Procuratevi un buon editor di testo e non lasciate spazi bianchi alla fine
107 -----------------------------------
115 pezzi più piccoli, a meno che eccedere le 80 colonne non aiuti ad
125 Tuttavia, non spezzettate mai le stringhe visibili agli utenti come i
130 ---------------------------------------------
134 dell'indentazione, non ci sono motivi tecnici sulla base dei quali scegliere
140 .. code-block:: c
146 Questo è valido per tutte le espressioni che non siano funzioni (if, switch,
149 .. code-block:: c
165 .. code-block:: c
175 sono comunque speciali (non potete annidarle in C).
179 espressione, in pratica ``while`` nell'espressione do-while, oppure ``else``
180 nell'espressione if-else, come questo:
182 .. code-block:: c
185 body of do-loop
190 .. code-block:: c
204 righe sul vostro schermo non sono una risorsa illimitata (pensate ad uno
208 Non usate inutilmente le graffe dove una singola espressione è sufficiente.
210 .. code-block:: c
217 .. code-block:: c
224 Questo non vale nel caso in cui solo un ramo dell'espressione if-else
228 .. code-block:: c
239 .. code-block:: c
251 (quasi tutte) le parole chiave. L'eccezioni più evidenti sono sizeof, typeof,
254 linguaggio non lo richiede; come ``sizeof info`` dopo aver dichiarato
261 ma non con sizeof, typeof, alignof, o __attribute__. Ad esempio,
263 .. code-block:: c
268 Non aggiungete spazi attorno (dentro) ad un'espressione fra parentesi. Questo
271 .. code-block:: c
277 puntatore, il posto suggerito per l'asterisco ``*`` è adiacente al nome della
278 variabile o della funzione, e non adiacente al nome del tipo. Esempi:
280 .. code-block:: c
290 = + - < > * / % | & ^ <= >= == != ? :
292 ma non mettete spazi dopo gli operatori unari::
294 & * + - ~ ! sizeof typeof alignof __attribute__ defined
296 nessuno spazio dopo l'operatore unario suffisso di incremento o decremento::
298 ++ --
300 nessuno spazio dopo l'operatore unario prefisso di incremento o decremento::
302 ++ --
305 ``->``.
307 Non lasciate spazi bianchi alla fine delle righe. Alcuni editor con
308 l'indentazione ``furba`` inseriranno gli spazi bianchi all'inizio di una nuova
310 immediatamente. Tuttavia, alcuni di questi stessi editor non rimuovono
311 questi spazi bianchi quando non scrivete nulla sulla nuova riga, ad esempio
321 -----------------
324 contrario dei programmatori Modula-2 o Pascal, i programmatori C non usano
327 non è una delle più difficili da capire.
336 qualcosa di simile, **non** dovreste chiamarla ``cntusr()``.
339 ungherese) è stupido - il compilatore conosce comunque il tipo e
344 Chiamarlo ``loop_counter`` non è produttivo, non ci sono possibilità che
345 ``i`` possa non essere capito. Analogamente, ``tmp`` può essere una qualsiasi
353 --------------------------------
355 Per favore non usate cose come ``vps_t``.
358 .. code-block:: c
365 .. code-block:: c
372 Non molto. Sono utili per:
375 scopo di **nascondere** cosa sia davvero l'oggetto).
381 Gli oggetti opachi e le ``funzioni accessorie`` non sono, di per se,
383 che davvero non c'è alcuna informazione portabile.
385 (b) i tipi chiaramente interi, dove l'astrazione **aiuta** ad evitare
393 Ancora - dev'esserci una **ragione** per farlo. Se qualcosa è
394 ``unsigned long``, non c'è alcun bisogno di avere:
409 tipi standard come ``uint32_t``, alcune persone ne obiettano l'uso.
412 con segno, identici ai tipi standard, sono permessi- tuttavia, non sono
417 In alcune strutture dati visibili dallo spazio utente non possiamo
418 richiedere l'uso dei tipi C99 e nemmeno i vari ``u32`` descritti prima.
423 non usare MAI MAI un typedef a meno che non rientri in una delle regole
427 modo ragionevole, non dovrebbero **mai** essere definite con un typedef.
430 -----------
439 lunga (ma semplice) sequenza di caso-istruzione, dove avete molte piccole cose
443 non particolarmente dotato del primo anno delle scuole superiori potrebbe
444 non capire cosa faccia la funzione, allora dovreste attenervi strettamente ai
450 Un'altra misura delle funzioni sono il numero di variabili locali. Non
451 dovrebbero eccedere le 5-10, oppure state sbagliando qualcosa. Ripensate la
461 .. code-block:: c
473 Nonostante questo non sia richiesto dal linguaggio C, in Linux viene preferito
477 Non usate la parola chiave ``extern`` con le dichiarazioni di funzione perché
478 rende le righe più lunghe e non è strettamente necessario.
480 …scrivete i prototipi di funzione mantenete `l'ordine degli elementi <https://lore.kernel.org/mm-co…
487 L'ordine suggerito per gli elementi di un prototipo di funzione è il seguente:
489 - classe d'archiviazione (in questo caso ``static __always_inline``. Da notare
492 - attributi della classe di archiviazione (in questo caso ``__init``, in altre
494 - il tipo di ritorno (in questo caso, ``void *``)
495 - attributi per il valore di ritorno (in questo caso, ``__must_check``)
496 - il nome della funzione (in questo caso, ``action``)
497 - i parametri della funzione(in questo caso,
500 - attributi dei parametri (in questo caso, ``__printf(4, 5)``)
501 - attributi per il comportamento della funzione (in questo caso, ``__malloc_``)
504 della funzione), il compilatore non permette di usare gli attributi per i
516 ------------------------------------------
518 Sebbene sia deprecata da molte persone, l'istruzione goto è impiegata di
521 L'istruzione goto diventa utile quando una funzione ha punti d'uscita multipli
522 e vanno eseguite alcune procedure di pulizia in comune. Se non è necessario
527 se la goto libera (free) un ``buffer``. Evitate l'uso di nomi GW-BASIC come
533 - i salti incondizionati sono più facili da capire e seguire
534 - l'annidamento si riduce
535 - si evita di dimenticare, per errore, di aggiornare un singolo punto d'uscita
536 - aiuta il compilatore ad ottimizzare il codice ridondante ;)
538 .. code-block:: c
547 return -ENOMEM;
565 .. code-block:: c
568 kfree(foo->bar);
576 .. code-block:: c
579 kfree(foo->bar);
589 -----------
596 Solitamente, i commenti devono dire COSA fa il codice, e non COME lo fa.
601 (o brutto), ma cercate di non esagerare. Invece, mettete i commenti in
606 formato kernel-doc. Per maggiori dettagli, leggete i file in
607 :ref::ref:`Documentation/translations/it_IT/doc-guide/ <it_doc_guide>` e in
608 ``script/kernel-doc``.
610 Lo stile preferito per i commenti più lunghi (multi-riga) è:
612 .. code-block:: c
615 * This is the preferred style for multi-line
620 * with beginning and ending almost-blank lines.
626 commento per spiegarne l'uso.
630 ---------------------------
635 i modi predefiniti non sono proprio allettanti (infatti, sono peggio che
636 premere tasti a caso - un numero infinito di scimmie che scrivono in
637 GNU emacs non faranno mai un buon programma).
643 .. code-block:: elisp
645 (defun c-lineup-arglist-tabs-only (ignored)
647 (let* ((anchor (c-langelem-pos c-syntactic-element))
648 (column (c-langelem-2nd-pos c-syntactic-element))
649 (offset (- (1+ column) anchor))
650 (steps (floor offset c-basic-offset)))
652 c-basic-offset)))
654 (dir-locals-set-class-variables
655 'linux-kernel
656 '((c-mode . (
657 (c-basic-offset . 8)
658 (c-label-minimum-indentation . 0)
659 (c-offsets-alist . (
660 (arglist-close . c-lineup-arglist-tabs-only)
661 (arglist-cont-nonempty .
662 (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only))
663 (arglist-intro . +)
664 (brace-list-intro . +)
665 (c . c-lineup-C-comments)
666 (case-label . 0)
667 (comment-intro . c-lineup-comment)
668 (cpp-define-intro . +)
669 (cpp-macro . -1000)
670 (cpp-macro-cont . +)
671 (defun-block-intro . +)
672 (else-clause . 0)
673 (func-decl-cont . +)
675 (inher-cont . c-lineup-multi-inher)
676 (knr-argdecl-intro . 0)
677 (label . -1000)
679 (statement-block-intro . +)
680 (statement-case-intro . +)
681 (statement-cont . +)
684 (indent-tabs-mode . t)
685 (show-trailing-whitespace . t)
688 (dir-locals-set-directory-class
689 (expand-file-name "~/src/linux-trees")
690 'linux-kernel)
693 si trovano nella cartella ``~/src/linux-trees``.
696 non tutto è perduto: usate ``indent``.
700 Tuttavia, non è così terribile, perché perfino i creatori di GNU indent
701 riconoscono l'autorità di K&R (le persone del progetto GNU non sono cattive,
703 ``-kr -i8`` (che significa ``K&R, 8 caratteri di indentazione``), o utilizzate
704 ``scripts/Lindent`` che indenterà usando l'ultimo stile.
708 Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione.
710 Da notare che potete utilizzare anche ``clang-format`` per aiutarvi con queste
717 :ref:`Documentation/translations/it_IT/dev-tools/clang-format.rst <it_clangformat>`.
720 configurazioni basilari come l'indentazione e la fine delle righe verranno
725 ----------------------------------
728 sorgenti, l'indentazione è un po' differente. Le linee dopo un ``config``
738 logging of avc messages output). Does not do system-call
751 il documento Documentation/kbuild/kconfig-language.rst
755 ------------------
759 avere un contatore di riferimenti. Nel kernel non esiste un
766 in parallelo - e non doversi preoccupare di una struttura dati che
770 Da notare che la sincronizzazione **non** si sostituisce al conteggio dei
773 della memoria. Solitamente servono entrambe le cose, e non vanno confuse fra
781 Un esempio di questo tipo di conteggio dei riferimenti multi-livello può
786 Ricordatevi: se un altro thread può trovare la vostra struttura dati, e non
790 ---------------------------
795 .. code-block:: c
808 blocco do - while:
810 .. code-block:: c
818 Le macro che sembrano funzioni con parametri non usati dovrebbero essere
821 .. code-block:: c
827 Per motivi storici, molti file usano ancora l'approccio "cast a (void)" per
828 valutare i parametri. Tuttavia, non è raccomandato. Le funzioni inline risolvono
830 variabili non utilizzate, e in genere per qualche motivo sono documentate
833 .. code-block:: c
845 .. code-block:: c
850 return -EBUGGERED; \
854 la funzione chiamante; non cercate di rompere il decodificatore interno di
859 .. code-block:: c
866 3) le macro con argomenti che sono utilizzati come l-values; questo potrebbe
874 .. code-block:: c
882 .. code-block:: c
891 ret è un nome comune per una variabile locale - __foo_ret difficilmente
895 di gcc copre anche l'RTL che viene usato frequentemente nel kernel per il
899 --------------------------------------
902 di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
903 l'uso incorretto di abbreviazioni come ``dont``: usate ``do not`` oppure
906 I messaggi del kernel non devono terminare con un punto fermo.
908 Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
914 dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad
916 eccetera. Quando tutto funziona correttamente, non dovrebbero esserci stampe,
917 per cui preferite dev_dbg/pr_debug a meno che non sia qualcosa di sbagliato
921 l'avete può essere d'enorme aiuto per risolvere problemi da remoto.
924 essa non viene compilata nella configurazione predefinita, a meno che
925 DEBUG o CONFIG_DYNAMIC_DEBUG non vengono impostati. Questo vale anche per
929 -DDEBUG nei corrispettivi Makefile, e in altri casi aggiungono #define DEBUG
935 ---------------------
940 :ref:`Documentation/translations/it_IT/core-api/memory-allocation.rst <it_memory_allocation>`
944 .. code-block:: c
950 puntatore cambia tipo ma il corrispondente sizeof non viene aggiornato.
958 .. code-block:: c
964 .. code-block:: c
972 a meno che non venga esplicitamente specificato __GFP_NOWARN. Quindi, nella
977 -------------------
980 opzione "rendimi più veloce" chiamata ``inline``. In alcuni casi l'uso di
982 capitolo 12), ma molto spesso non lo è. L'uso abbondante della parola chiave
991 static e utilizzare una sola volta è sempre una scelta vincente perché non
999 -------------------------------------------
1004 (-Exxx = fallimento, 0 = successo) oppure un booleano di successo
1005 (0 = fallimento, non-zero = successo).
1010 errori per conto nostro ... ma questo non c'è. Per evitare di imbattersi
1019 in caso di successo o -EBUSY in caso di fallimento. Allo stesso modo,
1025 (static) possono non seguire questa convenzione, ma è comunque raccomandato
1029 piuttosto che l'indicazione sul successo di tale computazione, non sono
1035 17) L'uso di bool
1036 -----------------
1041 falso (*false*). Quando si usa un tipo bool il costrutto !! non sarà più
1047 Per il valore di ritorno delle funzioni e per le variabili sullo stack, l'uso
1048 del tipo bool è sempre appropriato. L'uso di bool viene incoraggiato per
1052 Non usate bool se per voi sono importanti l'ordine delle righe di cache o
1053 la loro dimensione; la dimensione e l'allineamento cambia a seconda
1055 ottimizzate per l'allineamento o la dimensione non dovrebbero usare bool.
1057 Se una struttura ha molti valori true/false, considerate l'idea di raggrupparli
1068 18) Non reinventate le macro del kernel
1069 ---------------------------------------
1076 .. code-block:: c
1083 .. code-block:: c
1085 #define sizeof_field(t, f) (sizeof(((t*)0)->f))
1089 d'intestazione per scoprire cos'altro è stato definito che non dovreste
1093 -----------------------------------------------------------
1099 .. code-block:: c
1101 -*- mode: c -*-
1105 .. code-block:: c
1109 compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
1115 .. code-block:: c
1119 Non includete nessuna di queste cose nei file sorgenti. Le persone hanno le
1120 proprie configurazioni personali per l'editor, e i vostri sorgenti non
1124 funzionare bene l'indentazione.
1127 -------------------
1131 specifica della piattaforma. Non esitate a farlo quando è necessario.
1132 Comunque, non usatele gratuitamente quando il C può fare la stessa cosa.
1133 Potete e dovreste punzecchiare l'hardware in C quando è possibile.
1137 varianti. Ricordatevi che l' *inline assembly* può utilizzare i parametri C.
1139 Il codice assembler più corposo e non banale dovrebbe andare nei file .S,
1144 d'evitare che GCC lo rimuova quando pensa che non ci siano effetti collaterali.
1145 Non c'è sempre bisogno di farlo, e farlo quando non serve limita le
1151 al fine di allineare correttamente l'assembler che verrà generato:
1153 .. code-block:: c
1160 ---------------------------------
1162 Ovunque sia possibile, non usate le direttive condizionali del preprocessore
1167 compilatore non produrrà alcun codice per le funzioni stub, produrrà gli
1170 È preferibile non compilare intere funzioni piuttosto che porzioni d'esse o
1175 Se avete una variabile o funzione che potrebbe non essere usata in alcune
1185 .. code-block:: c
1191 Il compilatore valuterà la condizione come costante (constant-fold), e quindi
1193 non ne aumenterà il tempo di esecuzione. Tuttavia, questo permette al
1203 .. code-block:: c
1210 ------------------------
1215 ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
1219 Addison-Wesley, Inc., 1999.
1220 ISBN 0-201-61586-X.
1222 Manuali GNU - nei casi in cui sono compatibili con K&R e questo documento -
1227 URL: https://www.open-std.org/JTC1/SC22/WG14/