Sono ammessi i loop nel set di regole "Codice pulito"?

Penso che tu ti riferisca al principio " Un livello di astrazione per funzione " in Codice pulito.

Questo principio generale ha perfettamente senso: un livello di astrazione è l'occultamento di livelli più bassi di dettagli, al fine di padroneggia la complessità. Mescolare diversi livelli di astrazione implica quindi che il tuo tentativo di nascondere / incapsulare la complessità di livello superiore sia rotto dall'uso simultaneo del livello più basso, il che richiede una chiara comprensione di come entrambi i livelli siano correlati. Quindi perdi i vantaggi dell'incapsulamento.

Questo non ha nulla a che fare con il giudizio di valore che tu dai alle diverse istruzioni. Se consideri for come di basso livello, potresti considerare lo stesso per if , while , return , chiamate di funzione, ecc ...

Quindi puoi utilizzare for nel tuo progetto, senza infrangere la regola.

Nota: ciò che potrebbe infrangere la regola è se si usasse un ciclo for per accedere a un livello di dettaglio che dovrebbe essere nascosto. Ad esempio, se utilizzi una funzione di alto livello a for per scorrere un array, quando hai già una funzione di livello superiore per eseguire una ricerca.

In primo luogo, vale la pena ricordare che il libro Pulisci codice suggerisce linee guida piuttosto che regole. Sembra che la linea guida specifica a cui si fa riferimento qui sia la raccomandazione che Non mischiare i livelli di astrazione .

Vale la pena ricordare che questo consiglio si riferisce specificamente al design dell'interfaccia di classe. (cioè metodi pubblici / protetti, proprietà pubbliche - tutto ciò che è esposto a qualcosa che utilizza una classe)

Considera una classe astratta di alto livello Animal , da cui deriva una classe di classe di basso livello Dog . Il Dog può includere un metodo chiamato Bark() , che sembrerebbe appropriato per il livello di astrazione di Dog .

Tuttavia, non c'è nulla per fermare il metodo Bark() che viene incluso nell'interfaccia della classe abstract Animal ; ma se altre classi derivate da Animal non possono utilizzare il metodo Bark() , questo sarebbe un codice olfattivo . Qualsiasi cosa derivata da Animal è forzata ad ereditare (e persino a sostituire) il metodo Bark() , anche se un metodo Bark() è del tutto inappropriato per la classe concreta.

cioè.

public abstract class Animal
{
     public abstract void Bark();
}

public class Elephant : Animal
{
     public override void Bark()
     {
         // HUH?!
     }
}

Il consiglio ti incoraggia in genere a riflettere attentamente sui metodi che fornisci nelle astrazioni / interfacce di alto livello; per evitare di forzare le classi derivate ( "livello inferiore" ) per ereditare, sovrascrivere o implementare metodi o comportamenti che non appartengono logicamente alla classe di livello inferiore.

I costrutti linguistici come la parola chiave for non sono correlati alle interfacce di classe; e il consiglio riguardo ai "livelli misti di astrazione" in realtà non ha alcun senso per quanto riguarda le implementazioni del metodo.

Il titolo della tua domanda è un po 'provocante, dal momento che dal testo è chiaro, cosa intendi per "Sono ammessi i cicli nel set di regole" Codice pulito ", tranne che per i componenti di basso livello ". Ecco come interpreto la tua domanda.

Penso che sia IMHO una domanda molto interessante, non così banale come potrebbe sembrare a prima vista. Non lo interpreterei solo alla luce di "Clean code" di Bob Martin, ma anche guardando "Clean Code" come pubblicizzato da persone come Ralf Westphal (riferimento tedesco: link , prova Google translate). Il suo suggerimento per ciò che chiama IODA architettura porta il principio "don" t mescolare basso e alto livello "all'estremo. E in effetti, in questa architettura, non troverai alcun ciclo "for" (e nessun'altra struttura di controllo come i condizionali) ai "componenti di livello superiore" - solo al livello più basso. Gli scopi dei componenti di livello superiore in questa architettura sono esclusivamente per "collegare" componenti di livello inferiore insieme.

Se prendi questo veramente all'estremo, devi modificare la struttura di ogni funzione come

  function HighLevelfunction()
      sum=0
      for i = 1 to upperLimit  logic
           sum+=LowLevelFunction1(i)
      return sum

in

  function LowLevelfunction2( func funcAsParameter)
      sum=0
      ' just for demonstration purposes, think not of reusage here
      for i = 1 to upperLimit
           sum+=funcAsParameter(i)
      return sum

Nota nella prima versione HighLevelfunction dipende da LowLevelFunction , nel secondo LowLevelfunction2 non dipende più da nessuna altra funzione. Nella seconda, avrai bisogno di una funzione di "livello superiore" in cui la chiamata LowLevelfunction2(LowLevelFunction1) abbia luogo - ma questo è semplicemente un passo di integrazione, non ci sarà nessun ciclo "for" al livello più alto necessario.

Tuttavia, facendo questo per ogni singola funzione in un programma del mondo reale, questo probabilmente diventerà presto molto poco pratico. Io (e credo che anche la maggior parte degli altri programmatori) disegnino la linea tra funzioni di alto livello e livello basso, classi o componenti su una granularità molto più grossolana. Bisogna trovare il giusto equilibrio e assicurarsi di non scrivere codice pulito solo per motivi di pulizia. Oppure, per dirlo con le parole di Ralf Westphal, "Do not Let Cleaning- Up Go Overboard ".