1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › IT: Frauen, die programmieren und…
  6. Thema

"Programmieren" selbst "beibringen"

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


  1. Re: "Programmieren" selbst "beibringen"

    Autor: Bonita.M 06.12.18 - 08:31

    > Der Trick ist ja, Funktionen erst gar nicht so komplex werden zu
    > lassen. Jede beginnt ja erstmal mit einem Inhalt von null Zeilen.

    Es gibt da keinen Trick. Das ergibt sich aus der Notwendigkeit des Algorithmus.

    > Selbst das Extrahieren einer Funktion, die dann nur einmal genutzt wird,
    > kann sinnvoll sein, wenn man einen guten Namen findet - eine Funktion,
    > die aus zehn Zeilen Funktionsaufrufen besteht, die alle einen sprechenden
    > Namen tragen, und hinter denen sich jeweils Funktionen mit zwanzig Zeilen
    > befinden, die nirgendwo sonst aufgerufen werden, mag nicht optimal sein,
    > ist aber zigmal besser als eine Funktion mit 200 Zeilen.

    Dann schreib ich ein bisschen Kommentar in den Code rein der die größere Funktion ausmacht und hab einen gleichermaßen guten Effekt auf die Lesbarkeit.

  2. Re: "Programmieren" selbst "beibringen"

    Autor: mnementh 06.12.18 - 11:59

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Nein, eine Funktion muss nicht von mehreren Stellen aus genutzt werden.
    > > Das Stichwort unter dem Funktionen und Methoden fallen ist strukturierte
    > > Programmierung, ...
    >
    > Hier findest Du, was strukturierte Programmierung ist:
    > de.wikipedia.org
    > Irgnedwas von Funktionen kommt da nicht vor.
    >
    "Es beinhaltet zum einen die baumartige Zerlegung eines Programms in Teilprogramme (Prozeduren) und enthält somit das Paradigma der prozeduralen Programmierung."
    https://de.wikipedia.org/wiki/Strukturierte_Programmierung
    Oh ja, da heißt es Prozeduren. Manchmal werden Prozeduren und Funktionen darin unterschieden, dass letztere einen Rückgabewert haben. Aber in vielen Programmiersprachen ist es das gleiche, der Rückgabewert kann auch void sein.

    > > ... die Aufteilung in Funktionen dient der sinnvollen Strukturierung
    > > Deines Quellcodes. Es ist nicht erforderlich, dass eine Funktion von
    > > mehreren Stellen aus aufgerufen wird, ...
    >
    > Es ist aber auch nicht nötig und wenn eine Funktion wie in dem von dir
    > nicht zitierten Stelle zu viel Kontext aus der aufgerufenen Funktion
    > mitnimmt, dann ist das sogar unleserlicher als würde man das direkt in die
    > Funktion schreiben.
    Sorry, was? 100 Zeilen lange Funktionen/Prozeduren/Methoden sind schwerer zu verstehen, als wenn man diese in sinnvolle Funktionseinheiten mit sinnvoller Benennung und abgegrenzter Funktionalität zerlegt.

    Natürlich haben diese Unterprogramme einen eigenen Kontext. Das ist der Vorteil. Man kann über 10-20 Zeilen Code den Kontext gut erfassen, aber es schleppt sich kein Kontext weiter. Das Problem mit langen Unterprogrammen ist ja, dass in der Zeile die Du Dir gerade ansiehst ein Kontext benutzt wird, der 100 Zeilen zuvor ebenfalls manipuliert wurde. Das kann man nur noch schwer überblicken, der Code wird schwer wartbar und fehleranfälliger.

  3. Re: "Programmieren" selbst "beibringen"

    Autor: mnementh 06.12.18 - 12:02

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Der Trick ist ja, Funktionen erst gar nicht so komplex werden zu
    > > lassen. Jede beginnt ja erstmal mit einem Inhalt von null Zeilen.
    >
    > Es gibt da keinen Trick. Das ergibt sich aus der Notwendigkeit des
    > Algorithmus.
    >
    > > Selbst das Extrahieren einer Funktion, die dann nur einmal genutzt wird,
    > > kann sinnvoll sein, wenn man einen guten Namen findet - eine Funktion,
    > > die aus zehn Zeilen Funktionsaufrufen besteht, die alle einen
    > sprechenden
    > > Namen tragen, und hinter denen sich jeweils Funktionen mit zwanzig
    > Zeilen
    > > befinden, die nirgendwo sonst aufgerufen werden, mag nicht optimal sein,
    > > ist aber zigmal besser als eine Funktion mit 200 Zeilen.
    >
    > Dann schreib ich ein bisschen Kommentar in den Code rein der die größere
    > Funktion ausmacht und hab einen gleichermaßen guten Effekt auf die
    > Lesbarkeit.
    Nein, der Effekt ist nicht der gleiche. Du hast nämlich keine Trennung des Kontexts (lokale Variablen und ähnliches). Lange Funktionen haben daher oft mehr innere Abhängigkeiten, die den Code fragiler (schwerer zu ändern ohne Fehler zu verursachen) und schwerer verständlich werden lassen.

  4. Re: "Programmieren" selbst "beibringen"

    Autor: MickeyKay 06.12.18 - 14:45

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > Dann schreib ich ein bisschen Kommentar in den Code rein der die größere
    > Funktion ausmacht und hab einen gleichermaßen guten Effekt auf die
    > Lesbarkeit.
    Nein, Kommentare sind schlechter Programmierstil. Das macht man nicht mehr.
    Wenn du bereits beim Programmieren merkst "Oh, das könnte man nicht verstehen, das muss ich kommentieren", dann sage ich: "Nein! Du musst lesbaren Code schreiben!".

    Diese Ansicht ist genauso veraltet wie die Ansicht, dass Funktionen nur sich wiederholenden Code beinhalten sollten. Das war in den 80ern noch so - und auch ich hab das natürlich noch so gelernt, aber davon ist man inzwischen weg gegangen.
    Tatsächlich solltest du ALLES in Unterfunktionen auslagern. So lange, bis es nichts mehr auszulagern gibt. Sogar die Bedinungen hinter einem if (... oder while (... solltest du in eine eigene Funktion auslagern, um die Lesbarkeit zu erhöhen.

    Der Kontext durch Aufspaltung in Unterfunktionen ist übrigens sehr viel einfacher zu verstehen. (Google mal nach der Zeitungs-Metapher!)
    Du startest z.B. mit einer public-Methode als Einstiegspunkt in die Klasse. Diese wird von außen aufgerufen. Diese Methode hat nur 5 Zeilen. Der Code sollte so leserlich sein, dass du nur DIESE eine Funktion lesen musst, um zu wissen, was der Rest des Codes macht. Wenn du dann in die Details einsteigen willst, gehst du eine Stufe tiefer in die nächsten Funktionen.
    So erreichst du nicht nur eine bessere Lesbarkeit, sondern es hilft auch bei der Fehlersuche, da du den Bug EXTREM schnell eingrenzen kannst. Arbeitest du zudem ordentlich test driven, hat sich das mit den Bugs sowieso fast von alleine erledigt.

  5. Re: "Programmieren" selbst "beibringen"

    Autor: GodsBoss 06.12.18 - 21:42

    > > Der Trick ist ja, Funktionen erst gar nicht so komplex werden zu
    > > lassen. Jede beginnt ja erstmal mit einem Inhalt von null Zeilen.
    >
    > Es gibt da keinen Trick. Das ergibt sich aus der Notwendigkeit des
    > Algorithmus.

    Sowas höre ich oft: "Das kann man nicht anders umsetzen. Das ist intrinsische Komplexität. Das geht nicht besser."

    Bis es jemand besser macht.

    > > Selbst das Extrahieren einer Funktion, die dann nur einmal genutzt wird,
    > > kann sinnvoll sein, wenn man einen guten Namen findet - eine Funktion,
    > > die aus zehn Zeilen Funktionsaufrufen besteht, die alle einen
    > sprechenden
    > > Namen tragen, und hinter denen sich jeweils Funktionen mit zwanzig
    > Zeilen
    > > befinden, die nirgendwo sonst aufgerufen werden, mag nicht optimal sein,
    > > ist aber zigmal besser als eine Funktion mit 200 Zeilen.
    >
    > Dann schreib ich ein bisschen Kommentar in den Code rein der die größere
    > Funktion ausmacht und hab einen gleichermaßen guten Effekt auf die
    > Lesbarkeit.

    Nein, hast du nicht. Wenn du bei der 200-Zeilen-Funktion wissen willst, was sie macht, musst du die 200 Zeilen durchgehen, selbst wenn du nur nach den Kommentaren schaust. Bei der 10-Zeilen-Funktion erhältst du sofort einen groben Überblick und kannst dich sofort auf die für dich relevanten Teile stürzen, wenn du willst.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  6. Re: "Programmieren" selbst "beibringen"

    Autor: MickeyKay 07.12.18 - 12:07

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > Es gibt da keinen Trick. Das ergibt sich aus der Notwendigkeit des Algorithmus.
    Witzig, dazu halte ich gleich in einer Stunde einen Vortrag und stelle dort einen entsprechenden "Trick" vor.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. SoftwareentwicklerIn für Embedded Systeme (m/w/d)
    BOGE KOMPRESSOREN Otto Boge GmbH & Co. KG, Bielefeld
  2. Agile Coach (m/f/d)
    BSH Hausgeräte GmbH, München
  3. IT-Consultant (m/w/d) ECM/DMS
    Tönnies Business Solutions GmbH, Rheda-Wiedenbrück
  4. IT Solutions Expert SAP (m/w/d)
    DLR Gesellschaft für Raumfahrtanwendungen (GfR) mbH, Oberpfaffenhofen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 599,99€
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de