È possibile rendere più facile leggere il codice lungo che rappresenta un calcolo?

Hai scritto

Is such hard-to-read code considered bad code

quindi sei assolutamente d'accordo che è un codice difficile da leggere , e se è difficile da leggere, è difficile da mantenere ed evolvere, quindi suppongo che consideri il codice come "cattivo" "con le tue stesse misure. Tuttavia, a volte non è ovvio come migliorare qualcosa come un'istruzione SQL di 50 righe. I semplici rifattori del "metodo di estrazione" non funzionano e probabilmente non hai idea di dove cominciare a rendere il codice più leggibile. In questi casi, puoi comunque provare uno o tutti i seguenti

• mostra il codice qualcun altro che ha più esperienza di te nella pulizia del codice. Se non hai qualcuno nella tua organizzazione puoi chiedere, prova codereview.stackexchange

• prova a google per il problema specifico. Per il tuo esempio, cose come "ripulire la lunga istruzione sql" potrebbe essere un buon inizio. Sarai stupito di quanti articoli trovi su quell'argomento, e anche se non riesci a trovare una ricetta braindead per il tuo caso, potresti avere qualche idea fresca

• invece di chiedere una giustificazione per le cose che non puoi fare, concentrati sulle cose che puoi fare per ripulire il codice almeno un po ', come aggiungere interruzioni di riga appropriate, indentazione corretta, aggiungendo alcuni commenti esplicativi, dando a alcune variabili un nome migliore. Non è improbabile che durante questo processo, costringendo te stesso a rileggere i dettagli del codice, trovi un modo per ridefinire il codice in unità più piccole

• pratica, pratica, pratica. "Clean coding" non è qualcosa che impari in un giorno, diventa più facile con più esperienza. Forse non trovi una soluzione per il tuo problema oggi, ma quando tornerai al codice tra qualche mese, ti sembrerà diverso.

Difficile leggere non è male - la lettura inutilmente difficile è cattiva.

Alcune cose solo sono difficili. In tal caso, devi comprendere completamente il problema, scrivere il codice e commentarlo nel modo migliore possibile in modo che il prossimo sviluppatore abbia una possibilità.

Ma alcune cose sono difficili solo perché le hai rese difficili. Se il problema può essere semplificato e semplificato, semplificalo. Se è difficile da capire ma può essere ragionevolmente suddiviso in sottoproblemi, quindi dividerlo in sottoproblemi per semplificarlo.

ORM per creare un report? Sul serio? Impara un po 'di SQL, amico. I linguaggi procedurali sono terribili in questo genere di cose.

SQL è un linguaggio molto meglio progettato per gestire join e selezioni complicati. E anche se non riesci a far sembrare l'SQL bello, ci sono tutti i tipi di strumenti di visualizzazione disponibili dove puoi trascinare e rilasciare gli oggetti del database su un diagramma e l'SQL verrà generato per te. Per non parlare del fatto che sarete in grado di ottimizzare e ottimizzare la query, visualizzare il suo piano di query, ottenere la piattaforma per suggerire ulteriori opzioni di indicizzazione, ecc. È semplicemente più flessibile.

Sono sicuro che alcune persone qui non saranno d'accordo con me, ma ORM non è adatto per complicati scopi di reporting. Se possibile, prenderei in considerazione l'idea di allontanarmi da questo e spostarmi verso il linguaggio di query Strutturato .

In generale, il codice difficile da leggere è una cattiva idea ovunque - anche se sei l'unico manutentore - ho avuto diverse occorrenze di tornare ad alcuni anni di codice o persino settimane più tardi e trovarlo difficile Mettimi alla testa.

Se devi fare molto in una singola query prova a dividerlo su più righe con commenti incorporati:

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah))) 

diventa:

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

Oltre all'eccellente risposta di @ DocBrown, penso che valga la pena riconoscere che nessuno scrive codice "buono" tutto il tempo. La codifica sta facendo dei compromessi, e spesso è meglio accettare di aver scritto qualcosa di un po 'meno pulito di quanto si vorrebbe e tornare più tardi. Il refactoring è il processo per migliorare il codice nel tempo e, secondo la mia esperienza, è ciò che rende un buon codice base, non "fa bene la prima volta".

E tu valuti il codice a livello dell'applicazione, non il livello dei singoli metodi / linee di codice. Quindi se hai un metodo complesso, ma è chiaramente chiamato, non penso che tu abbia un codice "cattivo" purché il metodo sia coeso.

Il naming è l'arma più grande che hai nel rendere il codice intelligibile - dai al tuo metodo un nome che permetta alle persone che leggono il tuo codice di saltare il corpo se necessario. Assegna un nome alle tue variabili, ecc. In modo che i lettori possano vedere ciò che rappresentano senza dover leggere le loro istruzioni di assegnazione.

La prossima cosa è assicurarsi che il tuo metodo faccia davvero una sola cosa: gli effetti collaterali rendono il codice difficile da capire. Quindi, se il tuo metodo restituisce i dati per un formato di output, non dovrebbe anche aggiornare lo stato del tuo database su "stampato" o altro.

La stratificazione / componentizzazione è la prossima cosa che potresti fare - se hai un sacco di metodi complessi che generano risultati ORM, raggruppali insieme in modo che i lettori del tuo codice possano assumere che si comportano allo stesso modo, non hanno effetti collaterali ecc.