Diskussion:Strukturierte Programmierung
Erweiterung
BearbeitenDiese Zusammenstellung von Hinweisen gefällt mir. In vielen Lehrbüchern werden immer wieder dieselben Ratschläge benötigt -- hier sind sie als Sammlung zu finden. Ich glaube, ich werde auch etwas beitragen. -- Jürgen 09:28, 5. Jan. 2012 (CET)
- Die Unterstützung würde mich sehr freuen! --Bautsch 01:55, 6. Jan. 2012 (CET)
Auch die folgenden Themen könnten besprochen werden.
- Untergliederung
- Das Buch bekommt inzwischen so viele Einzelthemen, dass eine Gliederung in Bereiche (und damit in eigenständige Kapitel) sinnvoll wäre. Ich habe mir darüber noch keine genaueren Gedanken gemacht. -- Jürgen 09:28, 5. Jan. 2012 (CET)
- Diese Idee ist mir auch schon gekommen, aber ich habe mir auch noch keine weiteren Gedanken gemacht. --Bautsch 01:55, 6. Jan. 2012 (CET)
- Diese Anleitung nimmt immer mehr Inhalt an (und sobald andere Programmierer es sehen, dürfte noch mehr dazu kommen). Ich empfehle deshalb die Aufteilung in einzelne Kapitel (Seiten); als Hauptthemen geht mir so etwas durch den Kopf (noch nicht als Formulierungen der Kapitel):
- Gestaltung von Quelltexten
- Konstante, Variable, Bezeichner, Deklaration
- Zusammenarbeit zwischen Quelldateien/Modulen/DLLs usw.
- Steuerung des Arbeitsablaufs
- alles, was zur OOP relevant ist
- Ich bin mir noch unsicher, ob alle bisherigen Stichpunkte auf diese Weise sinnvoll untergebracht werden. Aber vielleicht kommen wir auf diese Weise zu einer Struktur – denn um Struktur geht es hier schließlich. -- Jürgen 13:32, 6. Jan. 2012 (CET)
- Diese Anleitung nimmt immer mehr Inhalt an (und sobald andere Programmierer es sehen, dürfte noch mehr dazu kommen). Ich empfehle deshalb die Aufteilung in einzelne Kapitel (Seiten); als Hauptthemen geht mir so etwas durch den Kopf (noch nicht als Formulierungen der Kapitel):
- Diese Idee ist mir auch schon gekommen, aber ich habe mir auch noch keine weiteren Gedanken gemacht. --Bautsch 01:55, 6. Jan. 2012 (CET)
- Einrückungen und Zeilenumbruch
- Du hast den Code automatisch eingerückt. Das sollte in einem eigenen Punkt erläutert werden. Ein Zeichen ist dafür entschieden zuwenig; man sollte mindestens zwei Zeichen verwenden. Bitte setze aber keine absoluten Regeln fest. Beispielsweise kann man bei diesen Konventionen unterschiedlicher Meinung sind. Wichtig sind klare Festlegungen innerhalb eines Programms, damit die Struktur auch für neue Leser erkennbar bleibt. (Das hilft auch dem Autor eines Codes, wenn er nach zwei Wochen, Monaten oder Jahren etwas überarbeiten muss.) -- Jürgen 09:28, 5. Jan. 2012 (CET)
- Ich bevorzuge den Tabulator - mehrfache Leerzeichen stammen aus der Zeit der ersten Texteditoren-, aber ich vermute und befürchte, dass dies in der Wiki-Software zur Zeit noch nicht unterstützt wird. Für die Compiler spielt dies keine Rolle, aber dafür umso mehr für die Menschen, die davor sitzen ;-) --Bautsch 01:55, 6. Jan. 2012 (CET)
- Ich bevorzuge eigentlich ebenfalls Tabs, zumal in der IDE die Tab-Größe in der Regel eingestellt werden kann. Aber beim Kopieren z.B. über Foren geht der eigene Standard verloren; dann sind Leerzeichen besser, weil kompatibler. Mir ist vor allem aufgefallen, dass deine Code-Beispiele nur um ein Zeichen eingerückt sind. Es mag sein, dass das bei dir ein Tab war, und beim Herüberkopieren wurde das zu einem einsamen Leerzeichen. qed -- Jürgen 13:32, 6. Jan. 2012 (CET)
- Ich bevorzuge den Tabulator - mehrfache Leerzeichen stammen aus der Zeit der ersten Texteditoren-, aber ich vermute und befürchte, dass dies in der Wiki-Software zur Zeit noch nicht unterstützt wird. Für die Compiler spielt dies keine Rolle, aber dafür umso mehr für die Menschen, die davor sitzen ;-) --Bautsch 01:55, 6. Jan. 2012 (CET)
- Deutsch oder Englisch
- Ich empfehle, für Bezeichner generell englische Begriffe zu wählen, auch wenn ich die Verwendung der deutschen Sprache im deutschen Sprachraum entschieden bevorzuge. Zur Erläuterung meines Standpunkts (mit Beispielen) siehe .NET-Namenskonventionen. -- Jürgen 09:28, 5. Jan. 2012 (CET)
- Damit habe ich keine Probleme, zumal ich sowieso vor hatte, das Wikibook ins Englische zu übertragen. --Bautsch 01:55, 6. Jan. 2012 (CET)
Es ist erstaunlich, was einem bei Verbessern noch so alles einfällt. Ich habe einiges vom Diskutierten bereits umgesetzt und bin mir aber bewusst, dass dies alles noch nicht fertig und noch nicht der Weisheit letzter Schluss ist. Die sinnvolle Strukturierung von Artikeln ist mindestens so herausfordernd, wie diejenige von Programmen ;-) --Bautsch 12:49, 7. Jan. 2012 (CET)
Kein Missbrauch bei Imports
BearbeitenIch möchte widersprechen: Es ist kein Missbrauch, wenn using bzw. imports zur Verkürzung des Quellcodes genutzt wird. Gerade bei .NET mit den langen, mehrstufigen Namespace-Bezeichnern macht die ständige Wiederholung des vollständigen Bezeichners den Code sehr unübersichtlich. Der folgende Quelltext (aus der .NET-Doku kopiert) ist doch überhaupt nicht mehr lesbar, und es gibt Namespaces mit noch viel längeren Namen:
public void InsertRow(string connectionString)
{
string queryString = "INSERT INTO Dept (DeptNo, Dname, Loc) values (50, 'TECHNOLOGY', 'DENVER')";
using (System.Data.OracleClient.OracleConnection connection
= new System.Data.OracleClient.OracleConnection(connectionString))
{
System.Data.OracleClient.OracleCommand command = new System.Data.OracleClient.OracleCommand(queryString);
// do anything
}
}
Man muss also in der Praxis abwägen. Bei "einfachen" Bezeichnern wie MyModule passt der Ratschlag, aber es gibt eben auch andere Situationen. -- Jürgen 09:28, 5. Jan. 2012 (CET)
- Ich finde diesen Code gerade noch lesbar, verstehe das Argument aber sehr gut; insbesondere wenn auf engem Raum sehr viele Bezeichner aus einer fernen Bibliothek benutzt werden, kann das schnell albern und unübersichtlich aussehen. Bei einmaligem Auftreten finde ich das Ausschreiben im Allgemeinen schon recht hilfreich.
- Im engeren Sinne meinte ich aber besonders die Imports mit Wildcards, so wie zum Beispiel:
import myPackage.*; import yourPackage.*; drawLine (); Class var = new Class (); /* To which package does Class belong ? */
und ähnliche Fälle. Ich werde das demnächst einmal genauer und etwas umfangreicher formulieren. --Bautsch 01:55, 6. Jan. 2012 (CET)
For-Schleifen
BearbeitenMit dem was unter "For-Schleifen" steht, bin ich nicht ganz einverstanden bzw. erkenne nicht so ganz die Relevanz. Praktisch jede Programmiersprache, die die dortige Syntax kennt (z.B. C ab C99, C++, Java, C#, D), erlaubt auch ...
for(int i = 0; i < max; i++) { ... }
... mit dem entscheidenen Vorteil, dass i "so lokal wie möglich ist" (siehe weiter oben unter "Prinzip der Lokalität"), nämlich nur innerhalb des Schleifen-Blocks. Wenn wirklich nur stumpf gezählt wird und die Zähl-Variable danach nicht mehr benötigt wird, sollte immer die For-Schleife den Vorzug bekommen. Zudem würd ich die for-Schleifen noch zum "einfachen Sprachumfang" zählen, da immer sehr einfach und praktisch immer (in der obigen Form) identisch implementiert. Wenn man sich dagegen mal die Regeln für switch/case-Anweisungen vermeintlich ähnlicher Sprachen anguckt ... --92.196.53.40 21:51, 26. Mär. 2012 (CEST)
- Zustimmung zu deinen Bedenken. Es sind wohl die Randbedingungen zu beachten: Sofern dasselbe i vorher oder nachher benutzt wird, kann for durch eine der anderen Schleifen ersetzt werden. Du darfst Text und Gliederung gerne überarbeiten. -- Jürgen 09:04, 27. Mär. 2012 (CEST)
- Ich würd es eigentlich nur löschen wollen (was ich aber nicht tun werde). Die genannten Argumente überzeugen mich nicht und "... unter Umständen [welchen?] ... auschließlich ..." spricht auch nicht für eine eindeutigen Standpunkt des Autors. Wenn eine Sprache einen Zählschleifenkonstrukt mitbringt, sollte man es auch nutzen dürfen, denn es macht dem Quellcode-Leser deutlich, dass da nur gezählt wird (möglichst fixe Anzahl und Schrittweite) und nicht auf die Nichterfüllung einer while-Bedingung gewartet wird. --92.196.30.97 21:20, 27. Mär. 2012 (CEST)
- Ich bedanke mich für den wichtigen und richtigen Hinweis zur Lokalität und die Nichtlöschung des Abschnittes. Die Information habe ich mit einer weiteren Ergänzung in das Wikibook eingebaut. --Bautsch 08:39, 30. Mär. 2012 (CEST)
Standard-Vorsilben und Bezeichner
BearbeitenBei der Schreibweise von Bezeichnern und Methoden könnte man noch anfügen, dass bestimmte Standard-Vorsilben allgemein üblich sind. setFoo getFoo und andere wie isFoo myFoo delFoo copyFoo recht gebräuchlich. Der Bezug zum Objekt bleibt dadurch gewahrt. Ebenso kann man die Joker (Metasyntaktische Variablen) Foo, Bar, Bas, für den Quellcode erläutern. (z.B. am Beispiel von Parameterlisten). Weiterhin sollten gängige Zählvariablen erläutert werden. Das i und j meist für Iterationen gebraucht werden. --mjchael 13:57, 30. Mär. 2012 (CEST)
- my, del und copy ist mir noch nie untergekommen. Das dürfte auch zu sprachspezifisch werden (ist es teileweise schon jetzt, finde ich). Ab irgendeinem Punkt kann man nur noch auf die Styleguides der einzelnen Sprachen verweisen. --92.196.71.109 17:07, 31. Mär. 2012 (CEST)
Leerräume
Bearbeiten"Leerräume, also zum Beispiel Leerzeichen, Zeilen- und Seitenumbrüche oder Tabulatoren, werden - genauso wie Kommentare - vom Compiler überlesen und dienen daher ausschließlich zur Verbesserung der Lesbarkeit für die Programmierer." Stimmt das wirklich immer? Zumindest für bestimmte Scriptsprachen trifft es nicht zu. In Python z.B. ist korrekte Einrückung absolut notwendig (siehe w:Python (Programmiersprache)#Strukturierung durch Einrücken). Ich würde hier zumindest einen entsprechenden Hinweis anbringen, dass es durchaus Ausnahmen geben kann. --Versat 09:36, 4. Dez. 2015 (CET)
- Zustimmung zu deinem Hinweis; bei Basic (vermutlich bei allen Dialekten) ist das Zeilenende (also ein einfacher Zeilenumbruch) die Markierung für den Abschluss einer Anweisung. Also ändere es passend. -- Jürgen 10:03, 4. Dez. 2015 (CET)
- Danke für die Hinweise ! Ich stimme auch zu, denn auch bei FORTRAN mussten am Zeilenanfang bestimmte Einrückungen eingehalten werden, damit die Lochkarten korrekt gestanzt werden konnten. Ich hatte das verdrängt, und habe den Text jetzt entsprechend geändert. --Bautsch 16:19, 5. Dez. 2015 (CET)
Beispiele Überladung des Divisionsoperators
BearbeitenHuhu, eine Frage wegen den Beispielen in diesem Abschnitt, laut Kommentar sind dort zwei Beispiele für Pascal, ist das nicht eher C, weil die Zuordnung der Werte in Pascal mit := erfolgen, oder? -- Zase Wieder 10:23, 28. Nov. 2023 (CET)
- Ich schätze es handelt sich hier lediglich um einen Flüchtigkeitsfehler. Kommentare und Syntaxhighlight sprechen für das Ziel Pascal. Könnte ja auch sein, dass es Zuweisungen aus dem Programmbeginn sein sollen. Nach der Projektbeschreibung (offensichtlicher Fehler) hab ich mal Doppelpunkte ergänzt. Für den Fall der Fälle: Ping@Bautsch. Viele Grüße, HirnSpukDisk – 15:39, 28. Nov. 2023 (CET)
- Ich danke Euch beiden, und habe mir auch noch erlaubt, "div" mit kleinen Buchstaben zu schreiben... :-) --Bautsch 16:50, 28. Nov. 2023 (CET)
- ich danke auch, nur noch eine Kleinigkeit: die Zuweisungart des Typs ist mir nicht so bekannt, ist es nicht umgekehrt xxx: integer; statt int xxx;und erfolgt diese Typenanweisung nicht „außerhalb“ in der Präambel. Auch scheinen leider unter der Literatur Ihre/Deine Beiträge nicht mehr bei ENISA aufrufbar zu sein, gibt es Alternativen (crises verbessert google zu crisis, ist letzteres gemeint?). Danke im Voraus und danke für die ganzen Kapitel hier auf de.wikibooks.org :). --grüße Zase Wieder 20:45, 12. Dez. 2023 (CET)
- Ich danke Euch beiden, und habe mir auch noch erlaubt, "div" mit kleinen Buchstaben zu schreiben... :-) --Bautsch 16:50, 28. Nov. 2023 (CET)