Conta spazi bianchi in una stringa C

[M.A.W. 1968]

In realtà il loop principale andrebbe impostato come segue:

for(i = 0; i < lenght; ++i)
{
    if (' ' == stringa[i])
    {
        ++conta;
    }
}

Anche un banale esempio come il presente può essere utile per illustrare, per l'ennesima volta, alcune importantissime regole di stile e software engineering.

1) Quando vedete un <= o un >= in un programma C, dovete immediatamente preoccuparvi. A prescindere da rare occasioni di necessità e specifici algoritmi di natura algebrico-discreta, tali operatori segnalano praticamente sempre la presenza di un insidioso errore di off-by-one che può portare problemi assai difficili da rintracciare a runtime. In C (e in Assembly...) si conta sempre partendo da zero, e i numeri naturali compresi nell'intervallo tra 0 ed n, estremi inclusi, sono esattamente n + 1.

2) Nelle operazioni di confronto con == è sempre opportuno anteporre le costanti. Infatti esse non possono essere un lvalue, ovvero non possono stare a "sinistra" in una espressione di assegnazione. Ergo, nel caso fin troppo frequente in cui si dimentichi un segno =, sarà il compilatore a segnalare come errore sintattico quello che in realtà è un grave errorre semantico.

3) Il linguaggio C non è Pascal o Basic. Esistono operatori appositi per incrementare e decrementare unitariamente una variabile, ed esistono operatori di assegnazione composita per tutti gli altri casi (es +=, -=). Per questioni di coerenza ed eleganza, si devono sempre usare tali operatori, in luogo della inguardabile sintassi a = a + qualcosa, che pure è accettata dal compilatore (ma non per questo automaticamente accettabile in sede di esame, colloquio di lavoro e/o revisione del codice).

4) Gli statement di controllo devono sempre essere seguiti da parentesi graffe, anche se il blocco di codice sotteso contiene un unico statement. Una simile regola si trova praticamente in ogni raccomandazione normativa, a partire dalla MISRA/C, ed è ovviamente mirata sia alla migliore leggibilità del codice, sia a facilitare il refactoring evitando a monte errori fin troppo comuni.

Applicare le regole di engineering fa definitivamente la differenza tra un programma che "in qualche modo funziona" e un programma scritto in modo professionale, manutenibile e robusto. E non è mai troppo presto per impararle!

[MItaly]

Sulla 2), mi permetto di aggiungere che tuttavia qualunque compilatore decente con warning attivati (e bisognerebbe avere sempre -Wall su gcc e simili e /W3 come minimo su VC++) emette un warning di livello grave per un assegnazione in un'espressione condizionale, per cui, almeno per quanto mi riguarda, evito le cosiddette "Yoda conditions", che trovo piuttosto innaturali sia da scrivere che da leggere.

Una cosa che è già stata postata come correzione ma non puntualizzata è l'uso dei codici ASCII "espliciti" nel codice, in questo caso il 32 (o 0x20) nel confronto: evitali. In C ci sono i literal di tipo char (carattere tra apici singoli) apposta, non c'è motivo per infarcire il codice di numeri magici incomprensibili.

Ultimo appunto @Fiorediloto: quando posti codice, inseriscilo tra tag [CODE] ... [/CODE], altrimenti perde l'indentazione e non beneficia dell'evidenziazione della sintassi.

[M.A.W. 1968]

Sulla 2), mi permetto di aggiungere che tuttavia qualunque compilatore decente con warning attivati (e bisognerebbe avere sempre -Wall su gcc e simili e /W3 come minimo su VC++) emette un warning di livello grave per un assegnazione in un'espressione condizionale, per cui, almeno per quanto mi riguarda, evito le cosiddette "Yoda conditions", che trovo piuttosto innaturali sia da scrivere che da leggere.

Osservazione sicuramente sensata, ma purtroppo talune normative impongono esplicitamente l'uso di tale sintassi, e quindi l'uso di un checker segnalerà un warning in caso di "violazione della regola" ossia anteposizione del LValue.

Una cosa che è già stata postata come correzione ma non puntualizzata è l'uso dei codici ASCII "espliciti" nel codice, in questo caso il 32 (o 0x20) nel confronto: evitali. In C ci sono i literal di tipo char (carattere tra apici singoli) apposta, non c'è motivo per infarcire il codice di numeri magici incomprensibili.

Ottima occasione per ricordare come ancora molti grandi sistemi (anche ad uso accademico), che supportano appieno il linguaggio C, non usano ASCII ma altre codifiche, EBCDIC in testa... i literal del C devono sempre essere usati, a meno di solidi e documentati motivi che facciano propendere per il contrario.