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

I metodi lunghi sono generalmente considerati cattivi, tuttavia nel mio codice ho alcuni metodi lunghi di difficile comprensione (più di 50 righe). Ho difficoltà a rendere più facili da leggere quei metodi perché una singola istruzione all'interno è già lunga più di 50 righe e quella singola istruzione difficile da leggere è costruire una query di database usando un ORM per fare un lavoro specifico in cui il lavoro svolto è chiaramente indicato sul nome del metodo. Il motivo per cui l'istruzione è così lunga perché si unisce su più colonne, applica più posizioni e seleziona più colonne distinte per creare un formato di output documentato richiesto.

Tale codice difficile da leggere è considerato un codice errato? Allo stesso modo, se scrivo codice per un algoritmo complicato che risulta in un codice difficile da leggere racchiuso in un metodo ben definito, quel codice è un codice errato?

Hai scritto

Un codice così difficile da leggere è considerato un codice errato?

quindi sei assolutamente d'accordo sul fatto che sia un codice difficile da leggere , e se è difficile da leggere, è difficile da mantenere ed evolvere - quindi immagino che consideri il codice come "cattivo" dalle tue stesse misure. Tuttavia, a volte non è ovvio come migliorare qualcosa come un'istruzione SQL a 50 righe. I semplici refactoring del "metodo di estrazione" non funzionano e probabilmente non hai idea di dove iniziare a rendere il codice più leggibile. In questi casi, puoi ancora provare una o tutte le seguenti

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

• prova a google per il problema specifico. Per il tuo esempio, cose come "clean up long sql statement" potrebbero essere un buon inizio. Rimarrai stupito dal numero di articoli che trovi su quell'argomento e anche se non riesci a trovare una ricetta intricata per il tuo caso, potresti avere delle idee originali

• 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 le giuste interruzioni di riga, il rientro corretto, aggiungere alcuni commenti esplicativi, dare ad alcune variabili un migliore nome. Non è improbabile, durante questo processo, costringendoti a rileggere i dettagli del codice, trovi un modo per riformattare 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 al tuo problema oggi, ma quando torni al codice tra qualche mese, ti sembrerà diverso.

Difficile da leggere non è male - inutilmente difficile da leggere è cattivo.

Alcune cose sono difficili. In tal caso, devi comprendere completamente il problema, scrivere il codice e commentarlo il più bene 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, semplificarlo. Se è difficile da capire ma può essere ragionevolmente suddiviso in sottoproblemi, quindi dividerlo in sottoproblemi per semplificarlo.

ORM per creare un rapporto? 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 complicate. E anche se non riesci a far sembrare bello l'SQL, ci sono tutti i tipi di strumenti di visualizzazione disponibili in cui puoi trascinare e rilasciare oggetti di database su un diagramma e l'SQL verrà generato per te. Per non parlare del fatto che sarai in grado di ottimizzare e ottimizzare la query, visualizzare il suo piano di query, ottenere la piattaforma per suggerire ulteriori opzioni di indicizzazione, ecc. È solo molto più flessibile.

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

In generale il codice difficile da leggere è una cattiva idea ovunque - anche se sei l'unico manutentore - ho avuto diverse occasioni di tornare ad alcuni codici anni o addirittura settimane dopo e trovarmi difficile farmi girare la testa.

Se devi fare molto in una singola query, prova a suddividerla 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" in ogni momento. La codifica sta facendo dei compromessi e spesso è meglio accettare di aver scritto qualcosa di un po 'meno pulito di quello che vorresti e tornarci più tardi. Il refactoring è il processo di miglioramento del codice nel tempo - e nella mia esperienza, questo è ciò che rende una buona base di codice, non "ottenerlo giusto la prima volta".

E tu valuti il ​​codice a livello dell'applicazione, non a livello di singoli metodi / linee di codice. Quindi, se hai un metodo complesso, ma ha un nome chiaro, non penso che tu abbia un codice "cattivo" fintanto che il metodo è coerente.

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

La prossima cosa è assicurarsi che il tuo metodo faccia davvero solo una cosa: gli effetti collaterali rendono il codice difficile da capire. Quindi, se il tuo metodo restituisce 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 comportino tutti allo stesso modo, senza effetti collaterali ecc.