Gitbaritalian
developer
podcast
12

Dare il nome alle variabili classi e funzioni. Programmare è questo!

Serie 1
Episodio 12
Durata 20 minuti

Dare il nome alle cose è una delle cose che i programmatori riconoscono come più complicate nella fase di sviluppo software. Programmando dovremmo comportarci come i grandi scritto. Dovremmo farci guidare dal significato. Usare le parole nel nostro codice deve essere una operazione oculate. Due chiacchiere con Orwell e Uncle Bob.

Links Utili

https://www.amazon.it/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 https://medium.com/personal-growth/george-orwells-six-rules-for-great-writing-4db6d31ff136

Contatti @brainrepo su twitter o via mail a info@gitbar.it

Crediti Le sigle sono state prodotte da MondoComputazionale Registrato negli studi di Radio Nuoro Centrale Le musiche da Blan Kytt - RSPN

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

Benvenuti su Bar, il podcast dedicato al mondo dei developer.
In mezzo artigiani in mezzo artisti che ogni giorno infilavano le mani nel fango per creare nel modo più efficace possibile quei prodotti digitali che quotidianamente utilizziamo.
Piu' Dodicesima puntata di KITT Bar Bene e benvenuti Io sono Ben Repo e questo E' il podcast dei Full Stack Developer italiani.
Dodicesima puntata dove affronteremo un argomento molto interessante, tanto semplice quanto importante nella vita dei developer.
Parleremo infatti di dare i nomi alle cose dove per cosa intendiamo variabili classi, funzioni costanti e tutti quelli per gli alimenti che sono praticamente le nostre Lego, con le quali andiamo a costruire il nostro castello quotidiana.
Ma prima di entrare nel vivo dell'argomento di oggi mi premeva ricordarvi i nostri contatti.
Bene, potete entrare in contatto con me scrivendo a in oppure direttamente attraverso Twitter a Heat Bring Repo Informatica.
Due sono le cose più complesse dare il nome alle cose, invalidare la cash ci torneremo in una delle prossime puntate, ma oggi ci soffermiamo sul passaggio sull'azione che è quella di dare il nome alle cose prima di entrare nel vivo proprio tecnico delle regolette, le buone pratiche per dare e non me le cose.
Mi piacerebbe immaginare il programmatore come se fosse uno scrittore e nel mio immaginario vedo un Dante Alighieri che fare factoring o un manzoni che si occupa di scrivere le classi e farete test-drive design so un'immagine abbastanza simpatica perche' cito queste immagini simpatica perché in realtà dovremmo imparare dagli scrittori scrittori che per creare un personaggio fanno un'analisi uno studio quasi maniacale.
La stessa cosa noi dovremmo fare per realizzare le nostre classi, i nostri metodi nelle nostre funzioni, alle nostre variabili.
Andando un po' sulla rete ho beccato una delle note molto interessanti è un testo di george Orwell che si intitola russo ok, è che da una serie di regole detta una serie di buone pratiche agli scrittori su come appunto andare a scrivere i romanzi.
È il passaggio più importante che George orwell cita e', un passaggio che secondo me molto significativo.
Lui ci batte tantissimo su questo è il passaggio che dice che bisogna lasciare che il significato scelga le parole e non arrendersi e cedere alla parola stessa.
Quando scriviamo il nostro codice spesso ci viene di getto dare un nome a una variabile e spesso questo nome non è il nome migliore che può essere associato al significato e del caso.
Giorgio dice appunto di Nel momento in cui si dà un nome, una variabile, fermarsi un attimo, andare a identificare il vero significato e cercare la parola migliore che può descriverlo per farlo, lui suggerisce tutta una serie, poi di piccole regole.
Quindi non lasciarsi guidare dall'istinto nel buttare giù una parola, ma da quella parola, prendere il significato e cercare la parola migliore per poterlo rappresentare quel significato.
La prima regola che lui ci dà è quella di non usare metafore.
Le parole sono precise, indicano un elemento piuttosto che un altro e lo fanno in un modo molto puntuale.
Bene, per definirle la nostra variabile, la nostra classe, la nostra funzione, dobbiamo usare la parola perfetta, la parola che la rappresenta.
Lui ci suggerisce anche che se ci troviamo davanti a una parola lunga, una parola accorta, dobbiamo scegliere necessariamente la parola accorta.
E questo ritorna anche a noi nel nostro codice.
Sembra quasi che George Orwell fosse uno sviluppo attore.
Perché questo elemento ci ritorna quotidianamente? Perché basta immaginare le variabili lunghissime, le variabili brevi che però ci danno un significato immediato.
Quali preferiamo? Preferiamo senza dubbio i nomi di variabili brevi.
Perché? Perché a colpo d'occhio non riusciamo a estrapolare il significato un'altra cosa? George Orwell dice che se puoi tagliare una parola o eliminare una parola, toglila.
Immaginiamo alle nostre nomi, ai nostri nomi di variabili, di funzioni, di metodi, di classi composte.
Quante volte utilizziamo più parole per definirli? E quante volte queste più parole sono superflue? Possiamo strizzare, ridurre, eliminare delle parole che non ci aiutano a identificare quel concetto.
Bene, questa è una regola letteraria che sta insieme alle regole di George Orwell, ma che quotidianamente possiamo utilizzare nel nostro operato.
Lui inoltre ci dice sempre nel testo inning di non di preferire sempre la forma attiva la forma passiva, immaginiamo una variabile eletto al posto di di utilizzare una funzione leggere e poi lui ci suggerisce di non usare verbi basali.
Naturalmente George orwell queste regole le ha definite naturalmente per gli scrittori inglesi, però immaginiamo di dover usare di dover scegliere tra due e due fra due parole dormirci suo rifletterci qual è più semplice? Quale scegliereste voi? E' l'ultima regola appunto delle regole letterarie stabilite da George Orwell nelle è quello di evitare parole scientifiche o comunque fuori contesto.
E quando vendola ricondurre all'ambiente di sviluppo, mi viene in mente una cosa interessante quante volte cerchiamo utilizziamo delle parole fuori dalla logica di business fuori dalla logica di business che un po' confondono all'interno del nostro codice.
Bene, le parole scientifiche citate da George Orwell possono essere identificati in quello, cioè una parola che è completamente fuori contesto, che quindi risulta difficile per chi deve andare a programmare.
Perche' non riesce a decifrarla nel momento in cui sta sta usando quel codice che magari la scritta un'altra persona.
Beh, noi programmatori cosa facciamo? Certo, spesso ci dimentichiamo delle regole del buon nominare di George Orwell, tanto che l'altro giorno ho fatto un esperimento.
Ho provato a cercare sia fu che fu bar all'interno di per vedere quante istanze, quante righe di codice risultavano presenti.
All'interno di queste appunto famosi tour per l'archiviazione di deposito di Git è alla ricerca di fu.
Sono rimasto di stucco perché ho visto che ci sono cento settantaquattro milioni di istanze che si chiamano fu dove fu è una variabile, segna posto un nome segna posto un nome che non ha un significato.
Quindi il nostro lavoro dovremo fermarci un pochino di piu' e ragionare un pochino di più sui nomi delle variabili.
Anche perché in realtà, se pensiamo al nostro codice, dobbiamo prendere in considerazione il fatto che il codice e' scritto per gli uomini e non per i compilatori gli interpreti.
Quindi il codice di per sé è uno strumento per comunicare.
Noi dobbiamo partire da questo presupposto.
Possiamo comunicare agli altri che sono membri del nostro team o le persone che lavorano allo stesso progetto open source, oppure il nostro cliente che deve poter leggere il nostro codice.
Ma dobbiamo anche comunicare al noi stessi, a noi stessi il noi stesso, che poi dovrà prendere il codice tra quattro mesi e dovra' capirci.
Quindi migliori sono i nomi che utilizziamo nel nostro codice migliore sarà la qualità del codice.
Anche perché in realtà, quando parliamo di codice complicato, non stiamo parlando di una complessità altissima.
Solitamente, quando si parla di codice complicato, se parla di codice implicito dove i nomi delle variabili i concetti non sono identificabili.
A prima occhiata, quindi, quando mi trovo davanti a un blocco di codice implicito di primo proprio di primo colpo a livello empatico, la prima cosa che vedo è che un codice complicato.
Poi magari il codice fa un'operazione banalissima.
Però ho davanti un codice complicato solo perché è implicito.
In realtà il codice dovrebbe spiegarsi da solo i nomi delle variabili dovrebbero essere delle classi e dei metodi e funzioni, e dovrebbero essere talmente eloquenti da non avere necessità di commenti.
Nessun commento di sorta e qua mi viene in mente il un capitolo di di Bobby Martin Boyd Martin ha scritto un bellissimo libro.
Si chiama suggerisco a tutti gli sviluppatori almeno chi non lo avesse fatto perché credo che l'ottanta per cento è novanta percento degli sviluppatori abbiano letto quel libro di leggerlo.
È uno dei primi capitoli, anzi, direi il primo vero capitolo ufficioso, dove della sostanza parla appunto di come dare il nome alle variabili.
E lui utilizza una serie di esempi per raccontare i casi limite e le best practices da utilizzare bene.
La prima best practices che ancor Bobo racconta è che suggerisce è quella di evitare la disinformazione, scegliendo appunto un nome giusto, un nome legato al significato.
Nelle nostre variabili, diciamo, riusciamo in qualche modo a dare l'informazione precisa, puntuale per poter identificare il suo contenuto un'altra, cosa che racconta nel primo capitolo e che suggerisce quella di utilizzare dei nomi impronunciabili.
E lui fa un esempio molto, molto interessante.
Racconta di aver lavorato in un blocco di codice dove la data di generazione si chiamava Jen Y M D H M n e Qualcos'altro.
No.
Allora che cosa Che cosa dice questo nome semplicemente dalla data i no in anni, mesi, giorni, ore, minuti, secondi della generazione di un certo dato? Beh, il nome potrebbe anche in qualche modo raccontare di cosa si tratta in realtà c'è.
Un altro problema su questo nome, però di per sé è un nome impronunciabile.
Immaginate di andare all'anagrafe, registrare vostro figlio e chiamarlo ad una roba del genere sarebbe impossibile.
Puoi chiamarlo durante durante la vita normale e quindi cosa succederebbe? Probabilmente si eviterebbe di chiamarlo, si userebbe un altro nome o comunque ci sarebbe una non comprensione nel processo comunicativo.
Un altro suggerimento che dà ancora Bobby nel suo libro è quello di suggerire dei nomi ricercabili.
Immaginiamo di dare il nome della nostra variabile.
È nel momento in cui io devo utilizzare le funzioni di ricerca perché voglio vedere idee le informazioni relative a quella variabile e scrivo è nella casellina di ricerca probabilmente mi evidenzia qualunque cosa ci sta su quel file.
Bene.
Se invece do un nome concreto, un nome che ha un significato, un nome ricercabile nel mio codice, beh diventa più facile anche intera a girarci.
Lui suggerisce inoltre anche di evitare le codifiche quante volte utilizziamo delle sigle che comunque vanno decodificata e beh, il processo di decodifica presuppone comunque uno sforzo mentale se state già facendo un ragionamento nel leggere e provare a capire qual è il processo della vostra applicazione, quindi magari avete scritto questa applicazione due mesi fa oppure siete dei delle new entry nel team? State provando a capire il flop delle delle dell'applicazione e vedete queste sigle dovette interrompere la comprensione del flop per andare a decodificare queste sigle e questo diventa comunque una sorta di interruzione nel processo di ragionamento.
È comunque un ostacolo che possiamo evitare a priori evitando le sigle.
Sempre parlando di sigle o comunque di nomi che hanno degli elementi che potrebbero essere omessi, mi viene in mente anche la notazione ungherese cosa prevedeva la notazione ungherese, che era una notazione utilizzata nei vecchi linguaggi di programmazione a partire dal forte e prevedeva il fatto che nel nome della variabile in qualche modo venisse indicato il tipo no.
Quindi se il nome della variabile conteneva da una parte il significato, dall'altra il tipo.
Ma questa operazione è superflua nei con i moderni editor.
Questo perché moderni editors e tu evidenzi il valore e il valore o lo non la variabile stessa.
Saranno loro a dirti di che tipo si tratta e se dovessi farvi un parallelismo, mi viene da pensare immaginate di chiamare vostro figlio Mario italiano o Mario persona o Mario uomo gia' non c' è bisogno di andare indicare il tipo non serve il superfluo, basta il nome e poi il resto lo dal contesto un'altra cosa molto importante è quella di evitare prefissi o suffissi, oppure delle variabili mono, come vi ho detto prima, non quando vi ho parlato delle variabili ricercabili le variabili mono lettera a è molto difficile passare un significato con una sola lettera e poi immaginate di chiamare una persona a o è.
Inoltre vi devo però anche ammettere che ci sono per tradizione delle situazioni dove le variabili mono sono utili.
Queste variabili mono sono utili per esempio, dove vengono utilizzate per convenzione.
Mi viene in mente il ciclo for dove abbiamo appunto la variabile.
Tutti i programmi sanno viva la variabile che contiene, appunto la reiterazione.
Tutti sanno che indica quello chiunque programmi è cosciente di quella informazione, quindi la necessità è quella di dare appunto dei nomi parlanti.
Queste sono diciamo alcune delle regole che ha indicato il suo libro.
In realtà ce ne sarebbero tante altre, però se già partissimo, cercando di rispettare il più possibile queste regolette e cercando di ricordarci quello che ha scritto george orwell nelle nei, sicuramente faremmo e' un codice decisamente migliori di quello che quotidianamente facciamo.
Io sono sicuro che voi siete dei bravissimi programmatori e probabilmente non avete bisogno di queste regole.
Te però io ogni tanto anche per me stesso al riguardo, perché spesso preso dal di programmazione.
Beh, qualcosina me la dimentico pure.
Mi faccio rapire dalle parole come dice george orwell, e tralascio i significati.
Beh, e capita non possiamo essere sempre al massimo della concentrazione o comunque focalizzati solo col nemico.
In quel caso beh, dovremmo comportarci un po' come i boy scout.
Nel momento in cui prendiamo in mano il codice, dovremmo provare a lasciare quello che prendiamo in mano.
Un pochino più pulito un pochino più ordinato, un pochino più comprensibile di come lo abbiamo trovato, anche perché oggi rinominare le variabili diventa sempre più semplice.
Con tool come php storm è possibile, utilizzando le funzioni dire factoring, rinominare grandi lotti di variabili senza rischiare tantissimo.
E poi se si è sviluppato usando un approccio a testa driven design, beh, a quel punto basta lanciare la propria suite di testa, vedere se fallisce o se va in porto per capire se si è distrutto qualcosa.
Però prima di lasciarvi, mi piacerebbe evidenziare anche questo passaggio nella scrittura, nella definizione dei nomi delle variabili dobbiamo anche possibilmente evitare di di di fare i simpatici perché martin dice nel suo libro appunto che gli è capitato di leggere delle funzioni del leeds chiamate con nomi del tipo super mega bomba distruttiva.
Questo è il nome di una funzione che deve andare eliminare qualcosa va bene, siamo a chiamare una funzione in questo modo, però diciamo che non siamo il massimo della chiarezza.
Detto questo, vi dico che appunto utilizzando un minimo dire factoring e le nuove funzioni di ridenominazione dei nostri editor, beh, probabilmente ridurre vuoi vuota fax per minuti, quindi aumenteremo l'indice di qualità del nostro codice e anche per oggi è tutto nelle puntate a partire da questa cercherò di alleggerirti un po' di più perché mi sono reso conto nelle puntate precedenti mezz'ora di Mauro che parla.
Forse erano un pochino pesante, quindi cercheremo di essere un pochino più leggeri, ma senza ridurre o sacrificare il significato.
Anche per oggi è tutto da una vi ricordo che se vi fa piacere trovati utile questo podcast.
Potete iscrivervi con il vostro client di podcast direttamente appunto cliccando sul pulsantino più in modo da ricevere ogni settimana la nuova puntata le notifiche pulsioni.
Se vi fa piacere potete contattarmi all'indirizzo email in oppure di' a twitter a heat Brian repo.
Per il resto non so cosa dirvi.
Non ha ancora deciso l'argomento della prossima del prossimo episodio, ma sarà sicuramente una cosa interessante, un saluto né da Lione e alla prossima settimana bar il circolo dei full stack e' bello.
Per una volta a settimana ci troviamo davanti a due birre e compra il ceppo.
Parliamo linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi di Fury
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄