Wie viele Zeilen Quellcode sollte eine Funktion haben?
Das ist einfach eine Frage die mich brennend interessiert, wie viele Zeilen schreiben andere in ihre funktionen? Bei mir ist das immer ganz unterschiedlich, wenn ich ehrlich bin mag ich es mehrere grössere Funktionen zu haben die auf meherern kleineren basieren. Die grösseren sind dann immer so max. 45 Zeilen lang, allerdings unterschtuezte ich auch gerne diese grösseren Funktionen auch mal mit so semi grösseren Funktionen (die sind dann so max. 20 Zeilen lang). Was ist eure Meinung dazu?
Und ja, ihr alten C Knacker ich weiss das ich 1212931 1 Zeilen lange Funktionen brauche weil sonst mein Programm 0.000000000000001 Millisekunden langsamer läuft, aber ich finde der Optik halber wird das dann immer sehr unuebersichtlich.
(Bei Datein gerne das gleiche)
1 Antwort
ich weiss das ich 1212931 1 Zeilen lange Funktionen brauche weil sonst mein Programm 0.000000000000001 Millisekunden langsamer läuft
Das zeigt sehr gut, dass du noch keine Ahnung davon hast, was gute Funktionen ausmacht.
Vereinfacht gesagt: Eine Funktion übernimmt genau EINEN EINZIGEN Arbeitsschritt. Nicht mehr, nicht weniger.
Der Grund dafür liegt nicht in irgendwelchen Millisekunden, die du herbei fabulierst, sondern ist der, dass es das Debuggen und Warten auch nach 6-12 Monaten (oder länger) überhaupt erst möglich macht. Wenn das Programm eine Datei nicht richtig lädt, dann such ich nach dem verwendeten FileReader - und nicht nach irgendeinem 200 Zeilen-Funktionsungetüm namens "LadeMalDenGanzeKram".
Allerdings rede ich auch vom professionellen (Arbeits-) Bereich. Privat und zum Hobby kannst du das natürlich handhaben, wie du lustig bist. Kannst ja mal das hier anschauen: https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-clean-code/ Da legen manche Arbeitsgeber bzw. Entwicklerteams Wert drauf.
Ich finde zwar den ersten Satz nicht sehr nett ausgedrueckt
Sei nicht so mimosenhaft, wenn du im Gegenzug andere als
ihr alten C Knacker
bezeichnest.
und mir sagen wie du denn deinen Privaten Code schreibst oder ob du gleich 9/11 2.0 startest sobald du eine Funktion länger als 20 Zeilen siehst
Kann ich machen.
Nein, ich bin zu alt, als dass ich noch ein Fass aufmachen würde, wenn mal wieder ein Jungspund meint, er wüsste alles besser als alle anderen Entwickler vor ihm (kein Sarkasmus). Wenn also jemand meint, mir eine Methode mit 200 Zeilen zu präsentieren, dann überarbeite ich die eben und erwähne das auch im nächsten Stand up.
Du sagtest, du hättest vier Jahre Erfahrung. Jetzt weiss ich natürlich nicht, ob du bisher nur bei kleinen Läden gearbeitet hast oder auch schon in richtigen Entwicklerteams. Ich bin in letzterem Bereich und kann dir von daher sagen: "Lone ranger" mit ihrem supereigenen Code halten sich nicht wirklich lange in der Industrie. Denn was du als tollen Code ansiehst, ist für andere (wie z.B. mich) eine Zumutung, die dann jedes Mal überarbeitet werden muss, damit auch andere mit deinem Code arbeiten können. Diese Überarbeitungen kosten aber Zeit und damit Geld. Und wenn du permanent diese Kosten verursachst, weil du dich quasi selbstverwirklichen willst, anstatt dich an die Coding Guides zu halten (vernünftige Softwareschmieden haben so etwas), dann hast du sehr schnell ein klärendes Gespräch mit deinem Vorgesetzten.
Der Grund dafür ist nicht, dass dich dann keiner leiden kann, sondern dass man in Team zusammen arbeitet. Und das bedeutet auch, dass man den Code auf eine Art und Weise verfasst, die für jederman verständlich ist. Persönliches Gusto steht da hinten an. Zum Beispiel empfinde ich in der Arbeit unsere Sourceformatierung etwas übertrieben. Aber hey - ich werde dafür bezahlt, dass ich u.a. auch mit so einem Code arbeite und unverständlich ist er nicht. Nur übertrieben formatiert - nach meinem persönlichen Geschmack.
Im privaten Bereich habe ich ganz, ganz früher (letztes Jahrtausend - wieder kein Sarkasmus) noch klassischen Spaghetticode programmiert und da kamen später auch die von dir präferierten Riesenfunktionen zum Einsatz. Nach den ersten paar WTF-Momenten, in denen ich mich in meinem eigenen Code zu Tode gesucht habe, habe ich dann angefangen, meine Methoden zu gliedern und zu verkleinern. Am liebsten sind mir Methoden, die auf einmal auf den Bildschirm passen und direkt, ganz ohne Scrollen, einzusehen sind.
Ich wäre jetzt gerne auf dein Codebeispiel eingegangen, aber das erschliesst sich mir nicht so ganz. Da scheinen mir ad hoc Methoden und Getter/Setter thematisch bunt gemixt zu sein. Aber ich versuch's mal so:
Bei mir gäbe es eine Klasse ObjectList, die würde auch einen Getter auf Data beinhalten. Wenn ich jetzt ein Object der Liste hinzufügen will, heisst das bei mir (man beachte die Groß- und Kleinschreibung: Das klein geschriebene ist ein Objekt - nicht die Klasse!) objectList.Data.add(xxx); Damit gäbe es kein createListElement() und auch kein upodateObjectList() (das geschieht automatisch) und die createBaseObjectList() liegt dann mit ihrer Funktionalität einfach im Konstruktor.
Ich hoffe, ich konnte so weit weiterhelfen - auch wenn ich einer diese alten C Knacker bin.
Mhh ich denke wird reden ein wenig vorbei, aber egal.
Erstens: Es tut mir leid ich war wirklich ein wenig unhöfflich bitte entschuldigen Sie.
Zweitens: Dein Beispiel hat mir sehr gefallen :D Genauso hätte ich das vermutlich auch gemacht (wenn auch nach villeicht 1-2 ueberarbeitungschritten hehe), doch ich meinte das damit garnicht. Mir ging es primär darum das es villeicht doch mal schlauer ist ein (semi) "Spaggetti Code" zu schreiben, das war mehr eine Frage, aber wenn ich mir das angeucke war das echt furchtbar ausgedrueckt Denn ich finde (und das sage ich zu 100% nur als höchtens Fortgeschrittener Programmierer) das ich es auch sehr unangenehm finde wenn die Funktion nicht auf den Screen passt, was ich aber noch viel mehr hasse ist wenn ich nicht Vorne und Hinten erkenne, was das Problem bei so einigen dieser Funktionen ist. Aber wie gesagt das mit keiner Ihrer Nachrichten wirklich was zu tun, und das ist villeicht auch einfach was was ich nicht verstehen kann.
Es stimmt zwar das ich mich gerne von Coding-Norms entferne, aber ich bin ganz sicher niemand der einen Code-Guide so missachtet das man sich nicht sicher ist ob das noch was mit Programmierung zu tun hat (möchte ich nur so richtig stellen, sry fuer diesen dummen Kommentar).
Den 5 Absatz wenn man die Zitate am Anfang ignoriere verstehe ich nicht ganz, aber ich lasse das mal aus.
Tatsächlich du den Sachen bin der kleinen Läden und Teams, ich habe so halb halb. Ich habe schonmal in der grössten Firma in unsere Umgebung gearbeitet, das war aber ein Elektronik Hersteller von daher habe ich da wenndann mit Arduino rumspielen duerfen. Sonst war eig nie was spannendes los.
- ich bin zu alt, als dass ich noch ein Fass aufmachen würde, wenn mal wieder ein Jungspund meint, er wüsste alles besser als alle anderen Entwickler vor ihm (kein Sarkasmus)
Autsch aber das habe ich wahrscheinlich verdient, egal, ich verstehe den Punkt sehr gut ich selbst habe schon die Erfahrung gemacht auch wenn ich wie gesagt in der Industrie erst 4 Jahre bin, aber versichern Sie sich das ich den aller grössten Respekt vor älteren Entwicklern habe, ich möchte sehr viel von Ihnen lernen, aber an der Kommunikation scheitert das leider ein wenig. Ich verstehe das Mindset: "Die Jungend mit ihren coolen JavaScript Sachen die wir schon vor 30 Jahren entwickelt haben.", dem ich selbst zustimmen kann, doch ich finde das ewige hin-und-her beider Partein ziemlich nervig (wobei mich die meisten als die Jungen ansehen wuerden). Von daher wuerde ich gerne mal wissen was sich den Ihrer Meinung nach ändern muesste das sich das Coding wieder verbessert (wie gesagt ich fände das nur interessant).
Wie Sie villeicht gemerkt haben, habe ich bei fast der gesamten DIskussion Punkte völlig wirkuerlich gewählt was ein gutes Beispiel ist was ich an diesem 100 FUnktionen schreiben nicht mag, aber das ist ein dummes Argument weil ich das wie gesagt selbst tue :D
Von daher wuerde ich gerne mal wissen was sich den Ihrer Meinung nach ändern muesste das sich das Coding wieder verbessert (wie gesagt ich fände das nur interessant).
Also das "du" ist schon in Ordnung, ich brauche nicht gesiezt zu werden.
Es gibt ja diesen Spruch: "Zu viele Köche verderben den Brei." Genau das gleiche Problem gibt es bei der Softwareentwicklung in Teams. Wir sind in unserem Team:
- Ein Softwarearchitekt, der gleichzeitig Teamleiter ist und erstaunlicherweise den Job richtig gut macht. Kein Witz: Gute Teamleiter sind verdammt selten.
- Zwei Senior Developer/Architects (ich bin einer davon). Schwerpunkte: Alles, was ein "C" im Namen hat (C, C++, C#, JavaScript) und Protokolle/APIs.
- Einen Software Developer, Schwerpunkt Frontend (JavaScript, Angular).
- Eine Kryptologin und ehemalige Entwicklerin, welche für die kryptographischen Algorithmen verantwortlich zeichnet (Bereich IT Security).
- Einen Auszubildenen(!) im 3. Lehrjahr.
- Einen Tester.
- Eine Senior Testerin.
Und wir sind nur eines von drei Entwicklerteams. Jetzt muss ALLES koordiniert werden, damit eine vernünftige Software am Ende heraus kommt. Schwierigkeiten sind dabei u.a.
- die Kryptologin formuliert ihre Algorithmen in Pseudocode mit mathematischen Anmerkungen. Da hat unser Azubi wenig Chancen, etwas zu verstehen.
- der andere Senior Developer bereitet sich schon auf die Rente vor. Seine Bereitschaft z.B. seinen Codingstil noch an den Rest des Teams anzupassen ist zwar noch vorhanden, aber nicht wahnsinnig ausgeprägt - um es mal so zu sagen.
- Ich habe den Schwerpunkt Backend. Das heisst, dass es manchmal etwas kniffliger wird, wenn der Frontend-Entwickler und ich uns detailtechnisch austauschen müssen. Ich spreche kein Angular und er ist nicht ganz so fit in C++.
- Und unsere Tester haben nicht nur die sprachliche Barriere zu überwinden (ukrainisch bzw. Python), sondern haben auch technisch ein völlig anderes Bestreben als wir Entwickler.
Bei uns ist z,B, auch ein Standardfall, dass niemand einfach so Code in die gemeinsame Codebasis eincheckt, sondern dass es vorher immer einen Review von mindestens einem anderen Teammitglied gibt.
Jetzt stell dir mal den Fall vor, der genau so auch geschehen ist:
Unser Azubi hat seinen Code mehr oder weniger "frei Schnauze" geschrieben, ähnlich, wie du es beschrieben hast. Also seine Methoden waren auch ziemlich "dick" und das Prinzip der singulären Arbeitsschritte in den Methoden hat er auch nicht befolgt.
Jetzt wollte er den Code einchecken und hat einen Review gebraucht.
Die Kryptologin macht keine vollen Reviews mehr, dazu ist sie mittlerweile zu weit von der Codebasis entfernt. Der andere Senior Developer hat einfach gesagt: "Das tue ich mir nicht an" und hat den Task offen stehen gelassen. Der Teamleiter hat eine externe Schulung gehalten. Der Frontendler konnte den Review nicht machen, weil es eine Backendänderung war.
Also habe ich den Review gemacht.
Und erwartungsgemäß (er ist halt noch Azubi, da gilt noch etwas Welpenschutz) hat sein Code nicht funktioniert. Aber ich konnte es ihm nur schwer sagen, an welcher Stelle der Fehler lag. Ich musste mit Dateinamen, Methodennamen UND Zeilennummern arbeiten - eben weil die Methoden so riesig waren.
Kleiner Spolier: Er hat seine Bugs bis jetzt noch nicht fixen können, weil er selber Schwierigkeiten hat, sich in seinem Code zurecht zu finden. Er ist derzeit erst einmal an einem kräftigen Refactoring dran.
Als Azubi - unschön, denn er hat unnötig Zeit verbraten. Hätte er sich gleich an die Coderichtlinien gehalten, wäre das Problem schon vor Wochen zu lösen gewesen. Aber als bezahlter Entwickler kannst du dir so etwas nicht allzu häufig oder lange erlauben.
Was sind also meine Ideen zum Verbessern des Codings?
- Als Teamleiter auch wirklich Leute einsetzen, die den Job machen wollen. Nicht nur des Geldes wegen oder um sich zu profilieren und um Himmels Willen keine Leute aus Sales oder Marketing (habe ich auch schon erleben müssen). Die sprechen nicht einmal die gleiche Sprache wie die Entwickler und Tester.
- Die Alten (also meine Wenigkeit) müssen einfach etwas Nachsicht mit dem Nachwuchs zeigen. Dummerweise sind aber nicht wenige Senior Developer geistig ziemlich fest gefahren in ihren Mustern. Da muss man einfach über seinen Schatten springen.
- Die Jungen sollten sich im Klaren sein, dass sie nicht die neuen Superstar-Developer sind, auf die die ganze IT-Welt nur gewartet hat. Da hilft ggf. sich klar zu machen: Der alte Sack, der dir gerade erklären will, wie das Coding funktioniert, hat die Entstehung des Internets miterlebt und daran mitgewirkt und noch mit DOS 5.0 gearbeitet - da gab es Windows noch gar nicht als Betriebssystem!
Ansonsten ist mein wichtigster Tipp für alles: Frage immer nach dem WARUM. Nimm' nie etwas einfach als gegeben hin, sondern frage auch immer: "WARUM soll ich es so und nicht anders machen? WARUM sind diese Richtlinien eingeführt worden? WARUM wird Software heutzutage so entwickelt?" Das Eruieren dieser Themen - das bringt dich dann wirklich weiter.
Ahh vielen Dank fuer die Antwort, finde ich sehr interessant danke auch fuer denn Tipp :D
Aha, sehr interessant. Ich bin ehrlich ich bin noch zum Jung um zu arbeiten und in Praktikas musste ich immer meistens nicht mal coden xD
Ich finde zwar den ersten Satz nicht sehr nett ausgedrueckt aber was erwarte ich bei einem anscheinend schwer zu verstehenden Sakasmus.
Trozdem finde ich zumbeispiel updateObjectList(); was eine FUnktion die zwar 100 Zeilen lang ist aber gut auskommentiert besser als: createBaseObjectList(); updateObjectList(); createListElement(); etc pp. Funktionen, das ist aber meine Meinung und ich denke ich wuerde dafuer von meinem Arbeitgeber geschlagen werden, aber nun ich habe auch erst 4 Jahre Erfahrung (das ist btw kein Sakasmus)
Trozdem könntest du mir die Frage gerne ein wenig genauer beantworten und mir sagen wie du denn deinen Privaten Code schreibst oder ob du gleich 9/11 2.0 startest sobald du eine Funktion länger als 20 Zeilen siehst (sorry fuer den Joke).