Programmierstil, Fallenstricke

Übersicht

BlitzBasic

FAQ und Tutorials

	OJay Betreff: Programmierstil, Fallenstricke	Fr, Feb 13, 2004 19:21 Antworten mit Zitat
Programmierstil und Fallenstricke Mal ein etwas anderes Tutorial Ich habe es nicht komplett selbst geschrieben, als vielmehr alles was ich zu dem Thema finden konnte zusammengestellt und in einen klaren Context gebracht. Ich hoffe es hilft dem einen oder anderen Team, Code zu produzieren, welchen auch andere Menschen leicht lesen und verstehen und damit arbeiten können. Allgemeines Benutze ausschließlich Großbuchstaben für Konstanten und gemischte Schreibweise oder das Unterstreichungszeichen ( _ ) für Variable und Funktionsnamen. Namen wie GetData oder get_data sind leichter zu lesen als kleingeschriebene Namen ohne Unterstreichungszeichen (wie getdata). Benutze Funktionen, um deine Programme kurz und modular zu halten. Funktionen verkürzen das Hauptprogramm und machen dadurch den Gesamtablauf klarer. Ein Funktionsname sollte, wie alle anderen Namen auch, den Zweck erkennen lassen. Funktionen sollten verhältnismäßig kurz (50 bis 200 Zeilen) sein und großzügig kommentiert werden. BB führt zwar eine Fehlerprüfung durch, es wird jedoch unterstellt, daß Programmierer wissen, was sie tun. Es liegt in der Verantwortung des Programmierers, Arraygrenzen und Parametertypen zu überprüfen. Einige wenige sorgfältige Prüfungen können lange Testzeiten ersparen. Über das Schreiben von Ausdrücken Wegen der großen Zahl von Operatoren, des nicht immer einleuchtenden Vorrangs und der Regeln der automatischen Typangleichung liegt es in der Verantwortung des Programmierers sicherzustellen, daß ein Ausdruck in der erwarteten Art und Weise arbeitet. Es folgen hier einige Anregungen, die es dir erleichtern sollen, leicht lesbare, effiziente (und fehlerfreie) Programme zu schreiben. Einige der Vorrangregeln sind nicht einleuchtend. Falls du unsicher bist, benutze Klammern, um die Reihenfolge und Priorität der Bewertung anzugeben. Denke jedoch daran, daß der Compiler die Bewertungsreihenfolge bestimmter Ausdrücke (solche, die nur die Operatoren /, ^, + oder * enthalten), selbst bei Anwesenheit von Klammern, frei wählen kann. Es gibt keine Leistungseinbuße durch die Bewertung von Konstantenausdrücken, da sie zur Compilationszeit bewertet werden. Zum Beispiel wandelt der Compiler den Ausdruck Code: [AUSKLAPPEN] [EINKLAPPEN] a = 17.3 / 14.7 * PI / vals(i) (vorausgesetzt, PI ist als 3.14159 definiert worden) in Code: [AUSKLAPPEN] [EINKLAPPEN] a = 3.697245371 / vals(i) um. Es ist leicht, unklare Ausdrücke zu schreiben. Selbst wenn diese Ausdrücke vom Compiler eindeutig interpretiert werden können, werden sie doch die meisten Programmierer verwirren. Wenn du nicht sicher bist, vereinfache es. Programmformat Obwohl die äußere Erscheinung des Quelltextes keine Rolle spielt, hat das Programmformat erheblichen Einfluß auf seine Verständlichkeit. Das Layout von Quellcode ist nicht nur eine Frage des persönlichen Geschmacks oder des Programmierstils. Ein vereinheitlichtes Code-Layout in einem Softwareprojekt ist eine wichtige Maßnahme zur besseren Interaktion von Teammitgliedern. Kommentare, die sich über mindestens eine Zeile erstrecken, sind linksbündig am Code ausgerichtet. Sie sollten beschreiben, was in den folgenden Programmzeilen bis zur nächsten Leerzeile geschieht. Ist ein Programmblock länger als 20 - 30 Zeilen, sollte ein Kommentar am Blockende auf den Blockanfang verweisen (z. B. ;Ende: while (x > 0) ...) Funktionsbeschreibungen enthalten alle Parameter, Fehlerfälle und Rückgabewert. Ggf.muss auch angegeben werden, ob ein Parameter Eingabewert, Ausgabewert oder beides ist. Die Beschreibung erfolgt direkt nach der Definition des Funktionskopfes noch vor den Block der Funktion. Formatiere die Anweisungen durch Einrücken so, daß man die Anweisungs- und Blockstruktur erkennen kann. Achte auf Lesbarkeit. Klammern oder Schlüsselworte zur Blockdefinition sollten in einer separaten Zeile stehen. Programmblöcke müssen durch Einrückung erkennbar (Tabulatorzeichen) und linksbündig ausgerichtet sein. Beispiel: Code: [AUSKLAPPEN] [EINKLAPPEN] if (wert > 10) ;tu was else ;tu was anderes endif Code im globalen Kontext (z. B. die Definition einer Funktion) darf nicht eingerückt sein. Eine Sprungmarke (Label) sollte eine einfache negative Einrückung zum vorhergehenden Code aufweisen. Trenne Vereinbarungen und Anweisungen durch eine Leerzeile, auch wenn das nicht vom Compiler gefordert wird. Scheue dich nicht, weitere Leerzeilen einzufügen. Funktionen sollten vom vorhergehenden Code durch 2 - 3 Leerzeilen getrennt werden. Einzelne zusammengehörende Codezeilen können durch eine Leerzeile vom vorhergehenden Code getrennt werden. Die maximale Zeilenbreite des Quellcodes sollte maximal 70 - 75 Anschläge umfassen. Vermeide es, den Anweisungsteil einer Schleifen- oder Entscheidungsanweisung in dieselbe Zeile zu schreiben wie den Schleifensteuerungsausdruck. Die zwar kürzere Form ist schlechter lesbar und anfälliger gegen Fehler wie das irrtümliche Einfügen einer leeren Anweisung. Schließlich, unterliege nicht der Versuchung vieler Programmierer, herauszufinden, wie man ein Programm in der knappsten möglichen Form schreiben kann. Wenn du unbedingt das Bedürfnis hast, tu es, aber werfe das Programm anschließend weg, denn es ist nicht mehr lesbar - oder nimm am Obfuscated C Contest teil. Über das Schreiben leicht lesbarer Programme Wir haben wenig Zeit darauf verwandt, Kriterien dafür zu finden, was eine gute Funktion ausmacht. Hier folgen einige Merkmale, die eine gut geschriebene Funktion besitzen sollte: Zusammenhalt: Eine Funktion sollte nur eine Aufgabe ausführen und alle Anweisungen in der Funktion sollten auf diese Aufgabe bezogen sein. Wenn die Wirkungsweise der Funktion nicht in einem einzigen Satz beschrieben werden kann, versucht die Funktion, zu viel zu tun. Allgemeingültigkeit: Eine Funktion sollte ihre eine Aufgabe gut erfüllen. Eine Sortierroutine sollte z.B. für alle Eingabemengen gut arbeiten und Fehlerfälle (wie wenn keine zu sortierenden Elemente vorhanden sind) angemessen behandeln. Einfachheit: Eine Funktion sollte ihre Aufgabe auf die einfachst mögliche Weise erledigen; versuche nicht, durch übertriebenes Ausfeilen des Codes noch ein oder zwei Operationen einzusparen. Im allgemeinen wird ein Wechsel des Algorithmus mehr zur Effizienz beitragen als irgendwelche Manipulationen am Code. Kürze: Funktionen, die eine einzelne Aufgabe in einfacher Weise erledigen, sind im allgemeinen nicht lang. Es bewährt sich, Funktionen auf ca. 25 bis 200 Zeilen zu beschränken. Natürlich können auch zu viele kleine Funktionen ein Programm zu sehr zerreißen und damit die Lesbarkeit und die Effizienz des Programms ruinieren. Die meisten Programmierer schreiben jedoch eher zu lange als zu kurze Funktionen. Dokumentation: Jede Funktion hat Anspruch auf einen Kommentar, der ihm Aufgabe beschreibt. Die Parameter und lokalen Variablen der Funktion sollten ebenfalls kommentiert werden. Häufig genügt ein einziger Satz zur Beschreibung der Funktion oder Variablen. Schreibe die Kommentare immer gleichzeitig mit dem Code, und warte nicht, bis die Funktion fertig geschrieben ist. Häufige Fallen Float-Ausdrücke: Code: [AUSKLAPPEN] [EINKLAPPEN] d# = 3/4 Hier wird zunächst 3 durch 4 geteilt - was für Integerwerte natürlich 0 ist. Dann wird dieses Ergebnis d# zugewiesen als 0.000000 (über eine implizite Typumwandlung) und bleibt somit natürlich 0. Abhilfe schafft die Verwendung der richtigen Konstanten 3.0 und 4.0 als floats (zumindest eine): Code: [AUSKLAPPEN] [EINKLAPPEN] d# = 3.0/4.0 Konstante und Variable: Bei const a und local b ist b=a ok (Verarbeitung nur einer Kopie), a=b ist dagegen falsch (Unerlaubte Änderung) Bei Fragen bitte einfach posten. Für Vorschläge zur Erweiterung und Verbesserung bin ich jederzeit offen Hf

OJay

Betreff: Programmierstil, Fallenstricke

Fr, Feb 13, 2004 19:21
Antworten mit Zitat

Programmierstil und Fallenstricke

Mal ein etwas anderes Tutorial Smile

Ich habe es nicht komplett selbst geschrieben, als vielmehr alles was ich zu dem Thema finden konnte zusammengestellt und in einen klaren Context gebracht. Ich hoffe es hilft dem einen oder anderen Team, Code zu produzieren, welchen auch andere Menschen leicht lesen und verstehen und damit arbeiten können.

Allgemeines
Benutze ausschließlich Großbuchstaben für Konstanten und gemischte Schreibweise oder das Unterstreichungszeichen ( _ ) für Variable und Funktionsnamen. Namen wie GetData oder get_data sind leichter zu lesen als kleingeschriebene Namen ohne Unterstreichungszeichen (wie getdata).

Benutze Funktionen, um deine Programme kurz und modular zu halten. Funktionen verkürzen das Hauptprogramm und machen dadurch den Gesamtablauf klarer. Ein Funktionsname sollte, wie alle anderen Namen auch, den Zweck erkennen lassen. Funktionen sollten verhältnismäßig kurz (50 bis 200 Zeilen) sein und großzügig kommentiert werden.

BB führt zwar eine Fehlerprüfung durch, es wird jedoch unterstellt, daß Programmierer wissen, was sie tun. Es liegt in der Verantwortung des Programmierers, Arraygrenzen und Parametertypen zu überprüfen. Einige wenige sorgfältige Prüfungen können lange Testzeiten ersparen.

Über das Schreiben von Ausdrücken
Wegen der großen Zahl von Operatoren, des nicht immer einleuchtenden Vorrangs und der Regeln der automatischen Typangleichung liegt es in der Verantwortung des Programmierers sicherzustellen, daß ein Ausdruck in der erwarteten Art und Weise arbeitet. Es folgen hier einige Anregungen, die es dir erleichtern sollen, leicht lesbare, effiziente (und fehlerfreie) Programme zu schreiben.

Einige der Vorrangregeln sind nicht einleuchtend. Falls du unsicher bist, benutze Klammern, um die Reihenfolge und Priorität der Bewertung anzugeben. Denke jedoch daran, daß der Compiler die Bewertungsreihenfolge bestimmter Ausdrücke (solche, die nur die Operatoren /, ^, + oder * enthalten), selbst bei Anwesenheit von Klammern, frei wählen kann.

Es gibt keine Leistungseinbuße durch die Bewertung von Konstantenausdrücken, da sie zur Compilationszeit bewertet werden. Zum Beispiel wandelt der Compiler den Ausdruck Code: [AUSKLAPPEN]

a = 17.3 / 14.7 * PI / vals(i)

(vorausgesetzt, PI ist als 3.14159 definiert worden) in Code: [AUSKLAPPEN]

a = 3.697245371 / vals(i)

um.
Es ist leicht, unklare Ausdrücke zu schreiben. Selbst wenn diese Ausdrücke vom Compiler eindeutig interpretiert werden können, werden sie doch die meisten Programmierer verwirren. Wenn du nicht sicher bist, vereinfache es.

Programmformat
Obwohl die äußere Erscheinung des Quelltextes keine Rolle spielt, hat das Programmformat erheblichen Einfluß auf seine Verständlichkeit. Das Layout von Quellcode ist nicht nur eine Frage des persönlichen Geschmacks oder des Programmierstils. Ein vereinheitlichtes Code-Layout in einem Softwareprojekt ist eine wichtige Maßnahme zur besseren Interaktion von Teammitgliedern.
Kommentare, die sich über mindestens eine Zeile erstrecken, sind linksbündig am Code ausgerichtet. Sie sollten beschreiben, was in den folgenden Programmzeilen bis zur nächsten Leerzeile geschieht.
Ist ein Programmblock länger als 20 - 30 Zeilen, sollte ein Kommentar am Blockende auf den Blockanfang verweisen (z. B. ;Ende: while (x > 0) ...) Funktionsbeschreibungen enthalten alle Parameter, Fehlerfälle und Rückgabewert. Ggf.muss auch angegeben werden, ob ein Parameter Eingabewert, Ausgabewert oder beides ist. Die Beschreibung erfolgt direkt nach der Definition des Funktionskopfes noch vor den Block der Funktion.
Formatiere die Anweisungen durch Einrücken so, daß man die Anweisungs- und Blockstruktur erkennen kann. Achte auf Lesbarkeit. Klammern oder Schlüsselworte zur Blockdefinition sollten in einer separaten Zeile stehen. Programmblöcke müssen durch Einrückung erkennbar (Tabulatorzeichen) und linksbündig ausgerichtet sein. Beispiel:
Code: [AUSKLAPPEN]

if (wert > 10)
;tu was
else
;tu was anderes
endif

Code im globalen Kontext (z. B. die Definition einer Funktion) darf nicht eingerückt sein.
Eine Sprungmarke (Label) sollte eine einfache negative Einrückung zum vorhergehenden Code aufweisen.
Trenne Vereinbarungen und Anweisungen durch eine Leerzeile, auch wenn das nicht vom Compiler gefordert wird. Scheue dich nicht, weitere Leerzeilen einzufügen. Funktionen sollten vom vorhergehenden Code durch 2 - 3 Leerzeilen getrennt werden. Einzelne zusammengehörende Codezeilen können durch eine Leerzeile vom vorhergehenden Code getrennt werden.
Die maximale Zeilenbreite des Quellcodes sollte maximal 70 - 75 Anschläge umfassen.
Vermeide es, den Anweisungsteil einer Schleifen- oder Entscheidungsanweisung in dieselbe Zeile zu schreiben wie den Schleifensteuerungsausdruck. Die zwar kürzere Form ist schlechter lesbar und anfälliger gegen Fehler wie das irrtümliche Einfügen einer leeren Anweisung.
Schließlich, unterliege nicht der Versuchung vieler Programmierer, herauszufinden, wie man ein Programm in der knappsten möglichen Form schreiben kann. Wenn du unbedingt das Bedürfnis hast, tu es, aber werfe das Programm anschließend weg, denn es ist nicht mehr lesbar - oder nimm am Obfuscated C Contest teil. Smile

Über das Schreiben leicht lesbarer Programme
Wir haben wenig Zeit darauf verwandt, Kriterien dafür zu finden, was eine gute Funktion ausmacht. Hier folgen einige Merkmale, die eine gut geschriebene Funktion besitzen sollte:
Zusammenhalt:
Eine Funktion sollte nur eine Aufgabe ausführen und alle Anweisungen in der Funktion sollten auf diese Aufgabe bezogen sein. Wenn die Wirkungsweise der Funktion nicht in einem einzigen Satz beschrieben werden kann, versucht die Funktion, zu viel zu tun.
Allgemeingültigkeit:
Eine Funktion sollte ihre eine Aufgabe gut erfüllen. Eine Sortierroutine sollte z.B. für alle Eingabemengen gut arbeiten und Fehlerfälle (wie wenn keine zu sortierenden Elemente vorhanden sind) angemessen behandeln.
Einfachheit:
Eine Funktion sollte ihre Aufgabe auf die einfachst mögliche Weise erledigen; versuche nicht, durch übertriebenes Ausfeilen des Codes noch ein oder zwei Operationen einzusparen. Im allgemeinen wird ein Wechsel des Algorithmus mehr zur Effizienz beitragen als irgendwelche Manipulationen am Code.
Kürze:
Funktionen, die eine einzelne Aufgabe in einfacher Weise erledigen, sind im allgemeinen nicht lang. Es bewährt sich, Funktionen auf ca. 25 bis 200 Zeilen zu beschränken. Natürlich können auch zu viele kleine Funktionen ein Programm zu sehr zerreißen und damit die Lesbarkeit und die Effizienz des Programms ruinieren. Die meisten Programmierer schreiben jedoch eher zu lange als zu kurze Funktionen.
Dokumentation:
Jede Funktion hat Anspruch auf einen Kommentar, der ihm Aufgabe beschreibt. Die Parameter und lokalen Variablen der Funktion sollten ebenfalls kommentiert werden. Häufig genügt ein einziger Satz zur Beschreibung der Funktion oder Variablen. Schreibe die Kommentare immer gleichzeitig mit dem Code, und warte nicht, bis die Funktion fertig geschrieben ist.

Häufige Fallen
Float-Ausdrücke:
Code: [AUSKLAPPEN]

d# = 3/4

Hier wird zunächst 3 durch 4 geteilt - was für Integerwerte natürlich 0 ist. Dann wird dieses Ergebnis d# zugewiesen als 0.000000 (über eine implizite Typumwandlung) und bleibt somit natürlich 0. Abhilfe schafft die Verwendung der richtigen Konstanten 3.0 und 4.0 als floats (zumindest eine):
Code: [AUSKLAPPEN]

d# = 3.0/4.0

Konstante und Variable:
Bei const a und local b ist b=a ok (Verarbeitung nur einer Kopie), a=b ist dagegen falsch (Unerlaubte Änderung)

Bei Fragen bitte einfach posten. Für Vorschläge zur Erweiterung und Verbesserung bin ich jederzeit offen Smile