Lines Matching full:per
8 Stile del codice per il kernel Linux
11 Questo è un breve documento che descrive lo stile di codice preferito per
14 dev'essere usato per qualsiasi cosa che io sia in grado di mantenere, e l'ho
15 preferito anche per molte altre cose. Per favore, almeno tenete in
33 schermo per 20 ore a file, troverete molto più facile capire i livelli di
48 subordinati ``case``. In questo modo si evita una doppia indentazione per
78 Non usate le virgole per evitare le parentesi:
85 Invece, usate sempre le parentesi per racchiudere più istruzioni.
99 spazi non vengono mai usati per l'indentazione, e l'esempio qui sopra è
127 d'utilizzare grep per cercarle.
137 posizionare la parentesi graffa di apertura per ultima sulla riga, e quella
138 di chiusura per prima su una nuova riga, così:
146 Questo è valido per tutte le espressioni che non siano funzioni (if, switch,
147 for, while, do). Per esempio:
225 contiene una sola espressione; in quest'ultimo caso usate le graffe per
249 Lo stile del kernel Linux per quanto riguarda gli spazi, dipende
277 puntatore, il posto suggerito per l'asterisco ``*`` è adiacente al nome della
312 perché volete lasciare una riga vuota. Il risultato è che finirete per avere
316 e può opzionalmente rimuoverli per conto vostro; tuttavia, se state applicando
330 descrittivi per variabili globali sono un dovere. Chiamare una funzione
346 variabile che viene usata per salvare temporaneamente un valore.
355 Per favore non usate cose come ``vps_t``.
356 Usare il typedef per strutture e puntatori è uno **sbaglio**. Quando vedete:
372 Non molto. Sono utili per:
381 Gli oggetti opachi e le ``funzioni accessorie`` non sono, di per se,
382 una bella cosa. Il motivo per cui abbiamo cose come pte_t eccetera è
393 Ancora - dev'esserci una **ragione** per farlo. Se qualcosa è
408 Nonostante ci voglia poco tempo per abituare occhi e cervello all'uso dei
413 obbligatori per il nuovo codice.
440 per molti casi differenti, allora va bene avere funzioni più lunghe.
446 compilatore di renderle inline se credete che sia necessario per le
458 esportata, la macro **EXPORT** per questa funzione deve seguire immediatamente
474 perché è un modo semplice per aggiungere informazioni importanti per il
487 L'ordine suggerito per gli elementi di un prototipo di funzione è il seguente:
495 - attributi per il valore di ritorno (in questo caso, ``__must_check``)
501 - attributi per il comportamento della funzione (in questo caso, ``__malloc_``)
503 Notate che per la **definizione** di una funzione (il altre parole il corpo
504 della funzione), il compilatore non permette di usare gli attributi per i
531 I motivo per usare le goto sono:
535 - si evita di dimenticare, per errore, di aggiornare un singolo punto d'uscita
584 Idealmente, dovreste simulare condizioni d'errore per verificare i vostri
599 tornare al punto 6 per un momento. Potete mettere dei piccoli commenti per
605 Per favore, quando commentate una funzione dell'API del kernel usate il
606 formato kernel-doc. Per maggiori dettagli, leggete i file in
610 Lo stile preferito per i commenti più lunghi (multi-riga) è:
623 Per i file in net/ e in drivers/net/ lo stile preferito per i commenti
635 È anche importante commentare i dati, sia per i tipi base che per tipi
636 derivati. A questo scopo, dichiarate un dato per riga (niente virgole
637 per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo
638 commento per spiegarne l'uso.
646 codice C per conto vostro, e avete notato che sì, in effetti lo fa, ma che
652 sensati. Per fare quest'ultima cosa, potete appiccicare il codice che
704 Questo farà funzionare meglio emacs con lo stile del kernel per i file che
711 ed è per questo che dovete passargli alcune opzioni da riga di comando.
720 Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione.
722 Da notare che potete utilizzare anche ``clang-format`` per aiutarvi con queste
723 regole, per riformattare rapidamente ad automaticamente alcune parti del
724 vostro codice, e per revisionare interi file al fine di identificare errori
725 di stile, refusi e possibilmente anche delle migliorie. È anche utile per
726 ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire
728 Per maggiori dettagli, consultate il file
735 Per tutti i file di configurazione Kconfig* che si possono trovare nei
749 Le funzionalità davvero pericolose (per esempio il supporto alla scrittura
750 per certi filesystem) dovrebbero essere dichiarate chiaramente come tali
758 Per la documentazione completa sui file di configurazione, consultate
770 contatore di riferimenti per ogni cosa che usate.
776 o stava facendo altro per un attimo.
795 avete un contatore di riferimenti per essa, quasi certamente avete un baco.
852 ritorcervisi contro se qualcuno, per esempio, trasforma FOO in una funzione
876 ret è un nome comune per una variabile locale - __foo_ret difficilmente
880 di gcc copre anche l'RTL che viene usato frequentemente nel kernel per il
887 di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
893 Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
896 Ci sono alcune macro per la diagnostica in <linux/dev_printk.h> che dovreste
897 usare per assicurarvi che i messaggi vengano associati correttamente ai
899 dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad
904 l'avete può essere d'enorme aiuto per risolvere problemi da remoto.
908 DEBUG o CONFIG_DYNAMIC_DEBUG non vengono impostati. Questo vale anche per
909 dev_dbg() e in aggiunta VERBOSE_DEBUG per aggiungere i messaggi dev_vdbg().
914 incondizionatamente, per esempio perché siete già in una sezione di debug
922 Per maggiori informazioni, consultate la documentazione dell'API:
925 Il modo preferito per passare la dimensione di una struttura è il seguente:
939 Il modo preferito per assegnare un vettore è il seguente:
945 Il modo preferito per assegnare un vettore a zero è il seguente:
951 Entrambe verificano la condizione di overflow per la dimensione
964 inline è appropriato (per esempio in sostituzione delle macro, vedi
967 suo complesso più lento per via di una cache per le istruzioni della CPU più
968 grande e poi semplicemente perché ci sarà meno spazio disponibile per una
977 manutenzione del codice per rimuovere gli inline quando compare un secondo
990 Mischiare questi due tipi di rappresentazioni è un terreno fertile per
993 errori per conto nostro ... ma questo non c'è. Per evitare di imbattersi
1001 Per esempio, ``add work`` è un comando, e la funzione add_work() ritorna 0
1030 Per il valore di ritorno delle funzioni e per le variabili sullo stack, l'uso
1031 del tipo bool è sempre appropriato. L'uso di bool viene incoraggiato per
1035 Non usate bool se per voi sono importanti l'ordine delle righe di cache o
1037 dell'architettura per la quale è stato compilato. Le strutture che sono state
1038 ottimizzate per l'allineamento o la dimensione non dovrebbero usare bool.
1044 Come per gli argomenti delle funzioni, molti valori true/false possono essere
1046 un'alternativa molto più leggibile se si hanno valori costanti per true/false.
1056 Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
1072 d'intestazione per scoprire cos'altro è stato definito che non dovreste
1079 nei file sorgenti e indicati con dai marcatori speciali. Per esempio, emacs
1103 proprie configurazioni personali per l'editor, e i vostri sorgenti non
1104 dovrebbero sovrascrivergliele. Questo vale anche per i marcatori
1106 modalità su misura, oppure potrebbero avere qualche altra magia per far
1112 Nel codice specifico per un'architettura, potreste aver bisogno di codice
1113 *inline assembly* per interfacciarvi col processore o con una funzionalità
1124 per le funzioni assembler dovrebbero usare ``asmlinkage``.
1147 seguire. Invece, usate queste direttive nei file d'intestazione per definire
1150 compilatore non produrrà alcun codice per le funzioni stub, produrrà gli
1164 Nel codice, dov'è possibile, usate la macro IS_ENABLED per convertire i
1184 che termina. Per esempio:
1206 per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui
1209 WG14 è il gruppo internazionale di standardizzazione per il linguaggio C,