È necessario altro esplicito negli inizializzatori? [duplicare]

Question

È necessario altro esplicito negli inizializzatori? [duplicare]

#1 da (5 voti)
#2 da (4 voti)
#3 da (1 voti)

-2

Ho un inizializzatore personalizzato come questo:

- (id)initWithLocation:(CLLocation *)location
{
    if (location == nil)
    {
        return nil;
    }

    self = [super init];

    if (self)
    {
        self.location = location;
    }

    return self;
}

A volte i miei colleghi mi chiedono di racchiudere tutto (tranne il return ), che segue la prima coppia di parentesi graffe, in una clausola else :

- (id)initWithLocation:(CLLocation *)location
{
    if (location == nil)
    {
        return nil;
    }
    else
    {
        self = [super init];

        if (self)
        {
            self.location = location;
        }

        return self;
    }
}

Ma non sono sicuro. Qual è il punto? La prima condizione if è un rapido controllo della morte. Se il parametro non viene fornito, non viene fornita alcuna istanza. Questo serve da imposizione per fornire un parametro. else sembra qui superficiale poiché è implicito nel flusso del codice.

Quale sarebbe il vantaggio di averlo?

objective-c

posta Earl Grey 19.11.2013 - 12:24

fonte

3 risposte

4

What would be the advantage having it?

Assolutamente no, secondo me. Aggiunge un livello non necessario di nidificazione, mentre non dovrebbe essere difficile interpretare l'istruzione "fail fast" if (foo == nil) return su un metodo.

risposta data 19.11.2013 - 12:37

fonte

1

L'ulteriore istruzione else non avrà alcun impatto sulla logica o sulle prestazioni. Ma ha ancora i suoi vantaggi.

Innanzitutto, aumenterà la leggibilità mostrando una chiara catena di decisioni. Andando oltre, è possibile dichiarare una variabile all'inizio dell'inizializzatore per mantenere il valore di ritorno. Quindi nella parte principale è possibile modificare la variabile e / o assegnargli un nuovo valore. L'ultima riga sarebbe l'istruzione return . Ciò aumenterà ulteriormente la leggibilità.

Un altro vantaggio è che il design if\else ti consente di tracciare le opzioni mutue esclusive. Se hai bisogno di aggiungere un'altra opzione, tale stile ti aiuterà a posizionarlo rapidamente nella giusta posizione senza ulteriori modifiche al codice e senza il rischio di errori durante l'implementazione della nuova logica.

risposta data 19.11.2013 - 12:34

fonte

Leggi altre domande sui tag objective-c

Protezione della domanda contro la pirateria [chiusa] Vantaggi del porting della libreria C in C ++ [chiuso]

score 5 · Accepted Answer

Penso che ciò di cui tu e il tuo collega state discutendo stia esprimendo l'intento nel vostro codice.

Ci sono due casi generali che dobbiamo considerare per rispondere alla tua domanda.

Controlli di sicurezza
Separazione della logica dell'applicazione / ramificazione condizionale

Controlli di guardia
Il tuo esempio dimostra il primo caso: un controllo di guardia. Un controllo di guardia controlla gli input o altri input necessari per assicurarsi che le cose siano valide. Se le cose non sono valide, la funzione deve immediatamente uscire o tornare.

La saggezza convenzionale che ho riscontrato è che i controlli di guardia non contano realmente come parte della logica della tua funzione. Un programmatore esperto sfogliando il codice prenderà nota dei controlli di guardia e quindi inizierà a prestare attenzione durante la fase di inizializzazione nell'esempio.

Quindi, nel caso dei controlli di guardia, non hai davvero bisogno del blocco else {} per esprimere chiaramente l'intento della tua funzione.

Ramificazione condizionale
L'altro caso in cui vi è una vasta logica applicativa richiede una considerazione diversa per esprimere l'intenzione. La versione semplificata ha questo aspetto:

if( A )
{
    ...
    doFoo()
}
else 
{
   doBar()
}

Le preoccupazioni sull'esprimere l'intenzione ora ruotano attorno a quanto codice rappresentano quelle ellissi. Se è "molto" di codice, il tuo collega è corretto ed è necessario avvolgere il ramo not A con un'istruzione else e potenzialmente il proprio set di parentesi. Il ragionamento qui è che non vuoi che i futuri manutentori debbano affrontare troppi sovraccarichi mentali mentre cercano di capire la tua funzione. Il else dimostra chiaramente che hai due percorsi principali.

Quindi per rispondere alla tua domanda, devi chiedere quale opzione esprime più chiaramente il tuo intento come sviluppatore del codice.