Lines Matching refs: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,
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.
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
471 perché è un modo semplice per aggiungere informazioni importanti per il
493 I motivo per usare le goto sono:
497 - si evita di dimenticare, per errore, di aggiornare un singolo punto d'uscita
546 Idealmente, dovreste simulare condizioni d'errore per verificare i vostri
561 tornare al punto 6 per un momento. Potete mettere dei piccoli commenti per
572 Lo stile preferito per i commenti più lunghi (multi-riga) è:
585 Per i file in net/ e in drivers/net/ lo stile preferito per i commenti
597 È anche importante commentare i dati, sia per i tipi base che per tipi
598 derivati. A questo scopo, dichiarate un dato per riga (niente virgole
599 per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo
600 commento per spiegarne l'uso.
608 codice C per conto vostro, e avete notato che sì, in effetti lo fa, ma che
666 Questo farà funzionare meglio emacs con lo stile del kernel per i file che
673 ed è per questo che dovete passargli alcune opzioni da riga di comando.
682 Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione.
684 Da notare che potete utilizzare anche ``clang-format`` per aiutarvi con queste
685 regole, per riformattare rapidamente ad automaticamente alcune parti del
686 vostro codice, e per revisionare interi file al fine di identificare errori
687 di stile, refusi e possibilmente anche delle migliorie. È anche utile per
688 ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire
711 Le funzionalità davvero pericolose (per esempio il supporto alla scrittura
712 per certi filesystem) dovrebbero essere dichiarate chiaramente come tali
732 contatore di riferimenti per ogni cosa che usate.
738 o stava facendo altro per un attimo.
757 avete un contatore di riferimenti per essa, quasi certamente avete un baco.
814 ritorcervisi contro se qualcuno, per esempio, trasforma FOO in una funzione
838 ret è un nome comune per una variabile locale - __foo_ret difficilmente
842 di gcc copre anche l'RTL che viene usato frequentemente nel kernel per il
849 di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
855 Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
858 Ci sono alcune macro per la diagnostica in <linux/device.h> che dovreste
859 usare per assicurarvi che i messaggi vengano associati correttamente ai
866 l'avete può essere d'enorme aiuto per risolvere problemi da remoto.
870 DEBUG o CONFIG_DYNAMIC_DEBUG non vengono impostati. Questo vale anche per
871 dev_dbg() e in aggiunta VERBOSE_DEBUG per aggiungere i messaggi dev_vdbg().
876 incondizionatamente, per esempio perché siete già in una sezione di debug
887 Il modo preferito per passare la dimensione di una struttura è il seguente:
901 Il modo preferito per assegnare un vettore è il seguente:
907 Il modo preferito per assegnare un vettore a zero è il seguente:
913 Entrambe verificano la condizione di overflow per la dimensione
926 inline è appropriato (per esempio in sostituzione delle macro, vedi
929 suo complesso più lento per via di una cache per le istruzioni della CPU più
930 grande e poi semplicemente perché ci sarà meno spazio disponibile per una
939 manutenzione del codice per rimuovere gli inline quando compare un secondo
952 Mischiare questi due tipi di rappresentazioni è un terreno fertile per
955 errori per conto nostro ... ma questo non c'è. Per evitare di imbattersi
992 Per il valore di ritorno delle funzioni e per le variabili sullo stack, l'uso
993 del tipo bool è sempre appropriato. L'uso di bool viene incoraggiato per
997 Non usate bool se per voi sono importanti l'ordine delle righe di cache o
999 dell'architettura per la quale è stato compilato. Le strutture che sono state
1000 ottimizzate per l'allineamento o la dimensione non dovrebbero usare bool.
1006 Come per gli argomenti delle funzioni, molti valori true/false possono essere
1008 un'alternativa molto più leggibile se si hanno valori costanti per true/false.
1034 d'intestazione per scoprire cos'altro è stato definito che non dovreste
1065 proprie configurazioni personali per l'editor, e i vostri sorgenti non
1066 dovrebbero sovrascrivergliele. Questo vale anche per i marcatori
1068 modalità su misura, oppure potrebbero avere qualche altra magia per far
1074 Nel codice specifico per un'architettura, potreste aver bisogno di codice
1075 *inline assembly* per interfacciarvi col processore o con una funzionalità
1086 per le funzioni assembler dovrebbero usare ``asmlinkage``.
1109 seguire. Invece, usate queste direttive nei file d'intestazione per definire
1112 compilatore non produrrà alcun codice per le funzioni stub, produrrà gli
1126 Nel codice, dov'è possibile, usate la macro IS_ENABLED per convertire i
1168 per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui
1171 WG14 è il gruppo internazionale di standardizzazione per il linguaggio C,