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 È anche importante commentare i dati, sia per i tipi base che per tipi
624 derivati.  A questo scopo, dichiarate un dato per riga (niente virgole
625 per una dichiarazione multipla).  Questo vi lascerà spazio per un piccolo
626 commento per spiegarne l'uso.
634 codice C per conto vostro, e avete notato che sì, in effetti lo fa, ma che
640 sensati.  Per fare quest'ultima cosa, potete appiccicare il codice che
692 Questo farà funzionare meglio emacs con lo stile del kernel per i file che
699 ed è per questo che dovete passargli alcune opzioni da riga di comando.
708 Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione.
710 Da notare che potete utilizzare anche ``clang-format`` per aiutarvi con queste
711 regole, per riformattare rapidamente ad automaticamente alcune parti del
712 vostro codice, e per revisionare interi file al fine di identificare errori
713 di stile, refusi e possibilmente anche delle migliorie. È anche utile per
714 ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire
716 Per maggiori dettagli, consultate il file
721 applicate automaticamente. Per maggiori informazioni consultate la pagina:
727 Per tutti i file di configurazione Kconfig* che si possono trovare nei
741 Le funzionalità davvero pericolose (per esempio il supporto alla scrittura
742 per certi filesystem) dovrebbero essere dichiarate chiaramente come tali
750 Per la documentazione completa sui file di configurazione, consultate
762 contatore di riferimenti per ogni cosa che usate.
768 o stava facendo altro per un attimo.
787 avete un contatore di riferimenti per essa, quasi certamente avete un baco.
819 sostituite da funzioni inline per evitare il problema.
827 Per motivi storici, molti file usano ancora l'approccio "cast a (void)" per
830 variabili non utilizzate, e in genere per qualche motivo sono documentate
867 ritorcervisi contro se qualcuno, per esempio, trasforma FOO in una funzione
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
902 di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
908 Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
911 Ci sono alcune macro per la diagnostica in <linux/dev_printk.h> che dovreste
912 usare per assicurarvi che i messaggi vengano associati correttamente ai
914 dev_warn(), dev_info(), e così via.  Per messaggi che non sono associati ad
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.
925 DEBUG o CONFIG_DYNAMIC_DEBUG non vengono impostati.  Questo vale anche per
926 dev_dbg() e in aggiunta VERBOSE_DEBUG per aggiungere i messaggi dev_vdbg().
931 incondizionatamente, per esempio perché siete già in una sezione di debug
939 Per maggiori informazioni, consultate la documentazione dell'API:
942 Il modo preferito per passare la dimensione di una struttura è il seguente:
956 Il modo preferito per assegnare un vettore è il seguente:
962 Il modo preferito per assegnare un vettore a zero è il seguente:
968 Entrambe verificano la condizione di overflow per la dimensione
981 inline è appropriato (per esempio in sostituzione delle macro, vedi
984 suo complesso più lento per via di una cache per le istruzioni della CPU più
985 grande e poi semplicemente perché ci sarà meno spazio disponibile per una
994 manutenzione del codice per rimuovere gli inline quando compare un secondo
1007 Mischiare questi due tipi di rappresentazioni è un terreno fertile per
1010 errori per conto nostro ... ma questo non c'è.  Per evitare di imbattersi
1018 Per esempio, ``add work`` è un comando, e la funzione add_work() ritorna 0
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
1054 dell'architettura per la quale è stato compilato.  Le strutture che sono state
1055 ottimizzate per l'allineamento o la dimensione non dovrebbero usare bool.
1061 Come per gli argomenti delle funzioni, molti valori true/false possono essere
1063 un'alternativa molto più leggibile se si hanno valori costanti per true/false.
1073 Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
1089 d'intestazione per scoprire cos'altro è stato definito che non dovreste
1096 nei file sorgenti e indicati con dai marcatori speciali.  Per esempio, emacs
1120 proprie configurazioni personali per l'editor, e i vostri sorgenti non
1121 dovrebbero sovrascrivergliele.  Questo vale anche per i marcatori
1123 modalità su misura, oppure potrebbero avere qualche altra magia per far
1129 Nel codice specifico per un'architettura, potreste aver bisogno di codice
1130 *inline assembly* per interfacciarvi col processore o con una funzionalità
1141 per le funzioni assembler dovrebbero usare ``asmlinkage``.
1164 seguire.  Invece, usate queste direttive nei file d'intestazione per definire
1167 compilatore non produrrà alcun codice per le funzioni stub, produrrà gli
1181 Nel codice, dov'è possibile, usate la macro IS_ENABLED per convertire i
1201 che termina.  Per esempio:
1223 per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui
1226 WG14 è il gruppo internazionale di standardizzazione per il linguaggio C,