Cerco di scrivere la maggior parte del mio codice usando pratiche standard. Questi includono tra gli altri e sono correlati a questa specifica domanda che ha funzioni short-ish, oggetti ben incapsulati quando OO è usato, non troppi argomenti di funzione o valori di ritorno (scrivo soprattutto in lingue dove è permesso restituire tuple implicitamente, ma in C per esempio Vorrei anche provare a non restituire una struct di 100 campi che contiene quasi tutto lo stato) e non ho bisogno di essere convinto che ciò sia utile per la produttività, la correttezza e il trasferimento di conoscenze.
Tuttavia, recentemente sono stato attratto molto dalla programmazione incentrata sul 'notebook', usando (nel mio campo) IPython o Matlab LiveScripts. Poiché lavoro in ricerche non correlate a SW, queste sono interessanti perché spesso non conosci "quello che stai cercando" mentre stai scrivendo il codice. Il vantaggio dei taccuini in questa situazione è che puoi caricare i dati una volta sola e fare molta manutenzione, quindi iniziare a sperimentare molto, tracciare Y in funzione di X, realizzare qualcosa, tracciare A in funzione di X invece di controllare, e così via e così via.
Il problema maggiore che ho con questo è che trovo la programmazione in stile "notebook" per incoraggiare la scrittura principalmente di codice puramente procedurale, perché è necessario essere in grado di rompere ovunque e avere tutti i dati disponibili. La nozione di "blocchi di codice" invece di funzioni ti spinge in quella direzione.
Per essere onesti, il mio approccio attuale non è roseo quando si tratta del vero processo di ricerca: finisco per dover ripetere l'intero codice molte volte perché devo riscrivere parte di esso per esporre alcuni stati interni, o altro vettore da tracciare.
Infine, questo non è un problema che ritengo sia facilmente risolvibile facendo affidamento sul debugger. Prima di tutto in certe situazioni il debugger Python diventa terribilmente lento (questo potrebbe essere dovuto alla grande quantità di dati e di elaborazione, ma potrebbe essere correlato allo strumento: non ho mai avuto problemi con il pdb CLI (che non uso spesso perché della sua ... interfaccia minimale) ma il debugger di vscode spesso macina verso il basso), ma ancora più importante, l'uso di un debugger non risolve del tutto il problema che se una funzione restituisce A, e ti rendi conto che volevi anche B, un valore intermedio, 10 minuti più tardi e cinque funzioni chiamano più tardi nel codice che non hai più disponibile.