Michele Andrighetti

Categoria: Excel

  • Separare logica, parametri e output: una piccola architettura per Excel

    Un file Excel spesso nasce in modo molto semplice: alcuni dati, qualche formula, un risultato.

    Poi cresce.

    Arrivano nuovi casi da gestire, eccezioni, percorsi di rete, soglie, anagrafiche, query Power Query, macro VBA. A quel punto il problema non è necessariamente che il file sia diventato grande. Il problema è che dati, configurazione, logica e risultati iniziano a confondersi.

    Una buona struttura non richiede di trasformare Excel in un’applicazione complessa. Spesso basta separare chiaramente alcuni ruoli.

    Quattro cose diverse

    In un workbook sufficientemente evoluto distinguerei almeno quattro livelli:

    • Dati — ciò che il file deve elaborare: transazioni, letture, file importati, movimenti, registrazioni.
    • Parametri e anagrafiche — descrivono il contesto in cui la logica deve operare: periodo di riferimento, percorsi, codici ammessi, associazioni, soglie, eccezioni.
    • Logica — trasforma e interpreta i dati attraverso formule, Power Query, VBA o una combinazione dei tre.
    • Output — ciò che interessa davvero all’utente: un risultato, una quadratura, un elenco di anomalie, un file da produrre.
    Dati + Parametri / Anagrafiche → Logica → Controlli → Output

    La distinzione sembra quasi ovvia. Nella pratica, però, molti problemi di manutenzione nascono proprio quando questi quattro elementi vengono mescolati.

    Un esempio molto piccolo

    Supponiamo di dover controllare dei movimenti relativi a un determinato periodo.

    Potremmo scrivere direttamente nelle formule:

    2026
09
1000
C:\Dati\Produzione\

    Il file funziona.

    Ma quei valori non appartengono alla logica. Sono parametri della logica.

    È molto diverso poter scrivere concettualmente:

    AnnoRiferimento
MeseRiferimento
SogliaControllo
CartellaDati

    A quel punto una modifica del contesto non richiede più una modifica dell’algoritmo.

    È la stessa distinzione che abbiamo incontrato parlando di intervalli nominati e di tabelle di configurazione, ma vista a un livello più generale.

    La logica dovrebbe cambiare meno dei dati

    Questo, per me, è uno dei segnali più utili per capire se un workbook è ben progettato.

    • I dati possono cambiare ogni giorno.
    • I parametri possono cambiare ogni mese.
    • Le anagrafiche possono acquisire nuove righe.

    La logica dovrebbe cambiare molto meno frequentemente.

    Se l’arrivo di un nuovo codice, di una nuova cartella o di una nuova eccezione obbliga a modificare una formula, una query o una macro, vale la pena chiedersi se quel nuovo caso non avrebbe dovuto essere rappresentato come dato.

    Non significa rendere tutto configurabile. Significa evitare di incorporare nella logica ciò che appartiene al dominio dei dati.

    Anche l’output va separato

    C’è un’altra separazione che trovo importante.

    Il foglio che l’utente consulta non dovrebbe necessariamente essere il luogo in cui avvengono tutte le elaborazioni.

    Un output può essere molto semplice:

    Stato Elemento Anomalia
    OK A
    KO B Codice non riconosciuto
    OK C

    Dietro quelle tre colonne possono esserci importazioni, join, controlli e trasformazioni molto più articolati.

    È una buona cosa.

    La complessità interna non deve necessariamente diventare complessità dell’interfaccia.

    Formule, Power Query e VBA possono condividere la stessa architettura

    Separare i ruoli aiuta anche a evitare una falsa contrapposizione tra strumenti.

    • una tabella Excel può contenere l’anagrafica;
    • un intervallo nominato può contenere il periodo scelto dall’utente;
    • Power Query può leggere entrambi e trasformare i dati;
    • una formula può effettuare un controllo immediato sull’output;
    • VBA può orchestrare aggiornamento, esportazione e gestione dei file.

    Non è necessario scegliere uno strumento per tutto.

    L’importante è che ciascuno abbia un compito comprensibile.

    Una struttura che rende visibili le responsabilità

    Non esiste una suddivisione dei fogli valida universalmente, ma trovo utile che anche i nomi rendano riconoscibile la struttura.

    Per esempio:

    0. Config
1. Input
2. Anagrafiche
3. Elaborazione
4. Controlli
5. Output

    Non è la numerazione a essere importante.

    È il fatto che, aprendo il file, sia possibile capire rapidamente dove si configura, dove entrano i dati, dove avvengono i controlli e dove si leggono i risultati.

    Lo stesso principio può essere applicato alle query Power Query e alle procedure VBA.

    La separazione aiuta anche a diagnosticare gli errori

    Quando qualcosa non torna, una struttura del genere permette di formulare domande più precise.

    • Il dato di partenza è corretto?
    • Il parametro utilizzato è quello previsto?
    • L’anagrafica contiene il valore?
    • La trasformazione ha prodotto il risultato atteso?
    • L’output lo rappresenta correttamente?

    Senza questa separazione, spesso l’unica domanda possibile è: “Perché il file non funziona?”

    Ed è una domanda molto più difficile.

    Non serve costruire un framework

    C’è anche un rischio opposto: progettare una struttura talmente astratta da rendere difficile un file che avrebbe potuto essere semplice.

    Un workbook usato una volta per confrontare due elenchi probabilmente non ha bisogno di sei livelli, una configurazione centralizzata e una convenzione di naming.

    La struttura acquista valore quando il file deve essere riutilizzato, modificato, affidato ad altri o mantenuto nel tempo.

    Anche qui, quindi, la complessità della soluzione dovrebbe essere proporzionata al problema.

    Un file Excel può avere un’architettura

    La parola architettura può sembrare eccessiva parlando di un foglio di calcolo.

    Ma non implica necessariamente classi, framework o grandi applicazioni.

    Significa semplicemente decidere quali parti del sistema hanno responsabilità diverse e quali dipendenze vogliamo creare tra loro.

    Quando questa distinzione è chiara, Excel rimane Excel, ma il file smette gradualmente di essere un insieme di celle che funzionano per diventare uno strumento che può evolvere senza dover essere continuamente riscritto.

  • RIDUCI non serve solo a ridurre: costruire risultati iterativi in Excel

    Il nome RIDUCI suggerisce un’operazione molto precisa: prendere molti valori e ricondurli a qualcosa di più piccolo. Una somma, un massimo, una concatenazione.

    È certamente uno dei suoi utilizzi. Ma non è ciò che rende RIDUCI particolarmente interessante.

    Il concetto centrale è l’accumulatore: a ogni iterazione la funzione riceve il risultato costruito fino a quel momento e può trasformarlo ulteriormente. Nulla impone che quel risultato diventi più piccolo. Può anche crescere.

    Un accumulatore che costruisce

    Immaginiamo di partire da una stringa vuota. Alla prima iterazione aggiungiamo un carattere, alla seconda un altro, poi un altro ancora:

    "" → "╦" → "╦═" → "╦═╗" → ...

    RIDUCI permette di esprimere proprio questa successione. Il valore restituito da un passaggio diventa l’ingresso del successivo.

    Questo cambia il modo di guardare alla funzione: non soltanto aggregazione, ma costruzione progressiva di uno stato.

    Prova il generatore

    Modifica le dimensioni e genera una nuova griglia. Nel foglio Excel gli stessi valori possono essere esposti come parametri tramite intervalli nominati.

    Un esempio meno convenzionale: costruire un labirinto

    Un caso che rende evidente questo comportamento è la costruzione di una matrice composta da caratteri Unicode che rappresentano segmenti e incroci di un labirinto.

    Disponiamo di una tabella T_Lab. Per ogni carattere sono indicate le connessioni disponibili nelle quattro direzioni: sinistra, sopra, destra e sotto. La tabella diventa quindi una piccola anagrafica delle tessere utilizzabili.

    La matrice viene costruita da sinistra a destra e dall’alto verso il basso. Quando dobbiamo scegliere un nuovo carattere, conosciamo già due informazioni: ciò che si trova alla sua sinistra e ciò che si trova sopra.

    Il nuovo elemento deve essere compatibile con entrambi.

    Lo stato contiene già ciò che serve

    Qui entra in gioco l’accumulatore. Invece di contenere un totale numerico, contiene tutti i caratteri scelti fino a quel momento.

    Per ogni posizione k ricaviamo riga e colonna. Dall’accumulatore recuperiamo il carattere precedente, quando esiste, e quello posto una riga sopra. Attraverso T_Lab possiamo conoscere le rispettive aperture verso destra e verso il basso.

    Queste diventano i vincoli per la tessera successiva.

    =LET(
    nR;numRighe;
    nC;numColonne;
    Tot;nR*nC;

    str;
    REDUCE(
        "";
        SEQUENZA(Tot);
        LAMBDA(acc;k;
            LET(
                r;INT((k-1)/nC)+1;
                c;RESTO(k-1;nC)+1;

                chSx;SE(c=1;"";STRINGA.ESTRAI(acc;k-1;1));
                chSp;SE(r=1;"";STRINGA.ESTRAI(acc;k-nC;1));

                sx;SE(
                    c=1;
                    FALSO;
                    CERCA.X(
                        chSx;
                        T_Lab[Carattere UNI];
                        T_Lab[Destra];
                        FALSO
                    )
                );

                sp;SE(
                    r=1;
                    FALSO;
                    CERCA.X(
                        chSp;
                        T_Lab[Carattere UNI];
                        T_Lab[Sotto];
                        FALSO
                    )
                );

                chiusuraFinale;
                SE(
                    E(r=nR;c=nC-1);
                    T_Lab[Destra]=
                        CERCA.X(
                            STRINGA.ESTRAI(acc;k-nC+1;1);
                            T_Lab[Carattere UNI];
                            T_Lab[Sotto];
                            FALSO
                        );
                    VERO
                );

                candidati;
                FILTRO(
                    T_Lab[Carattere UNI];
                    (T_Lab[Sinistra]=sx)*
                    (T_Lab[Sopra]=sp)*
                    SE(c=nC;T_Lab[Destra]=FALSO;1)*
                    SE(r=nR;T_Lab[Sotto]=FALSO;1)*
                    chiusuraFinale*
                    (T_Lab[Controllo]=VERO)
                );

                scelto;
                SE.ERRORE(
                    INDICE(
                        candidati;
                        CASUALE.TRA(1;RIGHE(candidati))
                    );
                    " "
                );

                acc&scelto
            )
        )
    );

    MAKEARRAY(
        nR;
        nC;
        LAMBDA(rr;cc;
            STRINGA.ESTRAI(
                str;
                (rr-1)*nC+cc;
                1
            )
        )
    )
)

    Perché RIDUCI e non SCAN?

    Una prima versione di questa formula utilizzava SCAN. Funzionava, ma conservava tutti gli stati intermedi della costruzione.

    Alla fine era quindi necessario estrarre l’ultimo elemento prodotto, perché era l’unico che ci interessava realmente.

    RIDUCI esprime meglio il problema: ogni stato serve per calcolare il successivo, ma ciò che vogliamo ottenere è soltanto lo stato finale.

    La differenza non è soltanto sintattica. Scegliere tra SCAN e RIDUCI significa chiedersi se gli stati intermedi facciano parte del risultato oppure siano soltanto passaggi necessari per arrivarci.

    Un dettaglio ai bordi che cambia il risultato

    La prima versione aveva anche un difetto interessante.

    Controllava la compatibilità con ciò che era già stato costruito, quindi sinistra e sopra, ma non imponeva che una tessera posta sull’ultima colonna fosse chiusa verso destra o che una tessera sull’ultima riga fosse chiusa verso il basso.

    Il risultato poteva quindi essere localmente coerente e, allo stesso tempo, lasciare un percorso idealmente aperto oltre il bordo della matrice.

    I due controlli aggiuntivi:

    SE(c=nC;T_Lab[Destra]=FALSO;1)
SE(r=nR;T_Lab[Sotto]=FALSO;1)

    risolvono quasi tutto, ma durante i test è emerso un caso più sottile: l’angolo in basso a destra può diventare impossibile da completare. Con le tessere utilizzate, quell’ultima posizione può chiudersi soltanto se riceve zero connessioni oppure due connessioni; una sola apertura proveniente da sinistra o dall’alto non ha una tessera terminale corrispondente.

    La prima tentazione potrebbe essere introdurre un backtracking: tornare indietro e cambiare una scelta precedente. In questo caso, però, non serve.

    La penultima scelta può garantire l’ultima

    Quando arriviamo alla penultima cella dell’ultima riga, la cella sopra l’angolo finale è già stata costruita. Conosciamo quindi già se essa apre verso il basso.

    Basta imporre che la penultima tessera apra verso destra esattamente nello stesso modo:

    B[Destra] = A[Sotto]

    La variabile chiusuraFinale esprime questo vincolo:

    chiusuraFinale;
SE(
    E(r=nR;c=nC-1);
    T_Lab[Destra]=
        CERCA.X(
            STRINGA.ESTRAI(acc;k-nC+1;1);
            T_Lab[Carattere UNI];
            T_Lab[Sotto];
            FALSO
        );
    VERO
);

    Così l’ultima cella riceve necessariamente due stati uguali: FALSO/FALSO, che può diventare uno spazio, oppure VERO/VERO, che può diventare ╝. Non occorre tornare indietro: è sufficiente usare lo stato già costruito per rendere valida la scelta corrente.

    Questo passaggio rende più preciso un concetto importante: l’accumulatore non contiene soltanto il risultato parziale. Può contenere anche le informazioni necessarie per garantire che la costruzione possa proseguire correttamente.

    Anche il vuoto deve occupare una posizione

    Un altro dettaglio emerso nei test riguarda la tessera senza connessioni. In T_Lab[Carattere UNI] non deve essere una cella realmente vuota, ma contenere un carattere spazio.

    L’accumulatore è infatti una stringa nella quale ogni posizione della matrice deve corrispondere esattamente a un carattere. Se una tessera vuota aggiungesse zero caratteri, la lunghezza dell’accumulatore non coinciderebbe più con il numero di celle elaborate e i successivi STRINGA.ESTRAI leggerebbero i vicini sbagliati.

    È un dettaglio tecnico, ma esprime bene una regola più generale: quando la posizione fa parte dello stato, anche l’assenza di contenuto deve avere una rappresentazione.

    È davvero un labirinto?

    Non necessariamente, almeno nel significato algoritmico più rigoroso del termine.

    La formula costruisce una matrice di tessere compatibili. Non garantisce, da sola, che esista un percorso tra due punti, che tutte le zone siano raggiungibili o che tra due celle esista un solo cammino.

    Chiamarlo “labirinto” descrive bene il risultato visivo, ma è utile distinguere l’aspetto grafico dalle proprietà che dovrebbe garantire un vero algoritmo di generazione di labirinti.

    Anche questo limite rende l’esempio interessante: una formula può rispettare perfettamente tutte le regole locali senza garantire automaticamente una proprietà globale.

    Il punto non è il labirinto

    Il labirinto è soprattutto un modo visibile per osservare RIDUCI al lavoro.

    Lo stesso schema compare ogni volta che il risultato di un passaggio deve diventare parte del contesto utilizzato dal passaggio successivo. L’accumulatore può essere un numero, un testo, un array o una struttura progressivamente più ricca.

    È qui che RIDUCI diventa più interessante di quanto suggerisca il suo nome.

    Non dobbiamo necessariamente chiederci: come riduco questi valori?

    Possiamo chiederci invece: quale stato voglio costruire, passo dopo passo?

  • Validare i dati prima di elaborarli

    Una formula può essere corretta. Una query può funzionare senza errori. Una macro può arrivare regolarmente alla fine.

    E il risultato può comunque essere sbagliato.

    Il problema, in molti casi, non è nella logica che elabora i dati, ma nei dati che quella logica ha ricevuto.

    Per questo, in un file destinato a essere utilizzato nel tempo, la validazione non dovrebbe essere un controllo aggiunto alla fine. Dovrebbe essere parte del processo.

    Un dato sconosciuto non è necessariamente un dato vuoto

    Supponiamo di utilizzare un’anagrafica per associare una categoria a un codice.

    Arriva un nuovo codice che non è ancora presente nell’anagrafica. La ricerca non trova corrispondenza.

    È molto comodo intercettare l’errore e restituire una stringa vuota, uno zero o una categoria predefinita. Il foglio rimane pulito e le elaborazioni successive continuano a funzionare.

    Ma abbiamo perso un’informazione importante: è comparso un caso che il nostro sistema non conosce.

    Nascondere l’errore non significa averlo gestito.

    Le anagrafiche possono diventare anche regole di controllo

    Nel momento in cui separiamo la logica dalle anagrafiche, come visto nell’articolo precedente, quelle stesse tabelle possono assumere una seconda funzione.

    Non servono soltanto a dire che al codice X corrisponde la descrizione Y. Possono anche definire quali codici il sistema conosce e sa elaborare.

    Un codice non presente nell’anagrafica diventa quindi un’anomalia da evidenziare, non necessariamente un errore da nascondere.

    È una differenza piccola nell’implementazione, ma importante nel modo di progettare il file.

    Anche un’anagrafica può essere sbagliata

    Validare i dati in ingresso non basta.

    Supponiamo che una tabella di supporto debba contenere una sola riga per ciascun codice. Se qualcuno inserisce accidentalmente lo stesso codice due volte, una ricerca che presuppone una relazione univoca può produrre un risultato inatteso.

    Il dato sorgente è corretto. La formula è corretta. È l’anagrafica ad avere violato una regola.

    Per questo alcuni controlli dovrebbero riguardare anche le strutture utilizzate per controllare gli altri dati: chiavi duplicate, campi obbligatori mancanti, intervalli di validità sovrapposti o combinazioni che non dovrebbero esistere.

    Non tutti i vuoti sono uguali

    Una cella vuota può significare molte cose.

    Il dato non è stato compilato. Non è disponibile. Non è previsto per quel tipo di record. Deve ancora essere calcolato. Oppure rappresenta perfettamente una condizione ammessa.

    Trattare tutti questi casi nello stesso modo è rischioso.

    Prima di sostituire automaticamente un valore mancante con zero, "" o un valore predefinito, conviene chiedersi se l’assenza del dato sia prevista dalla logica oppure rappresenti qualcosa che deve essere verificato.

    Lo zero, il valore vuoto e il valore sconosciuto non sono necessariamente sinonimi.

    Le regole possono dipendere dal contesto

    Non sempre è sufficiente controllare una singola colonna.

    Un valore può essere perfettamente valido preso da solo e diventare impossibile quando viene associato a un altro.

    Un certo tipo di operazione può ammettere solo alcuni stati. Una categoria può essere utilizzabile soltanto con determinati codici. Un record può essere valido oggi ma non esserlo rispetto alla data a cui si riferisce l’elaborazione.

    La validazione diventa quindi progressivamente più interessante quando passa dal semplice controllo del valore al controllo della coerenza tra valori.

    Controllare prima, non spiegare dopo

    C’è una differenza sostanziale tra scoprire un’anomalia prima di produrre il risultato e trovarla quando qualcuno si accorge che un totale non torna.

    Nel secondo caso bisogna risalire all’origine del problema attraversando tutte le trasformazioni che il dato ha subito.

    Nel primo possiamo fermarci molto prima: dato → controllo → elaborazione, anziché dato → elaborazione → risultato anomalo → ricerca della causa.

    Non significa necessariamente bloccare tutto al primo problema. In molti casi è più utile produrre una tabella delle anomalie e lasciare che il processo distingua ciò che può essere elaborato da ciò che richiede attenzione.

    Rendere visibili le anomalie

    Un buon controllo non dovrebbe limitarsi a dire che “qualcosa non va”.

    Se possibile dovrebbe permettere di capire quale record ha generato l’anomalia, quale regola non è stata rispettata, quale valore l’ha provocata e se il problema impedisce l’elaborazione oppure è soltanto una segnalazione.

    Questo approccio è particolarmente utile con Power Query, dove i controlli possono confluire in una tabella dedicata, ma lo stesso principio può essere applicato con formule Excel o VBA.

    La tecnologia cambia. Il principio no.

    Non serve controllare tutto

    Aggiungere controlli a ogni passaggio può rendere una soluzione pesante quanto non averne nessuno.

    La validazione dovrebbe concentrarsi sui punti in cui un dato inatteso potrebbe produrre un risultato formalmente valido ma sostanzialmente sbagliato.

    È qui che il controllo ha il valore maggiore.

    Un errore evidente tende a farsi trovare. Un numero plausibile, prodotto partendo da un presupposto sbagliato, può invece attraversare indisturbato tutto il processo.

    Per questo, tra un foglio che nasconde elegantemente ogni anomalia e uno che segnala chiaramente ciò che non riconosce, preferisco il secondo.

    Meglio un’anomalia esplicita che un risultato apparentemente corretto.

  • Dare un nome ai dati: gli intervalli nominati sono più utili di quanto sembrino

    In molte formule Excel i riferimenti raccontano dove si trova un valore, ma non che cosa rappresenta. $F$2 identifica perfettamente una cella; non dice però perché quella cella sia importante.

    Un nome può cambiare il modo in cui leggiamo la stessa formula. Se $F$2 contiene un’aliquota, usare un nome come AliquotaIVA rende esplicito il significato del dato e separa il concetto dalla sua posizione nel foglio.

    Un riferimento non è un significato

    Gli intervalli nominati sono una funzionalità storica di Excel, ma spesso rimangono poco utilizzati. L’idea di base è semplice: assegnare un nome a una cella o a un intervallo e utilizzare quel nome al posto del riferimento tradizionale.

    La differenza diventa evidente quando il valore rappresenta un parametro. Una formula che contiene $B$3 richiede di sapere cosa si trova in B3. Una formula che contiene PeriodoDiRiferimento porta parte della propria documentazione direttamente nel calcolo.

    Dove sono particolarmente utili

    I nomi funzionano bene per quei valori che hanno un significato stabile ma possono cambiare nel tempo: date di riferimento, soglie, percentuali, percorsi, modalità operative o altri parametri di configurazione.

    In questi casi il vantaggio non è evitare di scrivere un riferimento assoluto. È poter modificare il valore in un punto riconoscibile mantenendo invariata la logica che lo utilizza.

    Non sostituiscono le tabelle

    Un nome e una tabella strutturata risolvono problemi diversi. Se devo gestire un singolo parametro, un nome può essere molto efficace. Se devo mantenere un elenco di codici, categorie, associazioni o valori validi, una tabella è normalmente una rappresentazione più naturale.

    La combinazione dei due strumenti è spesso più utile della scelta esclusiva dell’uno o dell’altro: parametri singoli identificati da nomi chiari e anagrafiche organizzate in tabelle strutturate.

    Lo stesso parametro oltre le formule

    Un aspetto interessante è che un nome può diventare un punto di collegamento tra parti diverse della soluzione. Un parametro definito nel foglio può essere letto da Power Query e può essere recuperato anche da VBA.

    Questo consente, per esempio, di scegliere un periodo o un percorso in Excel e utilizzare lo stesso valore per governare una query o una procedura. Il foglio diventa così una piccola interfaccia di configurazione, mentre la logica rimane altrove.

    Nomi locali e nomi della cartella

    Excel permette di definire nomi validi per l’intera cartella oppure limitati a un singolo foglio. È una distinzione che può sembrare secondaria finché il file è piccolo, ma diventa importante quando la struttura cresce.

    Un parametro condiviso dovrebbe essere riconoscibile come tale. Un nome locale può invece avere senso quando il suo significato appartiene esclusivamente a un foglio. Anche qui la scelta dovrebbe rendere più evidente la struttura, non semplicemente evitare qualche riferimento di cella.

    Anche i nomi possono diventare debito tecnico

    Assegnare un nome a tutto non rende automaticamente un file più leggibile. Nomi generici, abbreviazioni difficili da interpretare, duplicazioni o definizioni rimaste dopo modifiche successive possono creare un livello di complessità poco visibile.

    Il Gestore nomi diventa quindi parte della manutenzione della cartella: i nomi dovrebbero essere pochi quanto basta, descrittivi e coerenti. Se per capire una formula bisogna prima decifrare dieci nomi poco significativi, il vantaggio è andato perso.

    Un piccolo cambio di prospettiva

    Gli intervalli nominati vengono spesso presentati come una comodità per scrivere formule. Il loro valore maggiore, però, emerge quando li consideriamo uno strumento di progettazione.

    Dare un nome a un parametro significa dichiarare che quel valore ha un ruolo nella soluzione. E quando una cartella deve durare nel tempo, distinguere chiaramente i dati, i parametri e la logica che li utilizza è spesso più importante di rendere una formula qualche carattere più corta.

  • Parametri e anagrafiche: far evolvere un file senza riscriverlo

    Molti file Excel invecchiano non perché le formule smettono di funzionare, ma perché cambiano le casistiche che quelle formule devono conoscere.

    Arriva una nuova categoria, cambia una corrispondenza, viene aggiunto un codice, una voce non è più valida. Se queste informazioni sono scritte direttamente dentro formule, query o macro, ogni variazione richiede una modifica strutturale. Spesso non è necessario.

    Separare la regola dai suoi parametri

    Una soluzione più robusta consiste nel distinguere la logica applicativa dalle informazioni che possono cambiare. La formula stabilisce come deve essere trattato un dato; una tabella di appoggio stabilisce quali valori, codici o corrispondenze sono validi in quel momento.

    È una distinzione semplice, ma cambia molto la manutenzione del file. Aggiungere una nuova casistica può diventare l’inserimento di una riga in una tabella invece della modifica di una formula complessa.

    Le anagrafiche come parte della soluzione

    Una tabella Excel è un ottimo contenitore per piccole anagrafiche operative: codici e descrizioni, classificazioni, associazioni tra valori, soglie, stati ammessi, percorsi, parametri o eccezioni note.

    Il vantaggio non è soltanto tecnico. Le informazioni diventano visibili, filtrabili e modificabili senza dover interpretare la logica che le utilizza. E una tabella strutturata si espande automaticamente quando vengono aggiunte nuove righe, evitando intervalli fissi da ricordare e aggiornare.

    Un esempio molto semplice

    Immaginiamo di dover attribuire una categoria a una serie di codici. Una soluzione immediata potrebbe incorporare le corrispondenze nella formula attraverso una sequenza di condizioni. Funziona, finché le categorie sono poche e stabili.

    Se invece le corrispondenze vengono raccolte in una tabella con colonne Codice e Categoria, la formula può limitarsi a cercare il codice. Quando compare una nuova casistica, non cambia la formula: cambia l’anagrafica.

    Parametri, non costanti nascoste

    Lo stesso principio vale per valori che spesso finiscono dispersi nelle formule: una data di riferimento, una soglia, un numero di mesi da analizzare, il nome di un ambiente, un percorso o una modalità di elaborazione.

    Se un valore è destinato a cambiare, trattarlo come parametro rende esplicita la sua funzione e riduce il rischio che la stessa costante venga scritta in più punti. Il parametro può vivere in una cella nominata, in una tabella di configurazione o, quando serve, essere letto anche da Power Query o VBA.

    Una sola informazione, più strumenti

    Questo approccio diventa particolarmente utile nei file che combinano formule, Power Query e VBA. Una tabella di configurazione può diventare il punto comune da cui strumenti diversi ricavano le stesse informazioni.

    In questo modo non occorre mantenere, per esempio, un elenco nella formula, una seconda copia nella query e una terza nel codice VBA. La logica può essere diversa, ma l’anagrafica rimane una sola.

    Dinamico non significa senza controllo

    Rendere modificabili parametri e anagrafiche non significa necessariamente esporli a tutti. In un file destinato a utenti operativi, le tabelle di configurazione possono essere raccolte in un foglio dedicato, documentate e, se opportuno, protette dalle modifiche accidentali.

    È utile anche prevedere controlli: valori obbligatori, duplicati non ammessi, date di validità o segnalazioni per codici non presenti nell’anagrafica. La facilità di aggiornamento non deve trasformarsi in assenza di regole.

    Il vantaggio più concreto

    La vera differenza emerge dopo mesi, quando arriva una nuova casistica. Se per gestirla occorre capire dove sia nascosta dentro una formula, una query o una macro, il file dipende ancora da chi lo ha costruito.

    Se invece basta aggiungere o modificare una riga nell’anagrafica corretta, l’aggiornamento diventa un’operazione ordinaria. La logica rimane stabile e ciò che cambia nel tempo viene trattato per quello che è: un dato.

  • Quando una formula è diventata troppo complessa?

    In Excel è facile accorgersi quando una formula è sbagliata. È molto più difficile accorgersi quando una formula corretta è diventata una cattiva soluzione.

    Succede soprattutto nei file che crescono nel tempo. Una prima esigenza viene risolta con una formula, poi arriva un’eccezione, poi un’altra condizione, poi una nuova sorgente dati. Ogni modifica è ragionevole presa da sola. Il risultato finale può non esserlo più.

    La complessità non si misura in caratteri

    Una formula lunga non è necessariamente complessa e una formula corta non è necessariamente semplice. LET, per esempio, può allungare una formula introducendo nomi intermedi e allo stesso tempo renderne molto più chiara la struttura. Al contrario, una sequenza compatta di funzioni annidate può richiedere parecchio tempo per essere ricostruita mentalmente.

    Il punto non è quindi ridurre il numero di caratteri. È ridurre il numero di cose che bisogna tenere contemporaneamente a mente per capire cosa sta succedendo.

    Il primo segnale: la stessa logica compare più volte

    La duplicazione è uno dei segnali più utili. Se la stessa espressione compare più volte nella formula, LET può permettere di calcolarla una volta, assegnarle un nome e riutilizzarla. Se la stessa logica compare in molte formule del foglio, può essere il momento di chiedersi se debba essere centralizzata in altro modo.

    La duplicazione non è soltanto una questione estetica. Ogni copia è un punto che può essere dimenticato quando la regola cambia.

    Il secondo segnale: per capire il risultato bisogna smontare la formula

    Una formula dovrebbe consentire di ricostruire abbastanza rapidamente il percorso che porta dall’input al risultato. Quando per farlo bisogna selezionare ripetutamente porzioni dell’espressione, copiarle altrove o sostituire temporaneamente parti della formula, la difficoltà di debug sta diventando parte del problema.

    LET aiuta perché consente di dare un nome ai risultati intermedi, ma ha anche un limite pratico: strumenti abituali come F9 non permettono di ispezionare con la stessa immediatezza i nomi locali definiti al suo interno. Una formula più strutturata può quindi essere più leggibile senza essere necessariamente più semplice da diagnosticare.

    Il terzo segnale: le eccezioni stanno guidando la struttura

    Molte formule iniziano con una regola semplice e crescono attraverso eccezioni: se accade A fai questo, tranne nel caso B, salvo che C sia vuoto, ma solo quando D appartiene a un certo insieme.

    Non c’è una soglia oltre la quale una formula diventa automaticamente sbagliata. Ma quando la struttura principale serve soprattutto a gestire casi particolari, può essere utile fermarsi e verificare se il problema sia ancora un calcolo da foglio o sia diventato un processo di trasformazione più adatto, per esempio, a Power Query.

    Il quarto segnale: funziona, ma nessuno vuole toccarla

    È forse il segnale più concreto. Una formula può produrre risultati corretti per anni e allo stesso tempo essere diventata fragile dal punto di vista della manutenzione. Se ogni modifica viene rimandata perché si teme di alterare un equilibrio difficile da ricostruire, il costo della soluzione è già aumentato.

    Questo vale anche quando chi mantiene il file coincide con chi l’ha costruito. Dopo alcuni mesi, il contesto che rendeva ovvie certe scelte può non esserlo più.

    Non tutto deve diventare Power Query o VBA

    Riconoscere questi segnali non significa trasformare ogni formula articolata in una query o in una macro. Spostare la logica ha un costo e può semplicemente trasferire la complessità in un ambiente meno accessibile all’utente o al manutentore.

    A volte la soluzione migliore è ancora una formula, ma riscritta: eliminando duplicazioni, introducendo LET, separando responsabilità diverse o rendendo espliciti alcuni passaggi intermedi. In altri casi la crescita della formula sta semplicemente segnalando che il problema ha cambiato natura.

    La domanda utile

    Prima di aggiungere un altro SE, un’altra condizione o un altro livello di annidamento, può essere utile chiedersi non soltanto se la modifica funziona, ma se rende ancora comprensibile la regola complessiva.

    Una formula non diventa troppo complessa quando supera una certa lunghezza. Lo diventa quando il costo per capirla, verificarla e modificarla comincia a superare il vantaggio di averla tutta in una cella.

  • La soluzione giusta dipende anche da chi la usa

    Una soluzione Excel non è buona soltanto perché funziona. Deve funzionare anche per la persona che la userà e per chi, eventualmente, dovrà controllarla o mantenerla nel tempo.

    È un criterio facile da trascurare, soprattutto quando costruiamo strumenti per noi stessi. Conosciamo i dati, ricordiamo perché abbiamo scelto una certa formula e sappiamo dove intervenire se qualcosa non torna. Quando il file passa a un altro utente, gran parte di questo contesto scompare.

    La stessa formula per utenti diversi

    Una formula ad espansione costruita con LET, FILTRO, MAP o altre funzioni recenti può sostituire decine di formule tradizionali. Dal punto di vista tecnico è spesso un miglioramento: meno duplicazione, meno trascinamenti, una logica concentrata in un solo punto.

    Ma il vantaggio cambia a seconda di chi apre il file. Per un utente che conosce gli array dinamici, una formula unica può essere più leggibile di molte colonne di appoggio. Per chi lavora soprattutto con formule tradizionali, la stessa soluzione può apparire come un blocco difficile da interpretare e ancora più difficile da modificare.

    Nascondere la complessità non significa eliminarla

    Power Query permette di spostare fuori dal foglio molte operazioni di importazione e trasformazione. VBA può arrivare ancora oltre, offrendo pulsanti e procedure che guidano l’utente senza mostrargli quasi nulla della logica sottostante.

    Per chi utilizza lo strumento può essere un grande vantaggio. Per chi deve mantenerlo, però, la complessità esiste ancora: si è semplicemente spostata. Una query M o una procedura VBA ben progettata può essere molto più manutenibile di un foglio pieno di formule; una soluzione poco strutturata può produrre l’effetto opposto.

    Chi deve capire cosa?

    Non tutti gli utenti devono conoscere l’intera soluzione. In uno strumento operativo può essere corretto che chi lo utilizza veda soltanto input, controlli e risultati, mentre la logica rimane affidata a formule, query o codice protetti da modifiche accidentali.

    Il punto è capire chi dovrà intervenire quando cambierà una regola, arriverà una nuova sorgente dati o comparirà un risultato inatteso. Se quella persona non dispone degli strumenti necessari per leggere la soluzione, il problema non è soltanto formativo: diventa un problema di progettazione.

    Anche il debug dipende dall’utente

    La manutenibilità emerge soprattutto quando qualcosa non funziona. Una formula semplice può essere verificata direttamente nel foglio; una formula LET molto articolata evita duplicazioni e permette di dare un nome ai passaggi intermedi, ma non offre sempre la stessa immediatezza nel debug. Tecniche abituali come F9, per esempio, non consentono di ispezionare con la stessa comodità i nomi locali definiti all’interno di LET.

    Power Query rende visibili i passaggi della trasformazione, ma richiede di conoscere il suo modello di elaborazione. VBA dispone di strumenti di debug molto più completi, ma presuppone competenze di programmazione. Non esiste quindi uno strumento che sia semplicemente «più facile»: dipende da chi dovrà diagnosticare il problema.

    Versioni, lingua e contesto

    Anche l’ambiente dell’utente fa parte della soluzione. Una funzione recente può non essere disponibile in una versione precedente di Excel. E i nomi delle funzioni localizzate non seguono sempre una regola uniforme: nella versione italiana possono convivere, per esempio, LET, LAMBDA e MAP con UNICI.

    Questo non rende necessariamente il file meno portabile, ma può rendere meno immediato leggere una formula trovata nella documentazione, confrontarla con un esempio online o spiegare la soluzione a chi utilizza Excel in un’altra lingua.

    Progettare per due utenti

    Molti file Excel hanno in realtà almeno due utenti: chi li usa e chi li mantiene. A volte sono la stessa persona, ma non è prudente progettarli dando per scontato che sarà sempre così.

    Per il primo servono chiarezza, pochi passaggi e protezione dagli errori. Per il secondo servono struttura, nomi comprensibili, logica non duplicata e la possibilità di capire rapidamente dove intervenire.

    Una buona soluzione cerca un equilibrio tra queste due esigenze. Non sceglie la formula più sofisticata, la query più elegante o la macro più automatizzata in assoluto. Sceglie il livello di complessità che il contesto può sostenere.

  • Stesso problema, tre Excel diversi: formule, Power Query o VBA?

    Lo stesso problema in Excel può spesso essere risolto in modi molto diversi. Una formula dinamica, una query Power Query e una macro VBA possono arrivare allo stesso risultato, ma non sono necessariamente soluzioni equivalenti.

    La domanda utile, quindi, non è soltanto «come posso farlo?», ma «dove conviene farlo?». La risposta dipende dal tipo di trasformazione, dalla frequenza con cui deve essere eseguita, dalla quantità di dati e, soprattutto, da chi dovrà usare e mantenere il file.

    Quando basta una formula

    Le formule sono spesso la scelta più naturale quando il risultato deve rimanere visibile nel foglio e reagire immediatamente ai dati. Con gli array dinamici è possibile costruire trasformazioni che un tempo avrebbero richiesto colonne di appoggio, formule trascinate o codice VBA.

    Il vantaggio è evidente: la logica resta vicina ai dati e può essere ispezionata direttamente dall’utente. Ma una formula molto compatta non è automaticamente una buona soluzione. Quando cresce troppo, combina molte trasformazioni o viene replicata in più punti, può diventare difficile da leggere, verificare e modificare.

    Quando Power Query descrive meglio il processo

    Power Query è particolarmente adatto quando il problema consiste nel leggere dati, pulirli, normalizzarli, unirli e produrre una tabella da aggiornare. In questi casi la sequenza dei passaggi racconta il processo in modo spesso più chiaro di una formula molto articolata.

    C’è però una differenza importante: Power Query non lavora con la stessa immediatezza di una formula. Il risultato viene aggiornato quando la query viene eseguita. Per un utente che si aspetta che ogni modifica nel foglio produca subito un nuovo valore, questo modello può essere meno intuitivo.

    Quando serve VBA

    VBA entra in gioco soprattutto quando non dobbiamo soltanto calcolare o trasformare dati, ma governare un processo: aprire o creare file, controllare percorsi, interagire con l’utente, eseguire più operazioni in sequenza, validare condizioni e gestire eccezioni.

    È più potente, ma introduce anche più responsabilità. Il codice deve essere strutturato, documentato e mantenuto; gli errori possono essere meno trasparenti per chi usa il file senza conoscere VBA. Usarlo solo perché «con una macro si può fare» rischia di trasformare un problema semplice in un’applicazione che qualcuno dovrà poi mantenere.

    Tre soluzioni corrette, tre costi diversi

    Immaginiamo di dover leggere una tabella, selezionare alcune righe, trasformare dei valori e ottenere un riepilogo. Possiamo costruire un’unica formula ad espansione, preparare una query oppure scrivere una procedura VBA. Tutte e tre le soluzioni possono essere tecnicamente corrette.

    Ciò che cambia è il costo della soluzione nel tempo. Una formula può essere perfetta per un’analisi interattiva ma scomoda da manutenere se diventa troppo complessa. Power Query può rendere molto leggibile una pipeline di trasformazione, ma richiede di comprendere il meccanismo di aggiornamento. VBA può orchestrare l’intero processo, ma al prezzo di una maggiore complessità tecnica.

    La scelta dipende anche da chi apre il file

    La stessa soluzione può essere ottima per chi l’ha costruita e poco adatta per chi dovrà utilizzarla. Un utente abituato alle formule può intervenire facilmente su un calcolo nel foglio ma trovarsi in difficoltà davanti a una query M. Un file destinato a diventare uno strumento operativo, invece, può beneficiare di una logica più nascosta e controllata, purché sia progettata in modo da non richiedere continui interventi sul codice.

    Anche la compatibilità conta: funzioni disponibili solo nelle versioni più recenti di Excel, funzionalità di Power Query e macro possono imporre vincoli diversi all’ambiente in cui il file verrà utilizzato.

    Non scegliere lo strumento prima del problema

    È facile affrontare ogni esigenza con lo strumento che conosciamo meglio. Chi lavora soprattutto con le formule tende a costruire formule sempre più sofisticate; chi usa Power Query porta tutto nelle query; chi programma in VBA vede rapidamente una macro possibile.

    Una soluzione Excel ben progettata può invece usare strumenti diversi nello stesso file, assegnando a ciascuno il compito per cui è più adatto: formule per il calcolo interattivo, Power Query per acquisizione e trasformazione dei dati, VBA per l’orchestrazione quando serve davvero.

    Il criterio non è trovare la soluzione più elegante in assoluto. È costruire quella che rende il problema più semplice da capire, usare e mantenere.

  • LAMBDA e LET: formule più strutturate, ma non sempre più semplici

    LET e LAMBDA permettono di portare nelle formule Excel principi che normalmente associamo al codice: dare un nome ai risultati intermedi, evitare duplicazioni e rendere riutilizzabile una logica. Il vantaggio è notevole, ma non gratuito: una formula più strutturata può anche diventare più difficile da esplorare, spiegare e correggere.

    LET: il primo vantaggio è non ripetersi

    LET viene spesso presentata come una funzione che rende le formule più leggibili. È vero, ma per me viene prima un altro aspetto: consente di definire una volta sola un’espressione e riutilizzarne il risultato. Se la stessa logica compare più volte nella formula, assegnarle un nome significa ridurre duplicazioni e, quando il calcolo è oneroso, evitare di eseguirlo inutilmente più volte.

    La leggibilità nasce anche da qui: non tanto dal rendere la formula più corta, quanto dal poter dare un significato ai suoi passaggi intermedi.

    LAMBDA: quando una formula diventa riutilizzabile

    LAMBDA aggiunge un passaggio ulteriore. Una logica che funziona bene e ricorre in più punti può essere trasformata in una funzione con parametri propri, senza ricorrere necessariamente a VBA. Il valore non è scrivere formule più sofisticate: è evitare che la stessa regola venga copiata, modificata e mantenuta in molti punti diversi.

    È lo stesso principio che rende utile una funzione nel codice: una responsabilità riconoscibile, un nome e un solo punto in cui intervenire quando la logica cambia.

    Il confine tra formula e piccolo programma

    Combinando LET, LAMBDA e array dinamici si possono costruire formule molto articolate. A quel punto, però, la domanda non dovrebbe essere soltanto “si può fare?”, ma “conviene farlo qui?”. Una formula può essere tecnicamente elegante e al tempo stesso risultare opaca per chi dovrà usarla o mantenerla.

    Il debug rimane un punto debole

    LET struttura bene i passaggi, ma i suoi nomi sono locali alla formula. Il classico F9, utile per valutare una sottoespressione, non consente di osservare un nome locale con la stessa immediatezza. In pratica, durante lo sviluppo può essere necessario restituire temporaneamente un risultato intermedio oppure separare alcuni passaggi prima di ricomporli.

    Con LAMBDA la distanza tra ciò che l’utente vede nella cella e la logica effettiva può aumentare ancora. È un vantaggio quando la funzione è stabile e ben nominata; può diventare uno svantaggio quando occorre capire rapidamente perché un risultato non è quello atteso.

    La manutenzione dipende dall’utenza

    Per un utente esperto, una funzione LAMBDA ben progettata può essere più chiara di una lunga formula ripetuta. Per un utente occasionale, invece, una funzione personalizzata può nascondere troppo. In un file distribuito a molte persone può essere preferibile un’interfaccia controllata; in un modello analitico mantenuto da pochi specialisti, la composizione di formule può essere la soluzione più trasparente.

    La qualità della soluzione non dipende quindi soltanto dalla formula, ma anche dalla distanza tra chi la progetta e chi dovrà comprenderla in futuro.

    Anche i nomi delle funzioni fanno parte del problema

    Anche i nomi delle funzioni fanno parte del problema. Nelle versioni localizzate di Excel la situazione non è sempre uniforme: alcune funzioni mantengono il nome inglese, altre vengono tradotte. Nella versione italiana, per esempio, convivono nomi come LET, LAMBDA e MAP con UNICI. Non è tanto un problema di portabilità della cartella, quanto di leggibilità e manutenibilità: confrontare una formula con documentazione, esempi online o soluzioni scritte per installazioni in altre lingue può richiedere un passaggio ulteriore di interpretazione.

    Quando fermarsi

    LET e LAMBDA sono strumenti potenti proprio perché permettono di spostare più logica dentro le formule. Ma questa possibilità non obbliga a farlo. Quando aumentano trasformazioni, dipendenze, dati o necessità di controllo, Power Query, VBA o un add-in possono offrire un confine più naturale.

    Il criterio che cerco di seguire è semplice: strutturare abbastanza da eliminare duplicazioni e rendere esplicita la logica, ma non al punto da trasformare una formula in qualcosa che soltanto il suo autore riesce a mantenere.

  • Pensare per array, non per celle

    EXCEL · ARRAY DINAMICI · FORMULE

    Le formule dinamiche hanno cambiato un aspetto importante di Excel: una formula non deve più necessariamente produrre il risultato di una singola cella. Può restituire più valori che si espandono automaticamente in un intervallo di celle adiacenti. Il cambiamento interessante, però, non è soltanto tecnico: sposta il modo di ragionare dalla singola cella all’insieme di dati.

    Dal trascinamento alla propagazione automatica

    Nel modello tradizionale una stessa logica viene spesso replicata lungo righe o colonne. È un approccio semplice e leggibile, ma porta con sé un rischio operativo molto concreto: una formula può non essere stata trascinata abbastanza, può essere stata sovrascritta oppure può differire accidentalmente dalle righe vicine.

    Con una formula ad espansione la logica rimane in una sola cella e il risultato occupa automaticamente l’intervallo necessario. Non serve quindi ricordarsi di propagare manualmente la formula quando il numero di righe cambia. Per me questo è uno dei vantaggi più importanti: non soltanto meno lavoro, ma anche un punto di manutenzione unico.

    Una precisazione terminologica. Quel risultato non è necessariamente una Tabella Excel strutturata. È più corretto parlare di intervallo espanso o di matrice restituita dalla formula. La distinzione può sembrare formale, ma evita di confondere due oggetti che in Excel hanno comportamenti diversi.

    Pensare per trasformazioni

    Il passo successivo è smettere di vedere ogni funzione come un’operazione isolata. Le formule moderne diventano davvero interessanti quando vengono composte: un insieme di dati viene filtrato, ordinato, rimodellato e poi passato alla trasformazione successiva.

    =LET(
    dati; Tabella1;
    validi; FILTER(dati; Tabella1[Stato]="OK");
    ordinati; SORT(validi; 3; -1);
    TAKE(ordinati; 10)
)

    L’esempio non è interessante perché usa FILTER, SORT o TAKE. Lo è perché rende esplicita una sequenza: selezionare, ordinare, limitare. Il valore sta nella composizione della logica, non nella singola funzione.

    Lo stesso vale per funzioni come VSTACK, HSTACK, TOCOL o TOROW: più che conoscerle una per una, conta capire che permettono di combinare e rimodellare intervalli senza tornare necessariamente al modello “una formula per riga”.

    Nota sui nomi delle funzioni. Excel non è sempre uniforme nella localizzazione delle funzioni più recenti. In alcune versioni italiane alcuni nomi rimangono in inglese, in altre risultano tradotti. Negli esempi conviene quindi verificare il nome effettivamente disponibile nella propria installazione di Microsoft 365.

    LET: evitare duplicazioni prima ancora che migliorare la leggibilità

    Uno dei motivi principali per cui considero utile LET è la possibilità di definire una volta sola un’espressione e riutilizzarne il risultato. Questo evita duplicazioni all’interno della formula e, quando l’espressione è costosa, evita anche di ricalcolarla più volte.

    =LET(
    datiValidi; FILTER(Tabella1; Tabella1[Stato]="OK");
    ...
)

    In questo caso FILTER(Tabella1; Tabella1[Stato]="OK") viene definita una volta sola come datiValidi. La leggibilità migliora, ma per me è una conseguenza: il primo vantaggio è aver eliminato codice duplicato e aver dato un’identità a un risultato intermedio.

    Più struttura non significa debug più semplice

    LET rende una formula più strutturata, ma sposta parte della complessità sul debug. I nomi definiti al suo interno sono locali alla formula e il classico uso di F9 non permette di ispezionarli con la stessa immediatezza di una normale sottoespressione.

    Quando devo verificare un passaggio, spesso sostituisco temporaneamente il risultato finale della LET con il nome intermedio che voglio osservare. In formule più complesse può essere perfino più efficace usare per qualche minuto celle di appoggio e ricomporre tutto solo quando la logica è stabile.

    È un buon promemoria: una formula più elegante non è automaticamente più semplice da sviluppare, spiegare o mantenere.

    La soluzione dipende anche da chi la usa

    La possibilità tecnica di costruire una formula compatta non significa che quella sia sempre la soluzione migliore. L’utenza conta almeno quanto la funzionalità.

    • Per un utente occasionale, alcuni passaggi visibili possono essere preferibili a una formula molto densa.
    • Per un utente Excel esperto, una formula dinamica ben strutturata può essere più trasparente di una macro nascosta.
    • Per un analista, poter modificare rapidamente la logica nel foglio può essere un vantaggio importante.
    • Per un processo operativo usato da molte persone, può essere più sicuro nascondere la complessità dietro un’interfaccia controllata.

    Per questo non considero gli array dinamici una destinazione obbligatoria. Sono uno strumento molto potente quando il problema, la dimensione dei dati e il profilo degli utenti lo rendono appropriato.

    Quando sceglierei un’altra strada

    Se la trasformazione diventa lunga, coinvolge molti dati, richiede join articolati o deve diventare un processo ripetibile e verificabile, Power Query può essere più naturale. Se invece serve guidare l’utente, automatizzare operazioni sul workbook o integrare il processo nell’interfaccia di Excel, VBA o un add-in possono essere più adatti.

    La domanda quindi non è “quanto si può fare con una formula?”, ma “qual è il livello giusto in cui mettere questa logica, per questo problema e per queste persone?”.

    Principio: gli array dinamici non eliminano le celle. Spostano il livello di ragionamento dalla singola cella all’insieme di dati.