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
82 spazi non vengono mai usati per l'indentazione, e l'esempio qui sopra è
104 printk, questo perché inibireste la possibilità d'utilizzare grep per cercarle.
114 posizionare la parentesi graffa di apertura per ultima sulla riga, e quella
115 di chiusura per prima su una nuova riga, così:
123 Questo è valido per tutte le espressioni che non siano funzioni (if, switch,
124 for, while, do). Per esempio:
202 contiene una sola espressione; in quest'ultimo caso usate le graffe per
226 Lo stile del kernel Linux per quanto riguarda gli spazi, dipende
254 puntatore, il posto suggerito per l'asterisco ``*`` è adiacente al nome della
289 perché volete lasciare una riga vuota. Il risultato è che finirete per avere
293 e può opzionalmente rimuoverli per conto vostro; tuttavia, se state applicando
307 descrittivi per variabili globali sono un dovere. Chiamare una funzione
324 variabile che viene usata per salvare temporaneamente un valore.
333 Per favore non usate cose come ``vps_t``.
334 Usare il typedef per strutture e puntatori è uno **sbaglio**. Quando vedete:
350 Non molto. Sono utili per:
359 Gli oggetti opachi e le ``funzioni accessorie`` non sono, di per se,
360 una bella cosa. Il motivo per cui abbiamo cose come pte_t eccetera è
371 Ancora - dev'esserci una **ragione** per farlo. Se qualcosa è
386 Nonostante ci voglia poco tempo per abituare occhi e cervello all'uso dei
391 obbligatori per il nuovo codice.
418 per molti casi differenti, allora va bene avere funzioni più lunghe.
424 compilatore di renderle inline se credete che sia necessario per le
436 esportata, la macro **EXPORT** per questa funzione deve seguire immediatamente
449 perché è un modo semplice per aggiungere informazioni importanti per il
471 I motivo per usare le goto sono:
475 - si evita di dimenticare, per errore, di aggiornare un singolo punto d'uscita
524 Idealmente, dovreste simulare condizioni d'errore per verificare i vostri
539 tornare al punto 6 per un momento. Potete mettere dei piccoli commenti per
545 Per favore, quando commentate una funzione dell'API del kernel usate il
546 formato kernel-doc. Per maggiori dettagli, leggete i file in
550 Lo stile preferito per i commenti più lunghi (multi-riga) è:
563 Per i file in net/ e in drivers/net/ lo stile preferito per i commenti
575 È anche importante commentare i dati, sia per i tipi base che per tipi
576 derivati. A questo scopo, dichiarate un dato per riga (niente virgole
577 per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo
578 commento per spiegarne l'uso.
586 codice C per conto vostro, e avete notato che sì, in effetti lo fa, ma che
592 sensati. Per fare quest'ultima cosa, potete appiccicare il codice che
644 Questo farà funzionare meglio emacs con lo stile del kernel per i file che
651 ed è per questo che dovete passargli alcune opzioni da riga di comando.
660 Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione.
662 Da notare che potete utilizzare anche ``clang-format`` per aiutarvi con queste
663 regole, per riformattare rapidamente ad automaticamente alcune parti del
664 vostro codice, e per revisionare interi file al fine di identificare errori
665 di stile, refusi e possibilmente anche delle migliorie. È anche utile per
666 ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire
668 Per maggiori dettagli, consultate il file
675 Per tutti i file di configurazione Kconfig* che si possono trovare nei
689 Le funzionalità davvero pericolose (per esempio il supporto alla scrittura
690 per certi filesystem) dovrebbero essere dichiarate chiaramente come tali
698 Per la documentazione completa sui file di configurazione, consultate
710 contatore di riferimenti per ogni cosa che usate.
716 o stava facendo altro per un attimo.
735 avete un contatore di riferimenti per essa, quasi certamente avete un baco.
792 ritorcervisi contro se qualcuno, per esempio, trasforma FOO in una funzione
816 ret è un nome comune per una variabile locale - __foo_ret difficilmente
820 di gcc copre anche l'RTL che viene usato frequentemente nel kernel per il
827 di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
833 Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
836 Ci sono alcune macro per la diagnostica in <linux/device.h> che dovreste
837 usare per assicurarvi che i messaggi vengano associati correttamente ai
839 dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad
844 l'avete può essere d'enorme aiuto per risolvere problemi da remoto.
848 DEBUG o CONFIG_DYNAMIC_DEBUG non vengono impostati. Questo vale anche per
849 dev_dbg() e in aggiunta VERBOSE_DEBUG per aggiungere i messaggi dev_vdbg().
854 incondizionatamente, per esempio perché siete già in una sezione di debug
862 Per maggiori informazioni, consultate la documentazione dell'API:
865 Il modo preferito per passare la dimensione di una struttura è il seguente:
879 Il modo preferito per assegnare un vettore è il seguente:
885 Il modo preferito per assegnare un vettore a zero è il seguente:
891 Entrambe verificano la condizione di overflow per la dimensione
904 inline è appropriato (per esempio in sostituzione delle macro, vedi
907 suo complesso più lento per via di una cache per le istruzioni della CPU più
908 grande e poi semplicemente perché ci sarà meno spazio disponibile per una
917 manutenzione del codice per rimuovere gli inline quando compare un secondo
930 Mischiare questi due tipi di rappresentazioni è un terreno fertile per
933 errori per conto nostro ... ma questo non c'è. Per evitare di imbattersi
941 Per esempio, ``add work`` è un comando, e la funzione add_work() ritorna 0
970 Per il valore di ritorno delle funzioni e per le variabili sullo stack, l'uso
971 del tipo bool è sempre appropriato. L'uso di bool viene incoraggiato per
975 Non usate bool se per voi sono importanti l'ordine delle righe di cache o
977 dell'architettura per la quale è stato compilato. Le strutture che sono state
978 ottimizzate per l'allineamento o la dimensione non dovrebbero usare bool.
984 Come per gli argomenti delle funzioni, molti valori true/false possono essere
986 un'alternativa molto più leggibile se si hanno valori costanti per true/false.
996 Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
1012 d'intestazione per scoprire cos'altro è stato definito che non dovreste
1019 nei file sorgenti e indicati con dai marcatori speciali. Per esempio, emacs
1043 proprie configurazioni personali per l'editor, e i vostri sorgenti non
1044 dovrebbero sovrascrivergliele. Questo vale anche per i marcatori
1046 modalità su misura, oppure potrebbero avere qualche altra magia per far
1052 Nel codice specifico per un'architettura, potreste aver bisogno di codice
1053 *inline assembly* per interfacciarvi col processore o con una funzionalità
1064 per le funzioni assembler dovrebbero usare ``asmlinkage``.
1087 seguire. Invece, usate queste direttive nei file d'intestazione per definire
1090 compilatore non produrrà alcun codice per le funzioni stub, produrrà gli
1104 Nel codice, dov'è possibile, usate la macro IS_ENABLED per convertire i
1124 che termina. Per esempio:
1146 per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui
1149 WG14 è il gruppo internazionale di standardizzazione per il linguaggio C,