L'uso di subprocedures per separare logicamente il mio codice è una cattiva idea per la programmazione strutturata? [duplicare]

2

La maggior parte della mia esperienza di programmazione si trova in OOP, dove ho abbracciato pienamente i concetti di ciò incluso l'incapsulamento. Ora sono tornato alla programmazione strutturata in cui ho la tendenza a logicamente separare il mio codice usando le subprocedure. Ad esempio, se ho un caso di switch di grandi dimensioni (30 casi o più), lo inserirò nella sua stessa procedura in modo che il metodo principale appaia un po '"più ordinato". Generalmente, le sottoprocedure sono utilizzate per mantenere le cose DRY , ma in alcuni casi queste separazioni logiche che creo solitamente equivalgono ad essere usate una sola volta.

Alcuni dei miei codici sono stati esaminati e si è detto che questa è una pessima idea. Il suo sostegno a questa affermazione è che confonde l'acqua e "nasconde inutilmente" il codice. Invece, insiste che una subprocedura DEVE essere usata più di una volta per meritare di fare una subprocedura su una sezione di codice. Mentre questa idea di "nascondere il codice" è un luogo comune in OOP, ammette di non avere alcuna comprensione dei concetti OOP e ha sempre lavorato solo con la programmazione strutturata.

C'è qualche sostegno alla sua richiesta o si tratta semplicemente di un dogma di programmazione?

    
posta Chad Harrison 17.06.2013 - 17:57
fonte

4 risposte

17

Incapsulamento, occultamento dei dati, astrazione, scrittura di codice leggibile, ecc., nulla è unico per OOP. In realtà, tutti questi sono stati inventati molto prima dell'OOP. In realtà, l'unica differenza tra OOP e altri paradigmi è il meccanismo dell'astrazione dei dati: OOP utilizza l'astrazione procedurale, altri in genere utilizzano i tipi di dati astratti.

Spezzare le subroutine in modo tale che ogni istruzione (o espressione di livello superiore nel caso di lingue che non hanno istruzioni) sia allo stesso livello di astrazione e organizzandole in modo che il codice nasca una storia coerente, è un universale principio, completamente estraneo a qualsiasi paradigma particolare.

    
risposta data 17.06.2013 - 18:04
fonte
6

"Il codice che non si nasconde mai" viene talvolta chiamato nascondimento delle informazioni . È molto più vecchio dell'orientamento agli oggetti e in Codice completo (prima edizione) è stato descritto come uno dei più importanti miglioramenti nella produttività dei programmatori nella storia.

    
risposta data 17.06.2013 - 18:05
fonte
3

È una massima ragionevolmente comune che una funzione (per usare la terminologia C) non debba avere più di uno o due schermate di codice (esempio ), con il ragionamento che è più semplice prendere in considerazione tutto ciò che fa la funzione senza dover scorrere ripetutamente su e giù.

È certamente il caso che quando una funzione viene eseguita in centinaia o addirittura migliaia di righe diventa più difficile leggere e capire. Penso che devi metterlo in evidenza con il tuo revisore.

    
risposta data 17.06.2013 - 19:07
fonte
1

Direi dogma, ma per me questo implica l'aderenza a uno standard separato, e anche se potrebbe non essere totalmente solo su questo, non penso che ci sia un grande corpo che è d'accordo con lui.

Le sottoprocedure non dovrebbero essere un singolo comando, ma trasformare un'istruzione di 5 casi switch con blocchi di 10-20 linee in 5 subroutine e un'istruzione switch lunga 5 righe renderà il codice più leggibile .

    
risposta data 17.06.2013 - 18:11
fonte

Leggi altre domande sui tag