Appunti del 23/03/23

Stili di programmazione

bisogna rispettare lo stile altrimenti lui non lo legge

1. serve a far in modo che la struttura del codice sia sempre la stessa
2. quello che viene scritto sia coerente (coerenza tra descrizione delle soluzioni)

se soluzione non rispetta lo stile, viene ignorata.

Cose da rispettare

Nomi variabili

no nomi qualunque. il nome deve permettere di capire subito cos'è l'oggetto. no singola lettera, no che dice altro rispetto a ciò che fa. deve chiarire subito che tipo di dato è. deve essere breve, facile da ricordare ma deve dare le informazioni necessarie. se il nome ha ampia portata (usato in tutto il progetto) deve essere più che significativo. la singola lettera può andare bene per dati locali in piccole funzioni. se parliamo del main o di una var semiglobale no. nomi generici come vettore, array, vec non vanno bene.

ogni lettera ha un suo uso

• i, j, k come indici;
• n, m per gli interi;
• p, q per i puntatori;
• s, t per le stringhe;
• c per i caratteri.

le variabili dichiarate nel main o variabili globali, la singola lettera non va bene.

ripete la scelta del nome è importante ma non bisogna esagerare.

se si sceglie una costante il nome sarà scritto tutto in maiuscolo es COSTANTE, una variabile in minuscolo es. variabile se serve un'altra parola variabile_attiva altrimenti camelCase variabileAttiva. le costanti non sono mai locali ad una funzione, succede molto raramente. per questo motivo non vanno bene costanti a una lettera. vanno bene solo ed esclusivamente nel casi un cui la variabile abbia un nome ad una lettera e sia universalmente riconosciuta.

Nomi funzioni

se due func sono correlate o simili i nomi devono evidenziare questa cosa. se c'è possibilità di confusione i nomi devono essere il più diversi possibili.

se es. il tipo di dato è orario e c'è una fun che cambia l'orario, la parola orario va trovata in ogni nome correlato.

es. eliminare articoli, proposizioni e quant'altro.

verbo che dichiari l'azione della funzione e oggetto su cui la esegue.

se si ha una funzione che fa molte cose, questa funzione come va chiamata? leggi e controlla bla bla? non va bene, va riscritta. verbo all'infinito. se func è bool is+aggettivo es isPalindrome(). l'importante è scrivere tutto in una lingua o inglese o italiano. non inventare parole. nomi sono +.

per le func stessa cosa, es. funzione_principale() oppure funzionePrincipale() quindi o snake_case o camelCase.

Operatori (?)

vanno usati gli spazi es NO i=i+1; ma i = i + 1; o ancora A > B. anche se non si vuole alterare la precedenza degli operatori, usare le parentesi per rendere più facile la lettura del codice.

cercare di scrivere le expr booleane in modo più naturale possibile, come se si stesse pronunciando la stessa. es A + 1 > 0 è corretta me è meglio scrivere A > -1. se bisogna verificare se un un numero è maggiore di zero si scrive A > 0 e non !(A <= 0)

1. if (!(a == 0) || !(b == 0)) – errato;
2. if !((a == 0) && (b == 0)) – errato;
3. if ((a != 0) || (b != 0)) – corretto.

non c'è motivo di scrivere nei primi due modi.

bisogna cercare di raggruppare il più possibile i pezzetti logici anche se si vuole rispettare l'ordine di precedenza.

es. leap_year = y % 4 == 0 && y % 100 != 0 || y % 400 == 0 è scritto senza usare alcuna parentsi. è un controllo per l'anno bisestile, sarebbe meglio scrivere leap_year = (y % 4 == 0) && (y % 100 != 0) || (y % 400 == 0), si potrebbe anche dividere in tre sottoespressioni differenti e in alcuni casi è anche meglio.

una forma che fornisce il C è la seguente: <cond> ? <then> : <else>, dunque si può scrivere variabile = <cond> ? <then> : <else>; è difficile da leggere e sarebbe meglio scrivere:

if (cond) {
  variabile = ...;
} else {
  variabile = ...;
}

il costrutto precedente permette di annidare le condizioni

variabile = cond ? cond ? cond ? cond ? then : else;

il C permette di scrivere

if (cond)
  azione;
else
  azione;

ma è meglio non usarla

if (cond) {
  azione;
} else {
  azione;
}

1. si potrebbe dover aggiungere altre condizioni in futuro
2. evita problemi di capire a chi appartiene cosa.

per evitare di avere un'indentazione eccessiva con gli else..if si può scriverli sulla stessa riga

if (cond) {
  azione;
} else if (cond) {
  azione;
} else if (cond) {
  azione;
}

la posizione delle graffe va messa dopo la condizione

if /* while/do */ (condizione) {
  azione;
}

Numeri magici

tutti i numeri che appaiono nel programma, eccetto 0/1, sono detti numeri magici. bisogna evitare di scrivere valori del tipo if (a > 10) perché 10 è un numero magico, che rappresenta 10? I valori devono essere contestualizzati, si crea una costante che abbia come nome cosa rappresenta il numero.

Commenti

non vanno messi commenti inutili es. che duplicano quello che già dice il codice. vanno usati per parti di codice che vanno spiegate, oppure per delimitare porzioni di codice. se il codice è comprensibile es.

if (c >= 'A' && c <= 'Z') {
  azione;
}

è inutile spiegare la condizione, è già chiaro.

se si utilizzano formule o altro presi da altre fonti, sarebbe meglio linkare queste fonti o con un url, nome del libro, etc.

Alcune cose vanno spiegate sempre, ovvero le funzioni. ogni funzione ha un blocco di commenti che spiega cosa fa la funzione e ogni param di input e ogni param di output. ci sono sistemi che permettono di documentare automaticamente il codice utilizzando questi commendi (Doxygen). se non si riesce a spiegare una funzione, sarebbe meglio spezzarla in più funzioni differenti.

I commenti vanno aggiornati assieme al codice.

Esercizio

rivedere l'esercizio di ieri in funzione di ciò che è stato detto oggi.