Moin,
also es ist spannend, das hier zu lesen. Ich muss gestehen, ich muss für mich erstmal übersetzen, was Tim meint.
das trifft es ganz gut. :-)
[Macros]
In C sind sie durchaus üblich.
Sind die noch aus (Makro-)Assembler übrig geblieben, oder hat man da das Rad neu erfunden?
Keine Ahnung, wie die Evolution da abgelaufen ist, aber in C gelten sie als fester Bestandteil der Sprache, auch wenn der Macro-Präprozessor mitunter ein eigenständiges Programm ist, das auch als eigenständiger Schritt bei der Übersetzung abläuft (meistens ist das aber schon im Compiler integriert).
Auch bin ich zunehmend skeptischer gegenüber mehreren Ausstiegspunkten aus einer Funktion.
Ich nicht, im Gegenteil: Sobald das Ergebnis einer Funktion feststeht, beende ich sie. Ich finde das übersichtlicher, als "pro forma" das schon feststehende Ergebnis bis zum Ende der Funktion durchzureichen.
Das geht aber nur sicher in Sprachen, die selber für das Aufräumen sorgen und keine lost handles oder vagabundierenden Speicher zurücklassen, wenn man den Gültigkeitsbereich der Funktion verlässt.
Nicht nur, auch wenn es da natürlich am einfachsten ist.
Aber ich hatte es als selbstverständlich vorausgesetzt, dass der Programmierer entweder ganz raffiniert ist und diese "Aufräumarbeiten" (Speicher freigeben, hergestellte Verbindungen trennen etc.) in der aufrufenden Ebene macht (das ist manchmal vorteilhaft, aber im Sinne der Kapselung und Modularität nicht unbedingt der Brüller), oder zumindest sich um diese Dinge explizit kümmert - und sei es, dass er im konkreten Fall feststellt, dass nichts weiter notwendig ist.
Meiner Ansicht nach erreicht man das am besten, indem man versucht, den natürlichen Gedankengang so gut wie möglich mit den Strukturen der jeweiligen Programmiersprache abzubilden. Das ist allerdings keine Einbahnstraße: Intensive Beschäftigung mit einer bestimmten Programmiermethode führt dazu, dass man selbst anfängt, so zu denken, und das als "normal und intuitiv" empfindet.
Für mich ist es immer wichtiger, ob auch ANDERE, die die Sprache "nur lesen" können, auch verstehen können, was derjenige erreichen wollte.
Hmm. Was meinst du mit "nur lesen"? Möchtest du Programmcode wirklich so schreiben, dass ein Laie ihn nachvollziehen kann? Das halte ich für übertrieben. Ich setze schon veraus, dass derjenige, der den Code später liest, auch vom Fach ist.
Denn ob das Wollen mit dem Tun übreinstimmt, ist ja auch nicht immer selbstverständlich und steht selten dabei :-P
Wie wahr ...
Schönes Wochenende,
Martin
Drei Sachen vergesse ich immer wieder: Telefonnummern, Geburtstage und ... äääh ...
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(