@Trev: Zeichenketten sind keine Kommentare. Kommentare werden nur durch # gekennzeichnet. Zeichenketten mitten im Code sind im besten Fall einfach nur unnötige Ausdrücke deren Ergebnis (die Zeichenkette) für nichts verwendet werden. Aber sie haben für die Sprache selber an bestimmten Stellen eine besondere Bedeutung zur Dokumentation. Und für Werkzeuge zur Dokumentation nicht an den von der Sprache spezifizierten Stellen, sondern teilweise auch noch anderswo.
Kommentare sollen dem Leser einen Mehrwert über den Code geben. Faustregel: Kommentare beschreiben nicht *was* der Code macht, denn das steht da bereits als Code, sondern warum er das macht. Sofern das nicht offensichtlich ist. Offensichtlich ist in der Regel auch was in der Dokumentation von Python oder verwendeten Bibliotheken steht.
Das was unter dem ``if __name__ …``-Guard steht gehört in eine Funktion damit keine globalen Variablen auf Modulebene existieren auf die man versehentlich in einer Funktion zugreifen könnte, was Programme schwerer verständlich und fehleranfälliger macht.
Grunddatentypen haben in Namen nichts zu suchen. Das ändert man während der Programmentwicklung gerne mal und dann hat man falsche, irreführende Namen im Quelltext oder muss die überall im Programm anpassen.
Wenn bei `created_list` der Typ aus dem Namen fällt, bleibt da nur noch `created` was keinen Sinn macht. Auch mit dem `_list` ist der Name nicht sinnvoll. Namen sollen dem Leser verraten was der Wert dahinter für eine Bedeutung im Programm hat. Das es sich um eine Liste handelt, und das die erstellt worden ist (das wird jede Liste), sagt dem Leser nicht was da eigentlich enthalten ist. `numbers` wäre beispielsweise passender.
Funkions- und Methodennamen beschreiben üblicherweise die Tätigkeit, welche die Funktion oder Methode durchführt. `test()` ist da *sehr* allgemein. Der Leser will wissen *was* da getestet wird. `ask_confirmation()` beispielsweise. Und dann könnte man die auch etwas allgemeiner halten und den eigentlichen Fragetext als Argument übergeben. Und man würde nach der Eingabe von weiteren Werten auch *nach* der Eingabe eines Wertes fragen und nicht davor. Wenn der Benutzer nämlich schon *vor* der ersten Eingabe die Frage verneint, dann hat Dein Programm ein Problem und läuft in eine Ausnahme.
Was mir der Name `make` sagen soll ist mir schleierhaft.
Man belegt nicht vor einer ``while``-Schleife eine Variable mit einem Dummywert der die Schleife nicht abbricht sondern macht daraus eine ”Endlosschleife” mit einem ``if`` an der passenden Stelle, welches die Schleife dann abbricht.
Bei einem ``if``/``else`` das über eine Bedingung `True` oder `False` zurück gibt, braucht man das ``if``/``else`` nicht, denn man hat ja bereits das Ergebnis der Bedigung das einen Wahrheitswert darstellt.
`make_input()` ist als Namen schlecht weil die Funktion nicht erstellt sondern den Benutzer fragt. *Der* macht dann die Eingabe, nicht die Funktion.
Was soll das `new_` bei `new_input`? Das hat keinen Informationsgehalt.
Auch hier ist wieder ein unnötiges ``if``/``else`` denn wenn der Benutzer 0 eingibt wird 0 zurückgegegen sonst das was der Benutzer eingegeben hat. Also letztendlich *immer* das was der Benutzer eingegeben hat. Die Abfrage macht keinen Sinn.
`average_result()` ist wieder keine Tätigkeit. Das wäre ein guter Name für das Durchschnittsergebnis. Da fehlt die Tätigkeit: `print_average_result()`.
Das mit den Namen geht weiter: `usable_list`. Was ist denn eine „verwendbare Liste“? Wie verhält die sich gegenüber einer nicht-verwendbaren Liste? Und der Datentyp ist da wieder drin. `numbers` wäre hier wieder ein passender Name.
`addition` macht auch keinen Sinn. Das ist die (Gesamt)Summe und keine „Addition“.
Die Schleife dort ist in Python ein „anti pattern“. Statt ``for i in range(len(sequence)):`` nur um dann über den unnötigen Laufindex auf das jeweilige Element zuzugreifen, iteriert man in Python direkt über die Elemente: ``for element in sequence:``.
Und auch das kann man sich sparen, denn es gibt die `sum()`-Funktion.
Zwischenstand (ungetestet):
Code: Alles auswählen
#!/usr/bin/env python3
def ask_confirmation(prompt):
prompt = f"{prompt} (y = yes | n = no): "
while True:
response = input(prompt)
if response in ["y", "n"]:
return response == "y"
def ask_number():
#
# FIXME Handle user input that's not an integer.
#
return int(input("Please enter an integer: "))
def print_average(numbers):
print("The average is", sum(numbers) / len(numbers))
def main():
numbers = []
while True:
numbers.append(ask_number())
if not ask_confirmation("Do you want to make more input?"):
break
print_average(numbers)
if __name__ == "__main__":
main()
Das mit der Frage bei jeder Zahl würde ich mir überlegen. Das ist nervig. Eine Leereingabe als Ende der Eingabe ist für den Benutzer einfacher als immer "y" plus Eingabetaste zwischen den Eingaben tippen zu müssen.
