1.. include:: ../disclaimer-ita.rst 2 3:Original: :ref:`Documentation/process/coding-style.rst <codingstyle>` 4:Translator: Federico Vaga <federico.vaga@vaga.pv.it> 5 6.. _it_codingstyle: 7 8Stile del codice per il kernel Linux 9==================================== 10 11Questo è un breve documento che descrive lo stile di codice preferito per 12il kernel Linux. Lo stile di codifica è molto personale e non voglio 13**forzare** nessuno ad accettare il mio, ma questo stile è quello che 14dev'essere usato per qualsiasi cosa che io sia in grado di mantenere, e l'ho 15preferito anche per molte altre cose. Per favore, almeno tenete in 16considerazione le osservazioni espresse qui. 17 18La prima cosa che suggerisco è quella di stamparsi una copia degli standard 19di codifica GNU e di NON leggerla. Bruciatela, è un grande gesto simbolico. 20 21Comunque, ecco i punti: 22 231) Indentazione 24--------------- 25 26La tabulazione (tab) è di 8 caratteri e così anche le indentazioni. Ci sono 27alcuni movimenti di eretici che vorrebbero l'indentazione a 4 (o perfino 2!) 28caratteri di profondità, che è simile al tentativo di definire il valore del 29pi-greco a 3. 30 31Motivazione: l'idea dell'indentazione è di definire chiaramente dove un blocco 32di controllo inizia e finisce. Specialmente quando siete rimasti a guardare lo 33schermo per 20 ore a file, troverete molto più facile capire i livelli di 34indentazione se questi sono larghi. 35 36Ora, alcuni rivendicano che un'indentazione da 8 caratteri sposta il codice 37troppo a destra e che quindi rende difficile la lettura su schermi a 80 38caratteri. La risposta a questa affermazione è che se vi servono più di 3 39livelli di indentazione, siete comunque fregati e dovreste correggere il vostro 40programma. 41 42In breve, l'indentazione ad 8 caratteri rende più facile la lettura, e in 43aggiunta vi avvisa quando state annidando troppo le vostre funzioni. 44Tenete ben a mente questo avviso. 45 46Al fine di facilitare l'indentazione del costrutto switch, si preferisce 47allineare sulla stessa colonna la parola chiave ``switch`` e i suoi 48subordinati ``case``. In questo modo si evita una doppia indentazione per 49i ``case``. Un esempio.: 50 51.. code-block:: c 52 53 switch (suffix) { 54 case 'G': 55 case 'g': 56 mem <<= 30; 57 break; 58 case 'M': 59 case 'm': 60 mem <<= 20; 61 break; 62 case 'K': 63 case 'k': 64 mem <<= 10; 65 fallthrough; 66 default: 67 break; 68 } 69 70A meno che non vogliate nascondere qualcosa, non mettete più istruzioni sulla 71stessa riga: 72 73.. code-block:: c 74 75 if (condition) do_this; 76 do_something_everytime; 77 78Non usate le virgole per evitare le parentesi: 79 80.. code-block:: c 81 82 if (condition) 83 do_this(), do_that(); 84 85Invece, usate sempre le parentesi per racchiudere più istruzioni. 86 87.. code-block:: c 88 89 if (condition) { 90 do_this(); 91 do_that(); 92 } 93 94Non mettete nemmeno più assegnamenti sulla stessa riga. Lo stile del kernel 95è ultrasemplice. Evitate espressioni intricate. 96 97 98Al di fuori dei commenti, della documentazione ed escludendo i Kconfig, gli 99spazi non vengono mai usati per l'indentazione, e l'esempio qui sopra è 100volutamente errato. 101 102Procuratevi un buon editor di testo e non lasciate spazi bianchi alla fine 103delle righe. 104 105 1062) Spezzare righe lunghe e stringhe 107----------------------------------- 108 109Lo stile del codice riguarda la leggibilità e la manutenibilità utilizzando 110strumenti comuni. 111 112Come limite di riga si preferiscono le 80 colonne. 113 114Espressioni più lunghe di 80 colonne dovrebbero essere spezzettate in 115pezzi più piccoli, a meno che eccedere le 80 colonne non aiuti ad 116aumentare la leggibilità senza nascondere informazioni. 117 118I nuovi pezzi derivati sono sostanzialmente più corti degli originali 119e vengono posizionati più a destra. Uno stile molto comune è quello di 120allineare i nuovi pezzi alla parentesi aperta di una funzione. 121 122Lo stesso si applica, nei file d'intestazione, alle funzioni con una 123lista di argomenti molto lunga. 124 125Tuttavia, non spezzettate mai le stringhe visibili agli utenti come i 126messaggi di printk, questo perché inibireste la possibilità 127d'utilizzare grep per cercarle. 128 1293) Posizionamento di parentesi graffe e spazi 130--------------------------------------------- 131 132Un altro problema che s'affronta sempre quando si parla di stile in C è 133il posizionamento delle parentesi graffe. Al contrario della dimensione 134dell'indentazione, non ci sono motivi tecnici sulla base dei quali scegliere 135una strategia di posizionamento o un'altra; ma il modo qui preferito, 136come mostratoci dai profeti Kernighan e Ritchie, è quello di 137posizionare la parentesi graffa di apertura per ultima sulla riga, e quella 138di chiusura per prima su una nuova riga, così: 139 140.. code-block:: c 141 142 if (x is true) { 143 we do y 144 } 145 146Questo è valido per tutte le espressioni che non siano funzioni (if, switch, 147for, while, do). Per esempio: 148 149.. code-block:: c 150 151 switch (action) { 152 case KOBJ_ADD: 153 return "add"; 154 case KOBJ_REMOVE: 155 return "remove"; 156 case KOBJ_CHANGE: 157 return "change"; 158 default: 159 return NULL; 160 } 161 162Tuttavia, c'è il caso speciale, le funzioni: queste hanno la parentesi graffa 163di apertura all'inizio della riga successiva, quindi: 164 165.. code-block:: c 166 167 int function(int x) 168 { 169 body of function 170 } 171 172Eretici da tutto il mondo affermano che questa incoerenza è ... 173insomma ... incoerente, ma tutte le persone ragionevoli sanno che (a) 174K&R hanno **ragione** e (b) K&R hanno ragione. A parte questo, le funzioni 175sono comunque speciali (non potete annidarle in C). 176 177Notate che la graffa di chiusura è da sola su una riga propria, ad 178**eccezione** di quei casi dove è seguita dalla continuazione della stessa 179espressione, in pratica ``while`` nell'espressione do-while, oppure ``else`` 180nell'espressione if-else, come questo: 181 182.. code-block:: c 183 184 do { 185 body of do-loop 186 } while (condition); 187 188e 189 190.. code-block:: c 191 192 if (x == y) { 193 .. 194 } else if (x > y) { 195 ... 196 } else { 197 .... 198 } 199 200Motivazione: K&R. 201 202Inoltre, notate che questo posizionamento delle graffe minimizza il numero 203di righe vuote senza perdere di leggibilità. In questo modo, dato che le 204righe sul vostro schermo non sono una risorsa illimitata (pensate ad uno 205terminale con 25 righe), avrete delle righe vuote da riempire con dei 206commenti. 207 208Non usate inutilmente le graffe dove una singola espressione è sufficiente. 209 210.. code-block:: c 211 212 if (condition) 213 action(); 214 215e 216 217.. code-block:: none 218 219 if (condition) 220 do_this(); 221 else 222 do_that(); 223 224Questo non vale nel caso in cui solo un ramo dell'espressione if-else 225contiene una sola espressione; in quest'ultimo caso usate le graffe per 226entrambe i rami: 227 228.. code-block:: c 229 230 if (condition) { 231 do_this(); 232 do_that(); 233 } else { 234 otherwise(); 235 } 236 237Inoltre, usate le graffe se un ciclo contiene più di una semplice istruzione: 238 239.. code-block:: c 240 241 while (condition) { 242 if (test) 243 do_something(); 244 } 245 2463.1) Spazi 247********** 248 249Lo stile del kernel Linux per quanto riguarda gli spazi, dipende 250(principalmente) dalle funzioni e dalle parole chiave. Usate una spazio dopo 251(quasi tutte) le parole chiave. L'eccezioni più evidenti sono sizeof, typeof, 252alignof, e __attribute__, il cui aspetto è molto simile a quello delle 253funzioni (e in Linux, solitamente, sono usate con le parentesi, anche se il 254linguaggio non lo richiede; come ``sizeof info`` dopo aver dichiarato 255``struct fileinfo info``). 256 257Quindi utilizzate uno spazio dopo le seguenti parole chiave:: 258 259 if, switch, case, for, do, while 260 261ma non con sizeof, typeof, alignof, o __attribute__. Ad esempio, 262 263.. code-block:: c 264 265 266 s = sizeof(struct file); 267 268Non aggiungete spazi attorno (dentro) ad un'espressione fra parentesi. Questo 269esempio è **brutto**: 270 271.. code-block:: c 272 273 274 s = sizeof( struct file ); 275 276Quando dichiarate un puntatore ad una variabile o una funzione che ritorna un 277puntatore, il posto suggerito per l'asterisco ``*`` è adiacente al nome della 278variabile o della funzione, e non adiacente al nome del tipo. Esempi: 279 280.. code-block:: c 281 282 283 char *linux_banner; 284 unsigned long long memparse(char *ptr, char **retptr); 285 char *match_strdup(substring_t *s); 286 287Usate uno spazio attorno (da ogni parte) alla maggior parte degli operatori 288binari o ternari, come i seguenti:: 289 290 = + - < > * / % | & ^ <= >= == != ? : 291 292ma non mettete spazi dopo gli operatori unari:: 293 294 & * + - ~ ! sizeof typeof alignof __attribute__ defined 295 296nessuno spazio dopo l'operatore unario suffisso di incremento o decremento:: 297 298 ++ -- 299 300nessuno spazio dopo l'operatore unario prefisso di incremento o decremento:: 301 302 ++ -- 303 304e nessuno spazio attorno agli operatori dei membri di una struttura ``.`` e 305``->``. 306 307Non lasciate spazi bianchi alla fine delle righe. Alcuni editor con 308l'indentazione ``furba`` inseriranno gli spazi bianchi all'inizio di una nuova 309riga in modo appropriato, quindi potrete scrivere la riga di codice successiva 310immediatamente. Tuttavia, alcuni di questi stessi editor non rimuovono 311questi spazi bianchi quando non scrivete nulla sulla nuova riga, ad esempio 312perché volete lasciare una riga vuota. Il risultato è che finirete per avere 313delle righe che contengono spazi bianchi in coda. 314 315Git vi avviserà delle modifiche che aggiungono questi spazi vuoti di fine riga, 316e può opzionalmente rimuoverli per conto vostro; tuttavia, se state applicando 317una serie di modifiche, questo potrebbe far fallire delle modifiche successive 318perché il contesto delle righe verrà cambiato. 319 3204) Assegnare nomi 321----------------- 322 323C è un linguaggio spartano, e così dovrebbero esserlo i vostri nomi. Al 324contrario dei programmatori Modula-2 o Pascal, i programmatori C non usano 325nomi graziosi come ThisVariableIsATemporaryCounter. Un programmatore C 326chiamerebbe questa variabile ``tmp``, che è molto più facile da scrivere e 327non è una delle più difficili da capire. 328 329TUTTAVIA, nonostante i nomi con notazione mista siano da condannare, i nomi 330descrittivi per variabili globali sono un dovere. Chiamare una funzione 331globale ``pippo`` è un insulto. 332 333Le variabili GLOBALI (da usare solo se vi servono **davvero**) devono avere 334dei nomi descrittivi, così come le funzioni globali. Se avete una funzione 335che conta gli utenti attivi, dovreste chiamarla ``count_active_users()`` o 336qualcosa di simile, **non** dovreste chiamarla ``cntusr()``. 337 338Codificare il tipo di funzione nel suo nome (quella cosa chiamata notazione 339ungherese) è stupido - il compilatore conosce comunque il tipo e 340può verificarli, e inoltre confonde i programmatori. 341 342Le variabili LOCALI dovrebbero avere nomi corti, e significativi. Se avete 343un qualsiasi contatore di ciclo, probabilmente sarà chiamato ``i``. 344Chiamarlo ``loop_counter`` non è produttivo, non ci sono possibilità che 345``i`` possa non essere capito. Analogamente, ``tmp`` può essere una qualsiasi 346variabile che viene usata per salvare temporaneamente un valore. 347 348Se avete paura di fare casino coi nomi delle vostre variabili locali, allora 349avete un altro problema che è chiamato sindrome dello squilibrio dell'ormone 350della crescita delle funzioni. Vedere il capitolo 6 (funzioni). 351 3525) Definizione di tipi (typedef) 353-------------------------------- 354 355Per favore non usate cose come ``vps_t``. 356Usare il typedef per strutture e puntatori è uno **sbaglio**. Quando vedete: 357 358.. code-block:: c 359 360 vps_t a; 361 362nei sorgenti, cosa significa? 363Se, invece, dicesse: 364 365.. code-block:: c 366 367 struct virtual_container *a; 368 369potreste dire cos'è effettivamente ``a``. 370 371Molte persone pensano che la definizione dei tipi ``migliori la leggibilità``. 372Non molto. Sono utili per: 373 374 (a) gli oggetti completamente opachi (dove typedef viene proprio usato allo 375 scopo di **nascondere** cosa sia davvero l'oggetto). 376 377 Esempio: ``pte_t`` eccetera sono oggetti opachi che potete usare solamente 378 con le loro funzioni accessorie. 379 380 .. note:: 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 è 383 che davvero non c'è alcuna informazione portabile. 384 385 (b) i tipi chiaramente interi, dove l'astrazione **aiuta** ad evitare 386 confusione sul fatto che siano ``int`` oppure ``long``. 387 388 u8/u16/u32 sono typedef perfettamente accettabili, anche se ricadono 389 nella categoria (d) piuttosto che in questa. 390 391 .. note:: 392 393 Ancora - dev'esserci una **ragione** per farlo. Se qualcosa è 394 ``unsigned long``, non c'è alcun bisogno di avere: 395 396 typedef unsigned long myfalgs_t; 397 398 ma se ci sono chiare circostanze in cui potrebbe essere ``unsigned int`` 399 e in altre configurazioni ``unsigned long``, allora certamente typedef 400 è una buona scelta. 401 402 (c) quando di rado create letteralmente dei **nuovi** tipi su cui effettuare 403 verifiche. 404 405 (d) circostanze eccezionali, in cui si definiscono nuovi tipi identici a 406 quelli definiti dallo standard C99. 407 408 Nonostante ci voglia poco tempo per abituare occhi e cervello all'uso dei 409 tipi standard come ``uint32_t``, alcune persone ne obiettano l'uso. 410 411 Perciò, i tipi specifici di Linux ``u8/u16/u32/u64`` e i loro equivalenti 412 con segno, identici ai tipi standard, sono permessi- tuttavia, non sono 413 obbligatori per il nuovo codice. 414 415 (e) i tipi sicuri nella spazio utente. 416 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. 419 Perciò, utilizziamo __u32 e tipi simili in tutte le strutture dati 420 condivise con lo spazio utente. 421 422Magari ci sono altri casi validi, ma la regola di base dovrebbe essere di 423non usare MAI MAI un typedef a meno che non rientri in una delle regole 424descritte qui. 425 426In generale, un puntatore, o una struttura a cui si ha accesso diretto in 427modo ragionevole, non dovrebbero **mai** essere definite con un typedef. 428 4296) Funzioni 430----------- 431 432Le funzioni dovrebbero essere brevi e carine, e fare una cosa sola. Dovrebbero 433occupare uno o due schermi di testo (come tutti sappiamo, la dimensione 434di uno schermo secondo ISO/ANSI è di 80x24), e fare una cosa sola e bene. 435 436La massima lunghezza di una funziona è inversamente proporzionale alla sua 437complessità e al livello di indentazione di quella funzione. Quindi, se avete 438una funzione che è concettualmente semplice ma che è implementata come un 439lunga (ma semplice) sequenza di caso-istruzione, dove avete molte piccole cose 440per molti casi differenti, allora va bene avere funzioni più lunghe. 441 442Comunque, se avete una funzione complessa e sospettate che uno studente 443non particolarmente dotato del primo anno delle scuole superiori potrebbe 444non capire cosa faccia la funzione, allora dovreste attenervi strettamente ai 445limiti. Usate funzioni di supporto con nomi descrittivi (potete chiedere al 446compilatore di renderle inline se credete che sia necessario per le 447prestazioni, e probabilmente farà un lavoro migliore di quanto avreste potuto 448fare voi). 449 450Un'altra misura delle funzioni sono il numero di variabili locali. Non 451dovrebbero eccedere le 5-10, oppure state sbagliando qualcosa. Ripensate la 452funzione, e dividetela in pezzettini. Generalmente, un cervello umano può 453seguire facilmente circa 7 cose diverse, di più lo confonderebbe. Lo sai 454d'essere brillante, ma magari vorresti riuscire a capire cos'avevi fatto due 455settimane prima. 456 457Nei file sorgenti, separate le funzioni con una riga vuota. Se la funzione è 458esportata, la macro **EXPORT** per questa funzione deve seguire immediatamente 459la riga della parentesi graffa di chiusura. Ad esempio: 460 461.. code-block:: c 462 463 int system_is_up(void) 464 { 465 return system_state == SYSTEM_RUNNING; 466 } 467 EXPORT_SYMBOL(system_is_up); 468 4696.1) Prototipi di funzione 470************************** 471 472Nei prototipi di funzione, includete i nomi dei parametri e i loro tipi. 473Nonostante questo non sia richiesto dal linguaggio C, in Linux viene preferito 474perché è un modo semplice per aggiungere informazioni importanti per il 475lettore. 476 477Non usate la parola chiave ``extern`` con le dichiarazioni di funzione perché 478rende le righe più lunghe e non è strettamente necessario. 479 480Quando scrivete i prototipi di funzione mantenete `l'ordine degli elementi <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_. 481 482Prendiamo questa dichiarazione di funzione come esempio:: 483 484 __init void * __must_check action(enum magic value, size_t size, u8 count, 485 char *fmt, ...) __printf(4, 5) __malloc; 486 487L'ordine suggerito per gli elementi di un prototipo di funzione è il seguente: 488 489- classe d'archiviazione (in questo caso ``static __always_inline``. Da notare 490 che ``__always_inline`` è tecnicamente un attributo ma che viene trattato come 491 ``inline``) 492- attributi della classe di archiviazione (in questo caso ``__init``, in altre 493 parole la sezione, ma anche cose tipo ``__cold``) 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, 498 ``(enum magic value, size_t size, u8 count, char *fmt, ...)``, 499 da notare che va messo anche il nome del parametro) 500- attributi dei parametri (in questo caso, ``__printf(4, 5)``) 501- attributi per il comportamento della funzione (in questo caso, ``__malloc_``) 502 503Notate che per la **definizione** di una funzione (il altre parole il corpo 504della funzione), il compilatore non permette di usare gli attributi per i 505parametri dopo i parametri. In questi casi, devono essere messi dopo gli 506attributi della classe d'archiviazione (notate che la posizione di 507``__printf(4,5)`` cambia rispetto alla **dichiarazione**):: 508 509 static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value, 510 size_t size, u8 count, char *fmt, ...) __malloc 511 { 512 ... 513 }*)**``)**``)``)``*)``)``)``)``*``)``)``)*) 514 5157) Centralizzare il ritorno delle funzioni 516------------------------------------------ 517 518Sebbene sia deprecata da molte persone, l'istruzione goto è impiegata di 519frequente dai compilatori sotto forma di salto incondizionato. 520 521L'istruzione goto diventa utile quando una funzione ha punti d'uscita multipli 522e vanno eseguite alcune procedure di pulizia in comune. Se non è necessario 523pulire alcunché, allora ritornate direttamente. 524 525Assegnate un nome all'etichetta di modo che suggerisca cosa fa la goto o 526perché esiste. Un esempio di un buon nome potrebbe essere ``out_free_buffer:`` 527se la goto libera (free) un ``buffer``. Evitate l'uso di nomi GW-BASIC come 528``err1:`` ed ``err2:``, potreste doverli riordinare se aggiungete o rimuovete 529punti d'uscita, e inoltre rende difficile verificarne la correttezza. 530 531I motivo per usare le goto sono: 532 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 ;) 537 538.. code-block:: c 539 540 int fun(int a) 541 { 542 int result = 0; 543 char *buffer; 544 545 buffer = kmalloc(SIZE, GFP_KERNEL); 546 if (!buffer) 547 return -ENOMEM; 548 549 if (condition1) { 550 while (loop1) { 551 ... 552 } 553 result = 1; 554 goto out_free_buffer; 555 } 556 ... 557 out_free_buffer: 558 kfree(buffer); 559 return result; 560 } 561 562Un baco abbastanza comune di cui bisogna prendere nota è il ``one err bugs`` 563che assomiglia a questo: 564 565.. code-block:: c 566 567 err: 568 kfree(foo->bar); 569 kfree(foo); 570 return ret; 571 572Il baco in questo codice è che in alcuni punti d'uscita la variabile ``foo`` è 573NULL. Normalmente si corregge questo baco dividendo la gestione dell'errore in 574due parti ``err_free_bar:`` e ``err_free_foo:``: 575 576.. code-block:: c 577 578 err_free_bar: 579 kfree(foo->bar); 580 err_free_foo: 581 kfree(foo); 582 return ret; 583 584Idealmente, dovreste simulare condizioni d'errore per verificare i vostri 585percorsi d'uscita. 586 587 5888) Commenti 589----------- 590 591I commenti sono una buona cosa, ma c'è anche il rischio di esagerare. MAI 592spiegare COME funziona il vostro codice in un commento: è molto meglio 593scrivere il codice di modo che il suo funzionamento sia ovvio, inoltre 594spiegare codice scritto male è una perdita di tempo. 595 596Solitamente, i commenti devono dire COSA fa il codice, e non COME lo fa. 597Inoltre, cercate di evitare i commenti nel corpo della funzione: se la 598funzione è così complessa che dovete commentarla a pezzi, allora dovreste 599tornare al punto 6 per un momento. Potete mettere dei piccoli commenti per 600annotare o avvisare il lettore circa un qualcosa di particolarmente arguto 601(o brutto), ma cercate di non esagerare. Invece, mettete i commenti in 602testa alla funzione spiegando alle persone cosa fa, e possibilmente anche 603il PERCHÉ. 604 605Per favore, quando commentate una funzione dell'API del kernel usate il 606formato 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``. 609 610Lo stile preferito per i commenti più lunghi (multi-riga) è: 611 612.. code-block:: c 613 614 /* 615 * This is the preferred style for multi-line 616 * comments in the Linux kernel source code. 617 * Please use it consistently. 618 * 619 * Description: A column of asterisks on the left side, 620 * with beginning and ending almost-blank lines. 621 */ 622 623Per i file in net/ e in drivers/net/ lo stile preferito per i commenti 624più lunghi (multi-riga) è leggermente diverso. 625 626.. code-block:: c 627 628 /* The preferred comment style for files in net/ and drivers/net 629 * looks like this. 630 * 631 * It is nearly the same as the generally preferred comment style, 632 * but there is no initial almost-blank line. 633 */ 634 635È anche importante commentare i dati, sia per i tipi base che per tipi 636derivati. A questo scopo, dichiarate un dato per riga (niente virgole 637per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo 638commento per spiegarne l'uso. 639 640 6419) Avete fatto un pasticcio 642--------------------------- 643 644Va bene, li facciamo tutti. Probabilmente vi è stato detto dal vostro 645aiutante Unix di fiducia che ``GNU emacs`` formatta automaticamente il 646codice C per conto vostro, e avete notato che sì, in effetti lo fa, ma che 647i modi predefiniti non sono proprio allettanti (infatti, sono peggio che 648premere tasti a caso - un numero infinito di scimmie che scrivono in 649GNU emacs non faranno mai un buon programma). 650 651Quindi, potete sbarazzarvi di GNU emacs, o riconfigurarlo con valori più 652sensati. Per fare quest'ultima cosa, potete appiccicare il codice che 653segue nel vostro file .emacs: 654 655.. code-block:: none 656 657 (defun c-lineup-arglist-tabs-only (ignored) 658 "Line up argument lists by tabs, not spaces" 659 (let* ((anchor (c-langelem-pos c-syntactic-element)) 660 (column (c-langelem-2nd-pos c-syntactic-element)) 661 (offset (- (1+ column) anchor)) 662 (steps (floor offset c-basic-offset))) 663 (* (max steps 1) 664 c-basic-offset))) 665 666 (dir-locals-set-class-variables 667 'linux-kernel 668 '((c-mode . ( 669 (c-basic-offset . 8) 670 (c-label-minimum-indentation . 0) 671 (c-offsets-alist . ( 672 (arglist-close . c-lineup-arglist-tabs-only) 673 (arglist-cont-nonempty . 674 (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only)) 675 (arglist-intro . +) 676 (brace-list-intro . +) 677 (c . c-lineup-C-comments) 678 (case-label . 0) 679 (comment-intro . c-lineup-comment) 680 (cpp-define-intro . +) 681 (cpp-macro . -1000) 682 (cpp-macro-cont . +) 683 (defun-block-intro . +) 684 (else-clause . 0) 685 (func-decl-cont . +) 686 (inclass . +) 687 (inher-cont . c-lineup-multi-inher) 688 (knr-argdecl-intro . 0) 689 (label . -1000) 690 (statement . 0) 691 (statement-block-intro . +) 692 (statement-case-intro . +) 693 (statement-cont . +) 694 (substatement . +) 695 )) 696 (indent-tabs-mode . t) 697 (show-trailing-whitespace . t) 698 )))) 699 700 (dir-locals-set-directory-class 701 (expand-file-name "~/src/linux-trees") 702 'linux-kernel) 703 704Questo farà funzionare meglio emacs con lo stile del kernel per i file che 705si trovano nella cartella ``~/src/linux-trees``. 706 707Ma anche se doveste fallire nell'ottenere una formattazione sensata in emacs 708non tutto è perduto: usate ``indent``. 709 710Ora, ancora, GNU indent ha la stessa configurazione decerebrata di GNU emacs, 711ed è per questo che dovete passargli alcune opzioni da riga di comando. 712Tuttavia, non è così terribile, perché perfino i creatori di GNU indent 713riconoscono l'autorità di K&R (le persone del progetto GNU non sono cattive, 714sono solo mal indirizzate sull'argomento), quindi date ad indent le opzioni 715``-kr -i8`` (che significa ``K&R, 8 caratteri di indentazione``), o utilizzate 716``scripts/Lindent`` che indenterà usando l'ultimo stile. 717 718``indent`` ha un sacco di opzioni, e specialmente quando si tratta di 719riformattare i commenti dovreste dare un'occhiata alle pagine man. 720Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione. 721 722Da notare che potete utilizzare anche ``clang-format`` per aiutarvi con queste 723regole, per riformattare rapidamente ad automaticamente alcune parti del 724vostro codice, e per revisionare interi file al fine di identificare errori 725di stile, refusi e possibilmente anche delle migliorie. È anche utile per 726ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire 727il testo e altre cose simili. 728Per maggiori dettagli, consultate il file 729:ref:`Documentation/translations/it_IT/process/clang-format.rst <it_clangformat>`. 730 731 73210) File di configurazione Kconfig 733---------------------------------- 734 735Per tutti i file di configurazione Kconfig* che si possono trovare nei 736sorgenti, l'indentazione è un po' differente. Le linee dopo un ``config`` 737sono indentate con un tab, mentre il testo descrittivo è indentato di 738ulteriori due spazi. Esempio:: 739 740 config AUDIT 741 bool "Auditing support" 742 depends on NET 743 help 744 Enable auditing infrastructure that can be used with another 745 kernel subsystem, such as SELinux (which requires this for 746 logging of avc messages output). Does not do system-call 747 auditing without CONFIG_AUDITSYSCALL. 748 749Le funzionalità davvero pericolose (per esempio il supporto alla scrittura 750per certi filesystem) dovrebbero essere dichiarate chiaramente come tali 751nella stringa di titolo:: 752 753 config ADFS_FS_RW 754 bool "ADFS write support (DANGEROUS)" 755 depends on ADFS_FS 756 ... 757 758Per la documentazione completa sui file di configurazione, consultate 759il documento Documentation/kbuild/kconfig-language.rst 760 761 76211) Strutture dati 763------------------ 764 765Le strutture dati che hanno una visibilità superiore al contesto del 766singolo thread in cui vengono create e distrutte, dovrebbero sempre 767avere un contatore di riferimenti. Nel kernel non esiste un 768*garbage collector* (e fuori dal kernel i *garbage collector* sono lenti 769e inefficienti), questo significa che **dovete** assolutamente avere un 770contatore di riferimenti per ogni cosa che usate. 771 772Avere un contatore di riferimenti significa che potete evitare la 773sincronizzazione e permette a più utenti di accedere alla struttura dati 774in parallelo - e non doversi preoccupare di una struttura dati che 775improvvisamente sparisce dalla loro vista perché il loro processo dormiva 776o stava facendo altro per un attimo. 777 778Da notare che la sincronizzazione **non** si sostituisce al conteggio dei 779riferimenti. La sincronizzazione ha lo scopo di mantenere le strutture 780dati coerenti, mentre il conteggio dei riferimenti è una tecnica di gestione 781della memoria. Solitamente servono entrambe le cose, e non vanno confuse fra 782di loro. 783 784Quando si hanno diverse classi di utenti, le strutture dati possono avere 785due livelli di contatori di riferimenti. Il contatore di classe conta 786il numero dei suoi utenti, e il contatore globale viene decrementato una 787sola volta quando il contatore di classe va a zero. 788 789Un esempio di questo tipo di conteggio dei riferimenti multi-livello può 790essere trovato nella gestore della memoria (``struct mm_sturct``: mm_user e 791mm_count), e nel codice dei filesystem (``struct super_block``: s_count e 792s_active). 793 794Ricordatevi: se un altro thread può trovare la vostra struttura dati, e non 795avete un contatore di riferimenti per essa, quasi certamente avete un baco. 796 79712) Macro, enumerati e RTL 798--------------------------- 799 800I nomi delle macro che definiscono delle costanti e le etichette degli 801enumerati sono scritte in maiuscolo. 802 803.. code-block:: c 804 805 #define CONSTANT 0x12345 806 807Gli enumerati sono da preferire quando si definiscono molte costanti correlate. 808 809I nomi delle macro in MAIUSCOLO sono preferibili ma le macro che assomigliano 810a delle funzioni possono essere scritte in minuscolo. 811 812Generalmente, le funzioni inline sono preferibili rispetto alle macro che 813sembrano funzioni. 814 815Le macro che contengono più istruzioni dovrebbero essere sempre chiuse in un 816blocco do - while: 817 818.. code-block:: c 819 820 #define macrofun(a, b, c) \ 821 do { \ 822 if (a == 5) \ 823 do_this(b, c); \ 824 } while (0) 825 826Cose da evitare quando si usano le macro: 827 8281) le macro che hanno effetti sul flusso del codice: 829 830.. code-block:: c 831 832 #define FOO(x) \ 833 do { \ 834 if (blah(x) < 0) \ 835 return -EBUGGERED; \ 836 } while (0) 837 838sono **proprio** una pessima idea. Sembra una chiamata a funzione ma termina 839la funzione chiamante; non cercate di rompere il decodificatore interno di 840chi legge il codice. 841 8422) le macro che dipendono dall'uso di una variabile locale con un nome magico: 843 844.. code-block:: c 845 846 #define FOO(val) bar(index, val) 847 848potrebbe sembrare una bella cosa, ma è dannatamente confusionario quando uno 849legge il codice e potrebbe romperlo con una cambiamento che sembra innocente. 850 8513) le macro con argomenti che sono utilizzati come l-values; questo potrebbe 852ritorcervisi contro se qualcuno, per esempio, trasforma FOO in una funzione 853inline. 854 8554) dimenticatevi delle precedenze: le macro che definiscono espressioni devono 856essere racchiuse fra parentesi. State attenti a problemi simili con le macro 857parametrizzate. 858 859.. code-block:: c 860 861 #define CONSTANT 0x4000 862 #define CONSTEXP (CONSTANT | 3) 863 8645) collisione nello spazio dei nomi quando si definisce una variabile locale in 865una macro che sembra una funzione: 866 867.. code-block:: c 868 869 #define FOO(x) \ 870 ({ \ 871 typeof(x) ret; \ 872 ret = calc_ret(x); \ 873 (ret); \ 874 }) 875 876ret è un nome comune per una variabile locale - __foo_ret difficilmente 877andrà in conflitto con una variabile già esistente. 878 879Il manuale di cpp si occupa esaustivamente delle macro. Il manuale di sviluppo 880di gcc copre anche l'RTL che viene usato frequentemente nel kernel per il 881linguaggio assembler. 882 88313) Visualizzare i messaggi del kernel 884-------------------------------------- 885 886Agli sviluppatori del kernel piace essere visti come dotti. Tenete un occhio 887di riguardo per l'ortografia e farete una belle figura. In inglese, evitate 888l'uso incorretto di abbreviazioni come ``dont``: usate ``do not`` oppure 889``don't``. Scrivete messaggi concisi, chiari, e inequivocabili. 890 891I messaggi del kernel non devono terminare con un punto fermo. 892 893Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo 894dovrebbero essere evitati. 895 896Ci sono alcune macro per la diagnostica in <linux/dev_printk.h> che dovreste 897usare per assicurarvi che i messaggi vengano associati correttamente ai 898dispositivi e ai driver, e che siano etichettati correttamente: dev_err(), 899dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad 900alcun dispositivo, <linux/printk.h> definisce pr_info(), pr_warn(), pr_err(), 901eccetera. 902 903Tirar fuori un buon messaggio di debug può essere una vera sfida; e quando 904l'avete può essere d'enorme aiuto per risolvere problemi da remoto. 905Tuttavia, i messaggi di debug sono gestiti differentemente rispetto agli 906altri. Le funzioni pr_XXX() stampano incondizionatamente ma pr_debug() no; 907essa non viene compilata nella configurazione predefinita, a meno che 908DEBUG o CONFIG_DYNAMIC_DEBUG non vengono impostati. Questo vale anche per 909dev_dbg() e in aggiunta VERBOSE_DEBUG per aggiungere i messaggi dev_vdbg(). 910 911Molti sottosistemi hanno delle opzioni di debug in Kconfig che aggiungono 912-DDEBUG nei corrispettivi Makefile, e in altri casi aggiungono #define DEBUG 913in specifici file. Infine, quando un messaggio di debug dev'essere stampato 914incondizionatamente, per esempio perché siete già in una sezione di debug 915racchiusa in #ifdef, potete usare printk(KERN_DEBUG ...). 916 91714) Assegnare memoria 918--------------------- 919 920Il kernel fornisce i seguenti assegnatori ad uso generico: 921kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), e vzalloc(). 922Per maggiori informazioni, consultate la documentazione dell'API: 923:ref:`Documentation/translations/it_IT/core-api/memory-allocation.rst <it_memory_allocation>` 924 925Il modo preferito per passare la dimensione di una struttura è il seguente: 926 927.. code-block:: c 928 929 p = kmalloc(sizeof(*p), ...); 930 931La forma alternativa, dove il nome della struttura viene scritto interamente, 932peggiora la leggibilità e introduce possibili bachi quando il tipo di 933puntatore cambia tipo ma il corrispondente sizeof non viene aggiornato. 934 935Il valore di ritorno è un puntatore void, effettuare un cast su di esso è 936ridondante. La conversione fra un puntatore void e un qualsiasi altro tipo 937di puntatore è garantito dal linguaggio di programmazione C. 938 939Il modo preferito per assegnare un vettore è il seguente: 940 941.. code-block:: c 942 943 p = kmalloc_array(n, sizeof(...), ...); 944 945Il modo preferito per assegnare un vettore a zero è il seguente: 946 947.. code-block:: c 948 949 p = kcalloc(n, sizeof(...), ...); 950 951Entrambe verificano la condizione di overflow per la dimensione 952d'assegnamento n * sizeof(...), se accade ritorneranno NULL. 953 954Questi allocatori generici producono uno *stack dump* in caso di fallimento 955a meno che non venga esplicitamente specificato __GFP_NOWARN. Quindi, nella 956maggior parte dei casi, è inutile stampare messaggi aggiuntivi quando uno di 957questi allocatori ritornano un puntatore NULL. 958 95915) Il morbo inline 960------------------- 961 962Sembra che ci sia la percezione errata che gcc abbia una qualche magica 963opzione "rendimi più veloce" chiamata ``inline``. In alcuni casi l'uso di 964inline è appropriato (per esempio in sostituzione delle macro, vedi 965capitolo 12), ma molto spesso non lo è. L'uso abbondante della parola chiave 966inline porta ad avere un kernel più grande, che si traduce in un sistema nel 967suo complesso più lento per via di una cache per le istruzioni della CPU più 968grande e poi semplicemente perché ci sarà meno spazio disponibile per una 969pagina di cache. Pensateci un attimo; una fallimento nella cache causa una 970ricerca su disco che può tranquillamente richiedere 5 millisecondi. Ci sono 971TANTI cicli di CPU che potrebbero essere usati in questi 5 millisecondi. 972 973Spesso le persone dicono che aggiungere inline a delle funzioni dichiarate 974static e utilizzare una sola volta è sempre una scelta vincente perché non 975ci sono altri compromessi. Questo è tecnicamente vero ma gcc è in grado di 976trasformare automaticamente queste funzioni in inline; i problemi di 977manutenzione del codice per rimuovere gli inline quando compare un secondo 978utente surclassano il potenziale vantaggio nel suggerire a gcc di fare una 979cosa che avrebbe fatto comunque. 980 98116) Nomi e valori di ritorno delle funzioni 982------------------------------------------- 983 984Le funzioni possono ritornare diversi tipi di valori, e uno dei più comuni 985è quel valore che indica se una funzione ha completato con successo o meno. 986Questo valore può essere rappresentato come un codice di errore intero 987(-Exxx = fallimento, 0 = successo) oppure un booleano di successo 988(0 = fallimento, non-zero = successo). 989 990Mischiare questi due tipi di rappresentazioni è un terreno fertile per 991i bachi più insidiosi. Se il linguaggio C includesse una forte distinzione 992fra gli interi e i booleani, allora il compilatore potrebbe trovare questi 993errori per conto nostro ... ma questo non c'è. Per evitare di imbattersi 994in questo tipo di baco, seguite sempre la seguente convenzione:: 995 996 Se il nome di una funzione è un'azione o un comando imperativo, 997 essa dovrebbe ritornare un codice di errore intero. Se il nome 998 è un predicato, la funzione dovrebbe ritornare un booleano di 999 "successo" 1000 1001Per esempio, ``add work`` è un comando, e la funzione add_work() ritorna 0 1002in caso di successo o -EBUSY in caso di fallimento. Allo stesso modo, 1003``PCI device present`` è un predicato, e la funzione pci_dev_present() ritorna 10041 se trova il dispositivo corrispondente con successo, altrimenti 0. 1005 1006Tutte le funzioni esportate (EXPORT) devono rispettare questa convenzione, e 1007così dovrebbero anche tutte le funzioni pubbliche. Le funzioni private 1008(static) possono non seguire questa convenzione, ma è comunque raccomandato 1009che lo facciano. 1010 1011Le funzioni il cui valore di ritorno è il risultato di una computazione, 1012piuttosto che l'indicazione sul successo di tale computazione, non sono 1013soggette a questa regola. Solitamente si indicano gli errori ritornando un 1014qualche valore fuori dai limiti. Un tipico esempio è quello delle funzioni 1015che ritornano un puntatore; queste utilizzano NULL o ERR_PTR come meccanismo 1016di notifica degli errori. 1017 101817) L'uso di bool 1019----------------- 1020 1021Nel kernel Linux il tipo bool deriva dal tipo _Bool dello standard C99. 1022Un valore bool può assumere solo i valori 0 o 1, e implicitamente o 1023esplicitamente la conversione a bool converte i valori in vero (*true*) o 1024falso (*false*). Quando si usa un tipo bool il costrutto !! non sarà più 1025necessario, e questo va ad eliminare una certa serie di bachi. 1026 1027Quando si usano i valori booleani, dovreste utilizzare le definizioni di true 1028e false al posto dei valori 1 e 0. 1029 1030Per il valore di ritorno delle funzioni e per le variabili sullo stack, l'uso 1031del tipo bool è sempre appropriato. L'uso di bool viene incoraggiato per 1032migliorare la leggibilità e spesso è molto meglio di 'int' nella gestione di 1033valori booleani. 1034 1035Non usate bool se per voi sono importanti l'ordine delle righe di cache o 1036la loro dimensione; la dimensione e l'allineamento cambia a seconda 1037dell'architettura per la quale è stato compilato. Le strutture che sono state 1038ottimizzate per l'allineamento o la dimensione non dovrebbero usare bool. 1039 1040Se una struttura ha molti valori true/false, considerate l'idea di raggrupparli 1041in un intero usando campi da 1 bit, oppure usate un tipo dalla larghezza fissa, 1042come u8. 1043 1044Come per gli argomenti delle funzioni, molti valori true/false possono essere 1045raggruppati in un singolo argomento a bit denominato 'flags'; spesso 'flags' è 1046un'alternativa molto più leggibile se si hanno valori costanti per true/false. 1047 1048Detto ciò, un uso parsimonioso di bool nelle strutture dati e negli argomenti 1049può migliorare la leggibilità. 1050 105118) Non reinventate le macro del kernel 1052--------------------------------------- 1053 1054Il file di intestazione include/linux/kernel.h contiene un certo numero 1055di macro che dovreste usare piuttosto che implementarne una qualche variante. 1056Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la 1057macro: 1058 1059.. code-block:: c 1060 1061 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) 1062 1063Analogamente, se dovete calcolare la dimensione di un qualche campo di una 1064struttura, usate 1065 1066.. code-block:: c 1067 1068 #define sizeof_field(t, f) (sizeof(((t*)0)->f)) 1069 1070Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo 1071rigido sui tipi. Sentitevi liberi di leggere attentamente questo file 1072d'intestazione per scoprire cos'altro è stato definito che non dovreste 1073reinventare nel vostro codice. 1074 107519) Linee di configurazione degli editor e altre schifezze 1076----------------------------------------------------------- 1077 1078Alcuni editor possono interpretare dei parametri di configurazione integrati 1079nei file sorgenti e indicati con dai marcatori speciali. Per esempio, emacs 1080interpreta le linee marcate nel seguente modo: 1081 1082.. code-block:: c 1083 1084 -*- mode: c -*- 1085 1086O come queste: 1087 1088.. code-block:: c 1089 1090 /* 1091 Local Variables: 1092 compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c" 1093 End: 1094 */ 1095 1096Vim interpreta i marcatori come questi: 1097 1098.. code-block:: c 1099 1100 /* vim:set sw=8 noet */ 1101 1102Non includete nessuna di queste cose nei file sorgenti. Le persone hanno le 1103proprie configurazioni personali per l'editor, e i vostri sorgenti non 1104dovrebbero sovrascrivergliele. Questo vale anche per i marcatori 1105d'indentazione e di modalità d'uso. Le persone potrebbero aver configurato una 1106modalità su misura, oppure potrebbero avere qualche altra magia per far 1107funzionare bene l'indentazione. 1108 110920) Inline assembly 1110------------------- 1111 1112Nel codice specifico per un'architettura, potreste aver bisogno di codice 1113*inline assembly* per interfacciarvi col processore o con una funzionalità 1114specifica della piattaforma. Non esitate a farlo quando è necessario. 1115Comunque, non usatele gratuitamente quando il C può fare la stessa cosa. 1116Potete e dovreste punzecchiare l'hardware in C quando è possibile. 1117 1118Considerate la scrittura di una semplice funzione che racchiude pezzi comuni 1119di codice assembler piuttosto che continuare a riscrivere delle piccole 1120varianti. Ricordatevi che l' *inline assembly* può utilizzare i parametri C. 1121 1122Il codice assembler più corposo e non banale dovrebbe andare nei file .S, 1123coi rispettivi prototipi C definiti nei file d'intestazione. I prototipi C 1124per le funzioni assembler dovrebbero usare ``asmlinkage``. 1125 1126Potreste aver bisogno di marcare il vostro codice asm come volatile al fine 1127d'evitare che GCC lo rimuova quando pensa che non ci siano effetti collaterali. 1128Non c'è sempre bisogno di farlo, e farlo quando non serve limita le 1129ottimizzazioni. 1130 1131Quando scrivete una singola espressione *inline assembly* contenente più 1132istruzioni, mettete ognuna di queste istruzioni in una stringa e riga diversa; 1133ad eccezione dell'ultima stringa/istruzione, ognuna deve terminare con ``\n\t`` 1134al fine di allineare correttamente l'assembler che verrà generato: 1135 1136.. code-block:: c 1137 1138 asm ("magic %reg1, #42\n\t" 1139 "more_magic %reg2, %reg3" 1140 : /* outputs */ : /* inputs */ : /* clobbers */); 1141 114221) Compilazione sotto condizione 1143--------------------------------- 1144 1145Ovunque sia possibile, non usate le direttive condizionali del preprocessore 1146(#if, #ifdef) nei file .c; farlo rende il codice difficile da leggere e da 1147seguire. Invece, usate queste direttive nei file d'intestazione per definire 1148le funzioni usate nei file .c, fornendo i relativi stub nel caso #else, 1149e quindi chiamate queste funzioni senza condizioni di preprocessore. Il 1150compilatore non produrrà alcun codice per le funzioni stub, produrrà gli 1151stessi risultati, e la logica rimarrà semplice da seguire. 1152 1153È preferibile non compilare intere funzioni piuttosto che porzioni d'esse o 1154porzioni d'espressioni. Piuttosto che mettere una ifdef in un'espressione, 1155fattorizzate parte dell'espressione, o interamente, in funzioni e applicate 1156la direttiva condizionale su di esse. 1157 1158Se avete una variabile o funzione che potrebbe non essere usata in alcune 1159configurazioni, e quindi il compilatore potrebbe avvisarvi circa la definizione 1160inutilizzata, marcate questa definizione come __maybe_unused piuttosto che 1161racchiuderla in una direttiva condizionale del preprocessore. (Comunque, 1162se una variabile o funzione è *sempre* inutilizzata, rimuovetela). 1163 1164Nel codice, dov'è possibile, usate la macro IS_ENABLED per convertire i 1165simboli Kconfig in espressioni booleane C, e quindi usatela nelle classiche 1166condizioni C: 1167 1168.. code-block:: c 1169 1170 if (IS_ENABLED(CONFIG_SOMETHING)) { 1171 ... 1172 } 1173 1174Il compilatore valuterà la condizione come costante (constant-fold), e quindi 1175includerà o escluderà il blocco di codice come se fosse in un #ifdef, quindi 1176non ne aumenterà il tempo di esecuzione. Tuttavia, questo permette al 1177compilatore C di vedere il codice nel blocco condizionale e verificarne la 1178correttezza (sintassi, tipi, riferimenti ai simboli, eccetera). Quindi 1179dovete comunque utilizzare #ifdef se il codice nel blocco condizionale esiste 1180solo quando la condizione è soddisfatta. 1181 1182Alla fine di un blocco corposo di #if o #ifdef (più di alcune linee), 1183mettete un commento sulla stessa riga di #endif, annotando la condizione 1184che termina. Per esempio: 1185 1186.. code-block:: c 1187 1188 #ifdef CONFIG_SOMETHING 1189 ... 1190 #endif /* CONFIG_SOMETHING */ 1191 1192Appendice I) riferimenti 1193------------------------ 1194 1195The C Programming Language, Second Edition 1196by Brian W. Kernighan and Dennis M. Ritchie. 1197Prentice Hall, Inc., 1988. 1198ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback). 1199 1200The Practice of Programming 1201by Brian W. Kernighan and Rob Pike. 1202Addison-Wesley, Inc., 1999. 1203ISBN 0-201-61586-X. 1204 1205Manuali GNU - nei casi in cui sono compatibili con K&R e questo documento - 1206per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui 1207https://www.gnu.org/manual/ 1208 1209WG14 è il gruppo internazionale di standardizzazione per il linguaggio C, 1210URL: https://www.open-std.org/JTC1/SC22/WG14/ 1211 1212Kernel CodingStyle, by greg@kroah.com at OLS 2002: 1213http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ 1214
