come nascondere variabili locali [chiuso]

Question

come nascondere variabili locali [chiuso]

#1 da (6 voti)
#2 da (5 voti)

1

Nel mio codice, a volte c'è una lunga funzione, per evitare di incasinare le variabili locali, vorrei usare un paio di parentesi per abbracciare i dettagli in modo che le variabili locali non siano visibili al resto del codice, ad esempio:

bool pricing_deals()
{
  //prepare deal type lookup table
  vector<DealType> deal_types; // deal type lookup table
  {
    vector<DealType> deal_types_TRF; 
    vector<DealType> deal_types_DCI; 
    ...
    // code that prepare deal_types by merging deal_types_TRF and deal_types_DCI etc
  }
  // from now on deal_types_TRF and deal_types_DCI are invisible

  //prepare ccy pair lookup table
  vector<CcyPair> ccy_pairs; // ccy pair lookup table
  {
    // code that prepare ccy_pairs;
  }
  // from now on local variables preparing ccy_pairs are invisible

  // real computation starts
  ...
}

Mi chiedo se questa è una buona pratica, o ci sono altri modi per farlo?

P.S. Preferisco non suddividerlo in funzioni più piccole in questo caso, poiché la sub-logica non è suscettibile di essere riutilizzata da altri, e il refactoring causerà il passaggio di molti parametri, il che aumenterebbe la complessità.

coding-style c++

posta athos 04.06.2017 - 03:25

fonte

2 risposte

Leggi altre domande sui tag coding-style c++

Quali sono le conseguenze dell'uso di verbi anziché di nomi nell'URI dell'API REST? Applicazione desktop basata su rest

score 6 · Answer 1

Ciò che è necessario qui è l'astrazione.

La singola cosa più limitante in questa situazione non è se questa può essere una funzione riutilizzabile o aiutare un test unitario. È se puoi o meno dargli un buon nome.

I metodi di helper privati monouso (o funzioni o subroutine o macro) non sono peccato se hanno un buon nome.

Che bel nome? Uno che garantisce che non devo guardare dentro per sapere cosa fa. Se guardo dentro dopo aver letto il nome dovrei trovare più o meno quello che mi aspettavo.

È solo quando non riesci a pensare ad un buon nome che abbia senso non astrarre. Quando un buon nome è disponibile l'astrazione dovrebbe essere sempre preferita.

score 5 · Answer 2

Normalmente suggerirei esattamente ciò che dici di voler evitare: rompere in funzioni più piccole.

Il vantaggio non è in realtà per la riusabilità ma per il test delle unità. Ogni pezzo può essere testato indipendentemente, il che rende più semplice scrivere test. Inoltre rende generalmente più utili i test, perché se c'è un errore è già più focalizzato su dove si trova.

Se ci sono in effetti un gran numero di variabili comuni che arrivano e sono correlate, suggerirei a un altro refattore di metterle tutte in una struct o in una classe e passarle a ciascuna funzione.

Se non sono correlati, allora qualcosa suona strano nel dover passare un numero elevato a ciascuna di queste sottofunzioni. Forse in questo caso è necessario venire a cose con un approccio diverso: pensare a come rendere le unità di lavoro (le funzioni) più piccole possibili che possono essere composte insieme.

Non esiste un "uno" approccio corretto qui, è molto situazionale e soggettivo.