Programmieren Mädchen-Code

"Girly Code" hab ich in den letzten 20 Jahren meiner Programmiertätigkeit nie gehört. Ein bemerkenswert "gängiges Synonym" also.Dass allerdings ein Programm ästhetisch sein kann, nicht nur in seiner fertigen, ausführbaren Form, sondern auch als Quelltext hinter den Kulissen, ist unbestritten. Ich behaupte sogar, es ist eine Form von Kunst, natürlich eine mit stark begrenztem Publikum.Dass ferner ein ästhetisches Programm viel zu Klarheit beiträgt, Wartbarkeit, nicht selten auch Positives zu späteren Laufzeiteigenschaften, ist etwas, das man heute gerne unter den Tisch fallen lässt. Die kurzfristige Kostenentwicklung im Rahmen eines Projekts o.ä. ist stets viel wichtiger als die langfristige, nachhaltige. Dabei ist Ästhetik nicht einmal teuer. Viele Menschen haben nur einfach keinen Sinn dafür.

Softwarequalität ist keine Frage des Geschlechts! Wer Code schlechter Qualität verbreitet, ist kein cooler Nerd, sondern jemand,der das Ende der Achtziger verschlafen hat.Dieser Artikel gehört eher in die Bravo als in die Zeit.

Was ist das für ein Unsinn? Der Begriff "Girly code" ist mitnichten gängig. Der Begriff wurde bestimmt schon mal gebraucht, aber nur, weil er einen syntaktisch korrekten Ausdruck darstellt. Darüberhinaus ist er eine Erfindung des Autors. Als IT-Profi habe ich "Girly code" noch nie gehört.Vor allem: auch inhaltlich ist der Begriff Unsinn. Wie der Programmcode aussieht ist keineswegs so wichtig. Architektur einer Software und Design der Implementierung sind bestimmend. Eine optisch übersichtliche Gestaltung des Programmcodes ist letztendlich eine Selbstverständlichkeit, die dazugehört, der aber für sich gesehen keineswegs eine solche Bedeutung zukommt. Ich würde sagen: Der Verfasser ist ein Aufschneider, der mit großem Geschwätz Werbung für seine Firma machen will. Das sich die Zeit für sowas hergibt. Siehe Frage im Betreff.

Ich glaube, man muss zwischen Design und Realisierung des Programms unterscheiden.Schoenheit in der Realisierung (dem Programmtext) ist schlichtes Handwerk. Einrueckungen, aussagekraeftige Variablen, klare Beschreibungen/Kommentare von Modulen, usw. sind einfach handwerkliche Faehigkeiten, die man erwarten kann/sollte. Spaghetticode sollte bei (professionellen) Programmierern schlichtweg nicht toleriert werden. (Er wird nauterlich im Interesse der allmaechtigen Deadline toleriert.) Schoenheit im Design hingegen ist ein zweischneidiges Schwert. Nicht immer laesst sich z.B. das optimale Design mit der verwendeten Programmiersprache optimal realisieren. Dann ist zwar die Loesung schoen, die Umsetzung aber kompliziert, umfangreich und so wieder schlechter verstandlich.Manchmal stellt sich auch die Frage, ab wann die Loesung so elegant ist, dass sie nicht mehr nachvollziehbar ist. Klar, das kann durch Kommentare ausgeglichen werden - aber nur zum Teil.Die aesthetisch/logisch optimale Loesung fuer eine Aufgabe ist meistens auch eine Loesung, die relativ unflexibel ist - etwas Neues hinzuzufuegen wird dann teilweise sehr schwierig. Ich habe mir schon manches Mal gewuenscht, dass meine Vorgaenger den einfachen, zuverlaessigen und Standard-konformen Weg gegangen waeren statt die "coole, intelligente, schnelle" Abkuerzung zu nehmen.

Jetzt aber mal halblang:Im Artikel wird die Herkunft des Begriffs "Girly code" doch einwandfrei erklärt; ich kannte diese Bezeichnung bislang auch nicht und sie ist sicherlich nicht gängig, aber eine Erfindung des Autors ist sie nachweislich nicht.Wichtiger Quellcode wird interessanterweise häufiger von Menschen gelesen als von Maschinen; dennoch programmieren gerade unerfahrene Softwareentwickler so, als ob die einzige Zielgruppe aus ihrem Rechner besteht. Ich würde mich nicht wundern, wenn Programmieren das menschliche Gehirn ähnlich nutzt und beansprucht wird, wie beim Schreiben oder Komponieren. Insofern ist es tatsächlich interessant sich auch als Softwareentwickler mit Schreibtechniken und Stilistik zu beschäftigen. Das Bild vom Programmierer als Ingenieur ist meiner Meinung nach nicht nur falsch, sondern könnte sogar ein Grund für das Scheitern vieler Softwareprojekte sein. Vertreter der "Softwareingenieur"-Metapher bemühen oft Argumente, nach denen das planende und sorgfältige Vorgehen eben gerade einen Vergleich zum Ingenieurswesen bedingt; jedem professionellen Autor wird es bei derartigen Vergleichen die Zehennägel aufrollen.

Ich finde nicht, dass eine solche Unterscheidung (Realisierung und Design) hier Sinn macht. Kodieren, als konkrete Tätigkeit der Realisierung, ist mitnichten eine rein handwerkliche Tätigkeit. Reale Softwareprobleme entziehen sich dem einfachen Bild von Planung mit anschließender Kodierung meist recht geschickt. Die beste Form der Kodierung beschreibt deklarativ das Problem selbst; ob eine solche Form möglich ist hängt sicherlich von den verwendeten Werkzeugen, aber mehr noch vom Geschick des Entwicklers ab. Insofern: Ja es gibt eine ganze Reihe handwerklicher Fähigkeiten. Von einem Autor erwartet man auch, dass er Rechtschreibung, Grammatik und einige simple Grundregeln der Stilistik beherrscht; es gehört allerdings mehr dazu, wirklich gut zu schreiben.Sie stellten auch fest, dass gerade die Schönheit im Design, die ästhetisch/logisch optimale Lösung nach ihrer Erfahrung unflexibel, unzuverlässig und schlecht verständlich sind. Kommentare würden zwar manchmal aushelfen, aber nur bedingt. Für mich bedeutet "schöner, ästhetisch gelungener Code", dass er (am besten auch ohne Kommentare) das Problem auf einfachste und ideale Weise beschreibt. Schlecht verständlicher, unflexibler Quellcode ist niemals ästethisch und niemals gut.