Perché si dovrebbe usare una variabile temporanea monouso?

Risposta breve: non lo facciamo. Entrambi gli esempi sono assolutamente soddisfacenti.

Ci sono tre motivi per cui le persone usano comunque variabili temporanee (come nel tuo primo esempio):

1. Assegna un nome esplicito al valore intermedio (ora sappiamo che è un message , non solo una stringa vecchia).
2. Aiuta a impedire che le dichiarazioni diventino troppo lunghe e complesse.
3. Semplifica il debug in fasi successive, perché è possibile eseguire il passaggio singolarmente di ciascuna parte (anche se esistono debugger di passaggi che funzionano con precisione della sub-linea).

nella maggior parte delle lingue che non è necessario, il che è utile se si desidera utilizzare un getter e passarlo in un metodo:

bar.doBaz(faa.getFoo())

ma può migliorare la leggibilità separando le chiamate soprattutto quando è una funzione non banale

riduce anche l'impronta orizzontale della chiamata al costo di una linea aggiuntiva (a condizione che il nome della nuova variabile sia breve)

Ci sono delle volte in cui una variabile extra può essere di aiuto per la leggibilità generale, specialmente quando si valuta una lunga espressione all'interno di una if o una chiamata di funzione che fa sì che il codice vada via dal lato destro dello schermo.

In Java 5 o versioni successive (e in molte lingue simili), una variabile extra può essere utile per trovare la causa delle eccezioni del puntatore nullo. Considera il seguente codice Java che si basa su "autoboxing" di Java per convertire Integer oggetti in una primitiva int :

public int add(Integer firstIntObj, Integer secondIntObj) {
    return firstIntObj + secondIntObj;
}

Getterà una NullPointerException quando converte un oggetto non inizializzato ( null ) Integer in un int primitivo, ma questa eccezione non indica quale oggetto ha causato l'eccezione perché i due possibili colpevoli sono sullo stesso linea. Quanto segue esploderebbe su una riga diversa per ogni input null , quindi il numero di riga nell'eccezione indicherà quale era null :

public int add(Integer firstIntObj, Integer secondIntObj) {
    int first = firstIntObj;
    int second = secondIntObj;
    return first + second;
}

Un modo migliore per gestire questo è lanciare la tua eccezione descrittiva in modo che qualcuno che chiama questo metodo possa diagnosticare il proprio problema senza bisogno del tuo codice sorgente:

public int add(Integer firstIntObj, Integer secondIntObj) {
    if (firstIntObj == null) {
        throw new IllegalArgumentException("First argument was null!");
    }
    if (secondIntObj == null) {
        throw new IllegalArgumentException("Second argument was null!");
    }
    return firstIntObj + secondIntObj;
}

Questa tecnica può essere utilizzata per suddividere qualsiasi linea che possa generare più di un'eccezione. L'utilizzo di variabili distinte è meno digitante rispetto a un'eccezione descrittiva: è veloce e sporca.

In questo caso non ha molta importanza ma quando lavori con sistemi più grandi può essere un problema come:

1. Semplifica molto il debug
2. Se hai l'abitudine di compattare il tuo codice per quanto mi riguarda lo rende effettivamente leggibile, ovvero:

square(getNum1(var1,var2[(param1+(param2%2))]),obj1.getNum2(((ptr1+dynamicOffset1)+5)(getMult(NULL))))