Perché i loop nidificati sono considerati cattive pratiche?

Il mio docente ha affermato oggi che era possibile "etichettare" i loop in Java in modo da poterli fare riferimento quando si tratta di loop nidificati. Quindi ho cercato la funzione perché non ne ero a conoscenza e in molti posti in cui questa funzione è stata spiegata è stata seguita da un avvertimento, scoraggiando i cicli annidati.

Non capisco davvero perché? È perché influenza la leggibilità del codice? O è qualcosa di più "tecnico"?

I loop nidificati vanno bene purché descrivano l'algoritmo corretto.

I loop nidificati hanno considerazioni sulle prestazioni (vedere la risposta di @ Travis-Pesetto), ma a volte è esattamente l'algoritmo corretto, ad esempio quando è necessario accedere a tutti i valori in una matrice.

L'etichettatura dei loop in Java consente di uscire prematuramente da diversi loop nidificati quando altri modi per farlo sarebbero ingombranti. Ad esempio, alcuni giochi potrebbero avere un codice come questo:

Player chosen_one = null;
...
outer: // this is a label
for (Player player : party.getPlayers()) {
  for (Cell cell : player.getVisibleMapCells()) {
    for (Item artefact : cell.getItemsOnTheFloor())
      if (artefact == HOLY_GRAIL) {
        chosen_one = player;
        break outer; // everyone stop looking, we found it
      }
  }
}

Mentre il codice come nell'esempio sopra può talvolta essere il modo ottimale per esprimere un certo algoritmo, di solito è meglio suddividere questo codice in funzioni più piccole e probabilmente usare al returnposto di break. Quindi un breakcon un'etichetta è un debole odore di codice ; presta particolare attenzione quando lo vedi.

I loop nidificati sono spesso (ma non sempre) cattive pratiche, perché sono spesso (ma non sempre) eccessivi per quello che stai cercando di fare. In molti casi, esiste un modo molto più rapido e meno dispendioso per raggiungere l'obiettivo che stai cercando di raggiungere.

Ad esempio, se hai 100 elementi nell'elenco A e 100 elementi nell'elenco B e sai che per ogni elemento nell'elenco A c'è un elemento nell'elenco B che lo corrisponde, (con la definizione di "match" lasciato deliberatamente oscuro qui) e vuoi produrre un elenco di coppie, il modo semplice per farlo è così:

for each item X in list A:
  for each item Y in list B:
    if X matches Y then
      add (X, Y) to results
      break

Con 100 voci in ogni elenco, occorreranno in media 100 * 100/2 (5.000) matchesoperazioni. Con più articoli o se la correlazione 1: 1 non è garantita, diventa ancora più costosa.

D'altra parte, c'è un modo molto più veloce per eseguire un'operazione come questa:

sort list A
sort list B (according to the same sort order)
I = 0
J = 0
repeat
  X = A[I]
  Y = B[J]
  if X matches Y then
    add (X, Y) to results
    increment I
    increment J
  else if X < Y then
    increment I
  else increment J
until either index reaches the end of its list

Se lo fai in questo modo, invece del numero di matchesoperazioni su length(A) * length(B)cui si basa length(A) + length(B), ora è basato su , il che significa che il tuo codice verrà eseguito molto più velocemente.

Un motivo per evitare i loop di nidificazione è perché è una cattiva idea nidificare le strutture dei blocchi troppo in profondità, indipendentemente dal fatto che siano o meno loop.

Ogni funzione o metodo dovrebbe essere facile da capire, sia per lo scopo (il nome dovrebbe esprimere ciò che fa) sia per i manutentori (dovrebbe essere facile capire gli interni). Se una funzione è troppo complicata per essere facilmente comprensibile, ciò significa che alcuni interni devono essere fattorizzati in funzioni separate in modo che possano essere indicati nella funzione (ora più piccola) per nome.

I loop nidificati possono diventare difficili da capire relativamente rapidamente, anche se alcuni nidificamenti di loop vanno bene, fornendo, come altri sottolineano, ciò non significa che stai creando un problema di prestazioni utilizzando un algoritmo estremamente (e inutilmente) lento.

In realtà, non sono necessari loop nidificati per ottenere limiti di prestazioni assurdamente lenti. Si consideri, ad esempio, un singolo ciclo che in ogni iterazione prende un elemento da una coda, quindi probabilmente ne mette diversi indietro - ad esempio la prima ricerca di un labirinto. Le prestazioni non sono decise dalla profondità di annidamento del loop (che è solo 1) ma dal numero di elementi che vengono messi in quella coda prima che alla fine sia esaurito ( se mai esaurito) - quanto è grande la parte raggiungibile del il labirinto è.

Dato il caso di molti loop nidificati, si finisce con il tempo polinomiale. Ad esempio dato questo pseudo codice:

set i equal to 1
while i is not equal to 100
  increment i
  set j equal to 1
  while j is not equal to i
    increment j
  end
 end

Questo sarebbe considerato O (n ^ 2) tempo che sarebbe un grafico simile a:

Dove l'asse y è la quantità di tempo impiegata per terminare il programma e l'asse x è la quantità di dati.

Se ricevi troppi dati, il tuo programma sarà così lento che nessuno lo aspetterà. e non è che circa 1.000 voci di dati credo che impiegheranno troppo tempo.

Guidare un camion da trenta tonnellate anziché un piccolo veicolo passeggeri è una cattiva pratica. Tranne quando è necessario trasportare 20 o 30 tonnellate di materiale.

Quando si utilizza un ciclo nidificato, non è una cattiva pratica. O è assolutamente stupido, oppure è esattamente ciò che è necessario. Tu decidi.

Tuttavia, qualcuno si è lamentato dei cicli di etichettatura . La risposta per questo: se devi porre la domanda, allora non usare l'etichettatura. Se sai abbastanza per decidere te stesso, allora decidi te stesso.

Non c'è nulla di intrinsecamente sbagliato o necessariamente cattivo nei loop nidificati. Tuttavia hanno alcune considerazioni e insidie.

Gli articoli a cui sei stato condotto, probabilmente in nome della brevità o a causa di un processo psicologico noto come bruciato, saltando le specifiche.

Essere bruciati è quando hai un'esperienza negativa di qualcosa con l'essere implicito che poi eviti. Ad esempio, potrei tagliare le verdure con un coltello affilato e tagliare me stesso. Potrei quindi dire che i coltelli affilati sono cattivi, non usarli per tagliare le verdure per cercare di rendere impossibile che quella brutta esperienza si ripeta. Questo è ovviamente molto poco pratico. In realtà devi solo stare attento. Se stai dicendo a qualcun altro di tagliare le verdure, allora hai un senso ancora più forte di questo. Se stessi insegnando ai bambini a tagliare le verdure, mi sentirei fortemente di dire loro di non usare un coltello affilato, soprattutto se non riesco a controllarli da vicino.

Il problema è che la programmazione non è che si raggiunga la massima efficienza se si preferisce sempre prima la sicurezza. In questo caso i bambini possono tagliare solo verdure morbide. Si confrontano con qualsiasi altra cosa e faranno solo un casino con un coltello smussato. È importante imparare a usare correttamente i loop, inclusi i loop nidificati, e non puoi farlo se sono considerati cattivi e non provi mai a usarli.

Come molte risposte qui evidenziano un loop nidificato è un'indicazione delle caratteristiche prestazionali del programma che può peggiorare in modo esponenziale ad ogni annidamento. Cioè, O (n), O (n ^ 2), O (n ^ 3) e così via che comprende O (n ^ profondità) dove la profondità rappresenta il numero di anelli che hai annidato. Man mano che il tuo annidamento cresce, il tempo richiesto cresce esponenzialmente. Il problema è che non è una certezza che la complessità del tempo o dello spazio sia tale (abbastanza spesso a * b * c, ma non tutti i cicli del nido possono essere eseguiti continuamente) né è una certezza che tu avere un problema di prestazioni anche se è quello.

Per molte persone, in particolare studenti, scrittori e docenti che per essere sinceri, raramente programmare per vivere o su base giornaliera per i cicli può anche essere qualcosa a cui non sono abituati e che ha indotto un carico cognitivo eccessivo nei primi incontri. Questo è un aspetto problematico perché c'è sempre una curva di apprendimento ed evitarlo non sarà efficace nel convertire gli studenti in programmatori.

I loop nidificati possono scatenarsi, ovvero possono finire nidificati molto profondamente. Se attraverso ogni continente, quindi attraverso ogni paese, quindi attraverso ogni città, quindi attraverso ogni negozio, quindi attraverso ogni scaffale, quindi attraverso ogni prodotto se è una lattina di fagioli attraverso ogni fagiolo e misuro le sue dimensioni per ottenere la media, quindi tu posso vedere che nidificherà molto profondamente. Avrai una piramide e molto spazio sprecato lontano dal margine sinistro. Potresti anche finire per uscire dalla pagina.

Questo è un problema che sarebbe storicamente più significativo in cui gli schermi erano piccoli e di bassa risoluzione. In quei casi anche pochi livelli di nidificazione potrebbero davvero occupare molto spazio. Questa è una preoccupazione minore oggi in cui la soglia è più alta sebbene possa ancora presentare un problema se c'è abbastanza nidificazione.

Correlata è l'argomento estetico. Molte persone non trovano nidificato per i loop esteticamente gradevoli in contrasto con i layout con un allineamento più coerente questo può o meno essere collegato a ciò a cui le persone sono abituate, il tracciamento degli occhi e altre preoccupazioni. È tuttavia problematico in quanto tende ad auto-rafforzarsi e alla fine può rendere il codice più difficile da leggere poiché rompere un blocco di codice e incapsulare loop dietro astrazioni come funzioni rischia anche di interrompere la mappatura del codice nel flusso di esecuzione.

C'è una naturale tendenza a ciò a cui le persone sono abituate. Se stai programmando qualcosa nel modo più semplice, la probabilità di non avere nidificazione è massima, la probabilità di aver bisogno di un livello diminuisce di un ordine di grandezza, la probabilità di un altro livello diminuisce di nuovo. La frequenza cala e significa essenzialmente quanto più profondo è l'annidamento, tanto meno i sensi umani sono addestrati ad anticiparlo.

In relazione a ciò è che in qualsiasi costrutto complesso, che può essere considerato un loop nidificato, allora dovresti sempre chiedere che la soluzione più semplice possibile in quanto esiste il potenziale per una soluzione mancata che necessita di meno loop. L'ironia è che una soluzione nidificata è spesso il modo più semplice per produrre qualcosa che funzioni con il minimo sforzo, complessità e carico cognitivo. Spesso è naturale nidificare per i loop. Se consideri ad esempio una delle risposte sopra in cui il modo molto più veloce di un ciclo nidificato per è anche molto più complesso e consiste in molto più codice.

È necessaria una grande cura poiché è spesso possibile astrarre gli anelli o appiattirli, ma il risultato finale è in definitiva una cura peggiore della malattia, in particolare se non si riceve ad esempio un miglioramento misurabile e significativo delle prestazioni dallo sforzo.

È molto comune per le persone sperimentare frequentemente problemi di prestazioni associati a cicli che indicano al computer di ripetere un'azione molte volte e che sono intrinsecamente spesso implicati in colli di bottiglia delle prestazioni. Purtroppo le risposte a questo possono essere molto superficiali. Diventa comune per le persone vedere un loop e vedere un problema di prestazioni in cui non c'è nessuno e quindi nascondere il loop dalla vista per nessun effetto reale. Il codice "sembra" veloce ma mettilo sulla strada, digita l'accensione, pedale dell'acceleratore e dai un'occhiata al tachimetro e potresti scoprire che è ancora veloce come una vecchia signora che cammina sul telaio più luminoso.

Questo tipo di nascondiglio è simile a se hai dieci rapinatori sulla tua rotta. Se invece di avere un percorso diretto verso dove vuoi andare, lo organizzi in modo che ci sia un rapinatore dietro ogni angolo, quindi dà l'illusione mentre inizi il tuo viaggio che non ci sono rapinatori. Lontano dagli occhi, lontano dal cuore. verrai ancora rapinato dieci volte, ma ora non lo vedrai arrivare.

La risposta alla tua domanda è che sono entrambe le cose, ma nessuna delle due preoccupazioni è assoluta. Sono interamente soggettivi o solo contestualmente obiettivi. Purtroppo a volte l'opinione totalmente soggettiva o piuttosto ha la precedenza e domina.

Come regola generale, se ha bisogno di un ciclo nidificato o che sembra il prossimo passo ovvio, è meglio non deliberare e semplicemente farlo. Tuttavia, se persistono dubbi, dovrebbe essere successivamente riesaminato.

Un'altra regola empirica è che dovresti sempre controllare la cardinalità e chiederti se questo ciclo sarà un problema. Nel mio esempio precedente ho attraversato le città. Per i test potrei passare solo attraverso dieci città ma qual è il numero massimo ragionevole di città che ci si aspetta dall'uso nel mondo reale? Potrei quindi moltiplicarlo per lo stesso per i continenti. È una regola pratica da considerare sempre con i loop, in particolare che ripetono una quantità dinamica (variabile) di volte ciò che potrebbe tradursi in down line.

Indipendentemente da ciò, fai sempre ciò che funziona per primo. Il modo in cui vedi un'opportunità per l'ottimizzazione può confrontare la tua soluzione ottimizzata con il più semplice per lavorare e confermare che ha prodotto i benefici previsti. Puoi anche dedicare troppo tempo all'ottimizzazione prematura prima che le misurazioni vengano eseguite e ciò porta a YAGNI o a perdere molto tempo e scadenze non rispettate.