return Booleans trivial?

Question

return Booleans trivial?

#1 da (6 voti)

2

Sto scrivendo un semplice pezzo di codice. È una funzione che ha permesso all'utente di prelevare un po 'di soldi. Ci sono alcune restrizioni a questo però.

L'utente non può prelevare più del limite di prelievo specificato.
L'utente non può prelevare più denaro che ha.

Lo script termina se ciò accade e fa sapere agli utenti. In caso contrario, l'utente può ritirare il denaro e gli aggiornamenti del saldo, ricevono anche un messaggio di conferma.

Ora la mia domanda è se dovessi restituire False se colpiscono entrambi i casi 1 o 2? E dovrei restituire True se le transazioni si completano correttamente?

Non ho piani in corso in cui avrò bisogno dei booleani dalla chiamata di funzione. Ma mi chiedo è buona pratica di codifica per restituire qualcosa in un caso come quello in cui la funzione potrebbe avere percorsi diversi.

Alcuni esempi di codice (Python):

limit = 500
balance = 5000

def withdraw_money(amount):
    if amount > limit:  # above the limt
        print('You cannot withdraw more than ${}'.format(balance))
        return False
    elif amount > balance:  # not enough money
        print('Insuffecient funds')
        return False
    else:  # actually worked
        balance -= amount
        print('Your new balance is ${}'.format(balance))
        return True

programming-practices python

posta Vader 31.01.2014 - 04:17

fonte

1 risposta

Leggi altre domande sui tag programming-practices python

Che cosa dice Scrum riguardo alle demo tecnologiche? Ho un'eccezione non eccezionale. Ciò viene generato da un'API utilizzata nel mio progetto. È standard per registrare errori come questi o gestirli senza registrazione [duplicato]

score 6 · Accepted Answer

Non esiste una convenzione standard per il ritorno dei booleani dalle funzioni. Se la funzione restituisce true o false, spetta a te, autore di quella funzione, determinare quale sia il significato di ciascun valore e in che modo il chiamante dovrebbe reagire a ciascuno di essi.

Tuttavia, una cosa che consiglio vivamente è che la tua funzione dovrebbe SOLO restituire un valore booleano se ti aspetti che il chiamante guardi il risultato e agisca di conseguenza come parte del flusso di lavoro normale (in altre parole, False non è più un fallimento di quanto lo sia True).

D'altra parte, se la tua intenzione è quella di restituire un booleano come un modo per indicare se la chiamata alla funzione è riuscita, c'è una convenzione per questo. In tal caso, non restituire nulla . Invece, se il chiamante chiama la tua funzione e la tua funzione ritorna, sarebbe considerato un successo. Se qualcosa all'interno della tua funzione fallisce, solleva un'eccezione.

I vantaggi di farlo in questo modo è che non devi scrivere codice simile a questo:

if not withdraw_money():
    .... handle error ....
    return

if not do_something():
    ... handle error ...
    return

if not do_something_else():
    ... handle error
    return

Invece, potresti scrivere:

try:
    withdraw_money()
    do_something()
    do_something_else()
except:
    ... handle all errors in one place ...

Quindi ora la tua logica effettiva non è mescolata con la gestione degli errori. E se usi la gestione delle eccezioni in tutta l'applicazione, molte volte sarai in grado di definire il blocco try-except ad un livello più alto e tutte le chiamate di funzione da quel punto in giù possono semplicemente focalizzarsi sull'implementazione della funzione effettiva, non cercando successo / fallimento in ogni singolo passaggio.

L'altro vantaggio è che le condizioni di errore sono molto più espressive. Se il chiamante torna "Falso", sa che qualcosa è fallito, ma potrebbe essere qualsiasi cosa. Se un chiamante recupera InsufficientFundsError () come tipo di eccezione, sa molto di più su quale condizione di errore ha causato il problema.

Aggiornare: Come ha sottolineato Robert Harvey, l'uso delle eccezioni è in qualche modo controverso nella comunità degli sviluppatori e in diversi linguaggi di programmazione l'uso delle eccezioni può variare. Sto orientando questa risposta verso Python perché questo è ciò che OP sta imparando.

Anche in python, si otterranno argomenti secondo cui le eccezioni dovrebbero essere solo per situazioni veramente eccezionali ma poi si ottiene un territorio molto soggettivo rispetto a ciò che è considerato veramente eccezionale. Chiaramente se un chip RAM si inverte un po 'a causa di un errore hardware, questa è una condizione eccezionale. Che dire del file di configurazione mancante?

Quindi molto di questo arriverà al tuo stile di programmazione personale e questa risposta sicuramente riflette la mia, quindi leggila con un pizzico di sale. Proprio come l'esempio di Robert con il dizionario python "che è necessario per restituire un oggetto valido (come in una ricerca del dizionario)" Tendo a scrivere la maggior parte del mio codice in modo tale che se una funzione restituisce un valore, I richiede per restituire un valore. Non ne ho bisogno, ma è la mia scelta su come definire la firma di quella funzione e su come intendo utilizzarla.

Se sei nuovo alla programmazione, ti consiglio caldamente di provare cose diverse e modificare il modo in cui strutturi il codice, in modo che tu possa vedere da te quali costrutti / convenzioni funzionano meglio e hanno più senso per te.