Lines Matching refs:una
18 La prima cosa che suggerisco è quella di stamparsi una copia degli standard
48 subordinati ``case``. In questo modo si evita una doppia indentazione per
120 allineare i nuovi pezzi alla parentesi aperta di una funzione.
122 Lo stesso si applica, nei file d'intestazione, alle funzioni con una
135 una strategia di posizionamento o un'altra; ma il modo qui preferito,
138 di chiusura per prima su una nuova riga, così:
177 Notate che la graffa di chiusura è da sola su una riga propria, ad
204 righe sul vostro schermo non sono una risorsa illimitata (pensate ad uno
208 Non usate inutilmente le graffe dove una singola espressione è sufficiente.
225 contiene una sola espressione; in quest'ultimo caso usate le graffe per
237 Inoltre, usate le graffe se un ciclo contiene più di una semplice istruzione:
250 (principalmente) dalle funzioni e dalle parole chiave. Usate una spazio dopo
276 Quando dichiarate un puntatore ad una variabile o una funzione che ritorna un
304 e nessuno spazio attorno agli operatori dei membri di una struttura ``.`` e
308 l'indentazione ``furba`` inseriranno gli spazi bianchi all'inizio di una nuova
312 perché volete lasciare una riga vuota. Il risultato è che finirete per avere
317 una serie di modifiche, questo potrebbe far fallire delle modifiche successive
327 non è una delle più difficili da capire.
330 descrittivi per variabili globali sono un dovere. Chiamare una funzione
334 dei nomi descrittivi, così come le funzioni globali. Se avete una funzione
345 ``i`` possa non essere capito. Analogamente, ``tmp`` può essere una qualsiasi
382 una bella cosa. Il motivo per cui abbiamo cose come pte_t eccetera è
393 Ancora - dev'esserci una **ragione** per farlo. Se qualcosa è
400 è una buona scelta.
423 non usare MAI MAI un typedef a meno che non rientri in una delle regole
426 In generale, un puntatore, o una struttura a cui si ha accesso diretto in
432 Le funzioni dovrebbero essere brevi e carine, e fare una cosa sola. Dovrebbero
434 di uno schermo secondo ISO/ANSI è di 80x24), e fare una cosa sola e bene.
436 La massima lunghezza di una funziona è inversamente proporzionale alla sua
438 una funzione che è concettualmente semplice ma che è implementata come un
442 Comunque, se avete una funzione complessa e sospettate che uno studente
457 Nei file sorgenti, separate le funzioni con una riga vuota. Se la funzione è
503 Notate che per la **definizione** di una funzione (il altre parole il corpo
521 L'istruzione goto diventa utile quando una funzione ha punti d'uscita multipli
591 I commenti sono una buona cosa, ma c'è anche il rischio di esagerare. MAI
594 spiegare codice scritto male è una perdita di tempo.
605 Per favore, quando commentate una funzione dell'API del kernel usate il
637 per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo
707 Ma anche se doveste fallire nell'ottenere una formattazione sensata in emacs
720 Ma ricordatevi: ``indent`` non è un correttore per una cattiva programmazione.
765 Le strutture dati che hanno una visibilità superiore al contesto del
774 in parallelo - e non doversi preoccupare di una struttura dati che
780 dati coerenti, mentre il conteggio dei riferimenti è una tecnica di gestione
786 il numero dei suoi utenti, e il contatore globale viene decrementato una
838 sono **proprio** una pessima idea. Sembra una chiamata a funzione ma termina
842 2) le macro che dipendono dall'uso di una variabile locale con un nome magico:
848 potrebbe sembrare una bella cosa, ma è dannatamente confusionario quando uno
849 legge il codice e potrebbe romperlo con una cambiamento che sembra innocente.
852 ritorcervisi contro se qualcuno, per esempio, trasforma FOO in una funzione
864 5) collisione nello spazio dei nomi quando si definisce una variabile locale in
865 una macro che sembra una funzione:
876 ret è un nome comune per una variabile locale - __foo_ret difficilmente
877 andrà in conflitto con una variabile già esistente.
887 di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
903 Tirar fuori un buon messaggio di debug può essere una vera sfida; e quando
914 incondizionatamente, per esempio perché siete già in una sezione di debug
925 Il modo preferito per passare la dimensione di una struttura è il seguente:
962 Sembra che ci sia la percezione errata che gcc abbia una qualche magica
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
969 pagina di cache. Pensateci un attimo; una fallimento nella cache causa una
974 static e utilizzare una sola volta è sempre una scelta vincente perché non
978 utente surclassano il potenziale vantaggio nel suggerire a gcc di fare una
985 è quel valore che indica se una funzione ha completato con successo o meno.
991 i bachi più insidiosi. Se il linguaggio C includesse una forte distinzione
996 Se il nome di una funzione è un'azione o un comando imperativo,
1011 Le funzioni il cui valore di ritorno è il risultato di una computazione,
1025 necessario, e questo va ad eliminare una certa serie di bachi.
1040 Se una struttura ha molti valori true/false, considerate l'idea di raggrupparli
1055 di macro che dovreste usare piuttosto che implementarne una qualche variante.
1063 Analogamente, se dovete calcolare la dimensione di un qualche campo di una
1105 d'indentazione e di modalità d'uso. Le persone potrebbero aver configurato una
1113 *inline assembly* per interfacciarvi col processore o con una funzionalità
1118 Considerate la scrittura di una semplice funzione che racchiude pezzi comuni
1131 Quando scrivete una singola espressione *inline assembly* contenente più
1132 istruzioni, mettete ognuna di queste istruzioni in una stringa e riga diversa;
1154 porzioni d'espressioni. Piuttosto che mettere una ifdef in un'espressione,
1158 Se avete una variabile o funzione che potrebbe non essere usata in alcune
1161 racchiuderla in una direttiva condizionale del preprocessore. (Comunque,
1162 se una variabile o funzione è *sempre* inutilizzata, rimuovetela).