L'arte della Programmazione: il Futurismo

Nel parco software, la razza dei Programmatori è senza dubbio la più fortunata (forse proprio perché è essa a creare i software!).
Per scrivere i sorgenti dei software ci sono a disposizione migliaia e migliaia di software, ed anche il software più semplice può trasformarsi nella piattaforma ideale di sviluppo per qualche Programmatore; idealmente, un Programmatore potrebbe programmare con una penna e un foglio di carta, per poi darlo in scansione a un OCR per la compilazione e la generazione del software.


Insomma, i Programmatori sono gli utenti più ricchi in termini di software disponibile per lo svolgimento del loro innato compito. Eppure, se dovessi chiedere a un Programmatore quale Editor o IDE utilizzare ti risponderà con uno scontato e arrogante “innegabilmente xxxx è il NonPlusUltra”, ovviamente ognuno menzionerà un software differente perché, eh già, non esiste l'innegabilmente NonPlusUltra (...ma questa è un'altra storia che vi racconterò!).

Dunque, se è vero ritenere i Programmatori come gli utenti più fortunati del mondo informatico è anche vero etichettarli come i più cavillosi sfortunati. Sì, perché, benché abbiano la libertà di scegliere (o crearselo) il proprio strumento tra un parco software enorme, hanno la cavillosa sfortuna di poter (quasi) scrivere come vogliono e andare, così, incontro a caos e possibili errori.

Il Programmatore, quotidianamente, battezza variabili, funzioni, classi, ecc. con dei nomi di sua fantasia. Adesso, potete iniziare a capire perché spesso si parla di Arte della programmazione.
Un bravo Programmatore è colui che riesce a inventare nomi significativi (ES: QuestaVariabileContieneUnIndirizzoEmail), brevi (ES: Q.V.C.U.I.E.) e facilmente ricordabili (ES: Email). Non stupitevi quindi se dal vostro partner vi aspettereste un:

“Stasera, vorresti uscire a cena con me in un ristorantino vicino al faro della scogliera?” (fonte: un Normal partner)

invece del chiaro,breve e facilmente ricordabile:

“Ceni?” (fonte: il Programmatore partner)

Sembra semplice, ma l'arte della programmazione è severa e rigorosa. Quasi tutti i linguaggi di programmazione sono case sensitive (sensibili alle maiuscole e minuscole), ergo se si battezza una funzione con il nome di CancellaLaVariabileCheContieneUnIndirizzoEmail (un bravo Programmatore scriverebbe più brevemente CancellaEmail), ogni volta che la si richiama bisogna inevitabilmente scriverla esattamente (attenzione alle maiuscole) com'è stata battezzata:

CancellaEmail()

mentre un

cancellaEmail()

genererebbe un errore (se il compilatore non è un incosciente!)!


Non è difficile, se non che esistono molti modi per scrivere lo stesso nome, ad esempio:

CancellaEmail()
cancellaEmail()
cancella_email()
CANCELLA_EMAIL()

Regole per una buona scrittura

Beh, non ci crederesti, ma tutti, o quasi, i modi per scrivere un nome sono stati definiti in specifiche regole di scrittura. Ecco le più note:

• UpperCase: tutte le lettere devono essere scritte in maiuscolo. Esempio CANCELLA EMAIL(), peccato che, nella programmazione, gli spazi e altri caratteri speciali non possono essere usati per l'assegnazione dei nomi, quindi si fa ricorso a UpperCase with underscores o a UpperCase with hyphens.

• UpperCase with underscores o genericamente EmbeddedUnderscore: come sopra, ma le parole sono separate dal carattere di underScore. Esempio CANCELLA_EMAIL().

• UpperCase with hyphens: come sopra, ma le parole sono separate dal trattino. Esempio CANCELLA-EMAIL().

• LowerCase: tutte le lettere devono essere scritte in minuscolo. Esempio cancella email(), peccato che, nella programmazione, gli spazi e altri caratteri speciali non possono essere usati per l'assegnazione dei nomi, quindi si fa ricorso a LowerCase with underscores o a LowerCase with hyphens.

• LowerCase with underscores o genericamente EmbeddedUnderscore: come sopra, ma le parole sono separate dal carattere di underScore. Esempio cancella_email().

• LowerCase with hyphens: come sopra, ma le parole sono separate dal trattino. Esempio cancella-email().

• CamelCase o LowerCamelCase: Tutte le parole sono unite. La prima lettera è rigorosamente minuscola, dopo tutte le altre parole iniziano con la lettera maiuscola. Esempio cancellaEmail().

• PascalCase o UpperCamelCase: Tutte le parole sono unite e tutte iniziano con la lettera maiuscola. Esempio CancellaEmail().

• BumpyCase o MixedCase: è l'utilizzo misto di CamelCase e PascalCase. Un esempio pratico di utilizzo misto, ma non casuale, è l'utilizzo del PascalCase per la definizione dei nomi delle Classi e il CamelCase per i nomi delle Istanze.

• WikiCase: è simile a PascalCase ma impone che non ci siano mai due lettere maiuscole consecutive. Ad esempio questo nome è un PascalCase che non può definirsi WikiCase perché ci sono due lettere consecutive maiuscole: PrepariamoIBiscotti().

• StudlyCaps: Alterna le lettere maiuscole con quelle minuscole. ESEMPIO cAnCeLla EmAiL(). Ai fini della programmazione bisogna fondere questo stile con EmbeddedUnderscore, ma quale folle programmatore deciderà di usare questa regola?

• CanonicalStudlyCaps: è simile allo StudlyCaps ma soltanto le vocali vengono scritte minuscole e tutte le altre lettere in maiuscolo. Esempio CaNCeLLa eMaiL(). Ai fini della programmazione bisogna fondere questo stile con EmbeddedUnderscore, oltre a essere folle il programmatore deve avere una spiccata propensione al masochismo per decidere di scegliere questa regola.

Le Linee Guida

Un bravo Programmatore non improvvisa mai, ma segue diligentemente una "Linee Guida" al fine di riuscire a modellare con le proprie mani un "quadro da incorniciare" (un codice chiaro, leggibile, armonioso e rigoroso, tanto da riuscire ad affascinare la vista di un altro Programmatore o insegnante di Informatica).
Purtroppo, per cadere a bomba sulla cavillosa sfortuna del Programmatore, non esiste una riconosciuta e universale "Linee Guida"! Anche se qualcuno cerca di imporre la propria (che ovviamente differisce dalle altre).

Microsoft dice ai propri programmatori e seguaci: questo
Apple: questo
Google: questo
e alcuni linguaggi di programmazione “consigliano” di seguire determinate regole: queste


In conclusione, il quadro perfetto è perennemente incompleto. Colori contrastati e figure sghembe. La scrittura del codice, oltre a essere piena di commenti insulsi e grammaticalmente “buggati” e ad avere un'indentazione fallata da TAB e spazi disomogenei, precipita inevitabilmente (salvo eccezioni) nell'utilizzo di un mixed rules (un minestrone di regole) che proietta violentemente l'Arte della Programmatore nella corrente artistica del Futurismo.
Adesso, dopo la lettura di questo mio saggio, potreste riconsiderare l'arte di Filippo Marinetti, l'artista molto discusso, ma del quale non si è mai discusso sul fatto che potrebbe essere il pioniere dello stile di scrittura dei Programmatori!

Infine, l'approccio del Programmatore 2.0

Sapete cosa fa il bravo Programmatore 2.0? Si impone di seguire una delle tante Linee Guida e perde il suo tempo a modificare tutti i nomi delle variabili, funzioni, classi, ecc....
Dopo alcune intense giornate di lavoro scopre che il programma non funziona più. Ergo, passa le successive giornate a correggere il problema riscrivendo buona parte del codice, ovviamente, avvolto dal pensiero lineare e insistente della programmazione mischiato ad una buon dose di incazzatura nervosismo, purga dai propri propositi tutte le regole specificate nelle Linee Guida che aveva deciso di seguire.
Dopo qualche mese di programmazione, ricade vittima del narcisismo di avere un codice “artisticamente valido” e ritorna nel loop (=un cane che si morde la coda) di modificare i propri sorgenti al fine di allinearli ad una delle tante Linee Guida.

Maggiori informazioni

Una lista di alcuni Editor utilizzati per la programmazione.

Una lista dei più noti IDE utilizzati per la programmazione.

Alcuni consigli per inventare i nomi delle funzioni.