---

Hallo Forum,

ich bin auf der Suche nach "Vorschriften" bzw. dem "guten Ton" von Lisproutinen. Wie lang darf/soll

1. ein Funktionsname
2. eine Variable

maximal sein? Welche Beschränkung ist sinnvoll? Gibt es Vorgaben bezüglich der Quellcodelänge? In "Maximizing Autolisp" habe ich gelesen, daß Code, der sechs (6!) Zeilen übersteigt, nicht sehr elegant ist, mag diese Behauptung aber nicht so recht glauben...

Kann mich jemand eines Besseren belehren? Bin für jeden Tip dankbar!

Freddy

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Betreffs Stilfragen verweise ich mal auf Mapcars Ansichten , die ich weitestgehend teile.
Ansonsten : guck dir doch den Code der Leute aus dem Forum an, jeder hat gewisse Vorlieben wie sprechende (oder nur ihm was sagende) Namen .. ausgefeilte Funktionsheader usw.

P.S: nur 6 Zeile halte ich für etwas übertrieben. Nix gegen Modularisierung, eine Funktion für einen Zweck, aber bei mir sinds auch mal 20 

------------------
Holger Brischke
CAD on demand GmbH
Individuelle Lösungen von Heute auf Morgen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Paulchen:
Hallo Forum,

ich bin auf der Suche nach "Vorschriften" bzw. dem "guten Ton" von Lisproutinen. Wie lang darf/soll

1. ein Funktionsname
2. eine Variable

maximal sein? Welche Beschränkung ist sinnvoll? Gibt es Vorgaben bezüglich der Quellcodelänge? In "Maximizing Autolisp" habe ich gelesen, daß Code, der sechs (6!) Zeilen übersteigt, nicht sehr elegant ist, mag diese Behauptung aber nicht so recht glauben...

Kann mich jemand eines Besseren belehren? Bin für jeden Tip dankbar!

Freddy

---

Ja, da stimme ich uneingeschränkt zu: ich habe noch keine elegante LISP-Funktion gesehen, die länger gewesen ist. Und ich habe schon viele gesehen :-)

Natürlich hat Brischke auch recht, aber er hat damit auf eine gar nicht gestellte Frage geantwortet: natürlich habe ich in meinen Apps auch jede Menge Funktionen, die länger als 6 Zeilen sind. Aber diese Funktionen sind dann aber auch nicht besonders elegant :-)

Tom Berger

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Eine feste Maximalzahl für Zeilen, Zeichen, Argumente usw. kann man nicht festlegen, das wäre hirnloses Schemadenken. Aber es gibt ein paar Regeln die man beherzigen sollte:

Eine Funktion sollte immer nur eine einzige Aufgabe erfüllen: Entweder fragt die Funktion nach Radius und MP eines Kreises, oder sie bekommt diese beiden Werte als Argumente und zeichnet den Kreis. Das Problem 'Kreis zeichnen' wird damit in 'Eingabe' und 'Ausführung' aufgespalten, und beide Teile sind daher wiederverwendbar. Ein Funktion, die beides auf einmal erledigt, nämlich Benutzerabfrage UND Ausführung, ist so speziell, dass man sie aller Wahrscheinlichkeit nach niemals für etwas anderes in einem anderen Programm verwenden kann.

Die Kreis-Aufgabe ist trivial, aber man muss ja nicht viel weiter ausholen: Eine Funktion, die irgendwelche Benutzereingaben zu Polylinien mit Bögen durchführt. Die selbe Funktion berechnet irgendwelche 'bulges' mit Tangens-halbe usw. Da haben wir schon den Salat: Beim nächsten Mal muss man sich wieder den Kopf zerbrechen. Hält man sich an die Regel "Eine Funktion - eine Aufgabe", dann macht man sich das Leben leichter. Beim nächsten Programm ist der Input-Dialog ein anderer, aber die bulge-Berechnungen hat man schon im Sack, man kann sie wiederverwenden.

Der grundsätzliche Aufbau eines Programms ist in der Regel ein sogenannter "Three-Tier", d.h. das Programm wird von vornherein in die drei Teile 'Eingabe - Verarbeitung - Ausgabe' zerlegt, wobei in CAD-Programmen die Ausgabe meistens grafischer Natur ist. Es gibt auch Two-Tier, das sind aber in der Regel Treiber- oder Konvertierungsprogramme (kein Verarbeitungs-Teil), und auf Four-Tier will ich hier gar nicht eingehen (->Google).

Daraus ergibt sich, dass jedes Programm (wenn's nicht um ein kleines Button-Makro geht) aus mindestens drei Funktionen bestehen sollte. Jeder der drei Tiers sollte dann aber noch soweit in Funktionen zerlegt werden, wie es irgendwie geht. Wenn es absehbar ist, dass man mehrmals pi/4 benötigt, sollte man eine Konstante erzeugen. Es gibt in Lisp aber keine Konstanten, also wird's eine Variable. Damit klar wird, dass eigentlich eine Konstante gemeint ist, sollte man den Namen in Großbuchstaben schreiben.

Dann wird wirklich JEDE Aufgabe in einer eigenen Funktion untergebracht. 6 Zeilen sind schon eine gute Richtschnur, aber bei komplizierten Anwendungen kann es durchaus mehr sein. Wenn ein Flansch gezeichnet werden soll, stehen z.B. einige Parameter in den entspr. DIN/EN-Tabellen. Wenn das dreißig sind, hat man eben eine Eingabe-Funktion, die 30 Parameter abfragt, und eine Ausgabe-Funktion, die 30 Argumente kriegt. Fast jede weitere Unterteilung wäre 'künstlich' und wenig nutzbringend - es sei denn, man legt die Sache so an, dass die Blindflansche gleich mit erschlagen werden. Sinnvoll ist da wohl nur, wenn man eine Funktion 'Bohrung' auslagert, denn Bohrungen kann man auch woanders gebrauchen.

Was die Namensgebung angeht, sollte man der Klarheit den Vorzug geben. "drawCircle" ist nach ein paar Monaten einfach besser zu lesen als "dc". Die Zeiten. als noch empfohlen wurde, Variablennamen in Lisp auf 6 Zeichen zu beschränken, sind seit 20 Jahren vorbei! Man kann in Autolisp auch das Komma oder die linke geschweifte Klammer als Variablennamen verwenden, aber mal ehrlich - tut man sich damit einen Gefallen? Gegen Variablennamen wie PI/4 oder durchmesser[2] spricht aber absolut nichts. Das wichtigste ist die Konsistenz: "makeGreen" und "make_yellow" bedeutet immer unbezahlte Überstunden. Leider ist Autolisp alles andere als ein gutes Vorbild, wenn es um Konsistenz geht.

Schöne Grüße, Justus   

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vielen Dank an alle! Scheinbar habe ich einen kleineren Diskussionsbedarf geweckt...

Entschuldigend muß ich gestehen, daß ich aus der "Nicht-Programmierer-sondern-Ingenieur-der-bißchen-mit-Lisp-rumspielt"-Ecke (so ähnlich laut mapcar ) komme. Ich möchte vermeiden, daß ich bereits am Anfang grobe Fehler mache. Eine gewisse Eleganz will ich mir schon selbst abverlangen, zumal man sich später viel Ärger und Arbeit erspart, vom "Spott" der wirklichen Lispler mal ganz abgesehen!

@Holger: Danke für den Link, hätte auch selbst draufkommen können...

@Tom: Schön, eine Bestätigung zu bekommen!

@Justus: Wow. Tolle Sache. Du beantwortest, ohne es zu wissen, einen Teil meiner nächsten Frage:

Nach meinem jetztigen Verständnis wird alles in sinnvolle Häppchen zerlegt, die beliebig verwendbar sind und ohne Umbau (nahezu) überall laufen. Kennt man sich denn da noch aus? Ich habe gerade einen Ordner mit 200-300 *.lsp-Dateien vor Augen. Was tut ihr? Alle einzeln laden oder in die Acad####doc.lsp oder...

Ich frage wohl Sachen, die für euch selbstverständlich sind. Für solche Tips ist aber dieses Forum doch da, oder?!

Mit der Bitte um Nachsicht

Freddy

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

..man muß nicht jede einzelne Lsip-Funktion in eine Extra Datei packen, mein Vorschlag: z.B alle Funktionen zur Zeichenketten-verarbeitung in eine Datei und alle mit dem gleichen Namensbegin: STR-DIV STR-SUBST STR-ADD oder wie auch immer, dann wieder alle Funktionen, die was mit Blöcken zu tun haben in eine Datei, alle Funktionen zur Table-object-bearbeitung in eine usw.
Dann hast du später eine schön sortierte Bibliothek. Und für Tools läd man entweder alle benötigten Bibos, oder man kopiert sich ie Einzelnen Bausteine zusammen, oder man nutz ein sogenanntes Pack-and-go .. da hat IMHO BENWISCH was tolles.

------------------
- Thomas -
"Bei 99% aller Probleme ist die umfassende Beschreibung des Problems bereits mehr als die Hälfte der Lösung desselben."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>> Vielen Dank an alle! Scheinbar habe ich einen kleineren Diskussionsbedarf geweckt...

Gern geschehen. Das ist ein essenzielles Thema. Der Eine packt's geschickt an, der andere verbringt 90% seiner Zeit damit, immer wieder den selben Code zu produzieren (aber jedesmal mit neuen Fehlerchen)

>> Ich möchte vermeiden, daß ich bereits am Anfang grobe Fehler mache.

Ein ausgezeichneter Ansatz

>> Eine gewisse Eleganz will ich mir schon selbst abverlangen, zumal man sich später viel Ärger und Arbeit erspart, vom "Spott" der wirklichen Lispler mal ganz abgesehen!

Jeder fängt mal klein an. Ein Programmierer, der seinen Code vom Vorjahr immer noch "richtig Klasse" findet und keine Notwendigkeit für  Veränderungen sieht, sollte eine Umschulung zum Toilettenfrau machen. Da muss man kaum was dazulernen;-)

>> ... in sinnvolle Häppchen zerlegt, die beliebig verwendbar sind und ohne Umbau (nahezu) überall laufen.

Ganz genau. Sowas ist dann auch leicht in andere Sprachen zu portieren. Spaghetticode schwimmt immer in Soße.

>> Kennt man sich denn da noch aus?

Muß man doch gar nicht! Was funktioniert, vergisst man eben für eine gewisse Zeit. Man braucht nur eine Übersicht bzw. Kurzanleitung als Gedächtnisstütze. Den eigentlichen Code - wenn er sich als stabil erwiesen hat, braucht man sich evtl. auf Jahre hinaus gar nicht mehr anschauen - es sei denn, man hat Neues dazugelernt. Dann ist mal ein "Frühjahrsputz" angesagt.

>> Ich habe gerade einen Ordner mit 200-300 *.lsp-Dateien vor Augen. Was tut ihr? Alle einzeln laden oder in die Acad####doc.lsp oder...

Das können auch tausend werden. Da halte dich an das, was Cadmium sagt. Je nach Art des Programms steht dann am Anfang nur (load"string"), (load"vector"), (load"list"), (load"xdata") usw. drin,
immer das, was du für das anliegende Projekt brauchst. Noch eleganter ist dann ein (needs 'string 'math 'vector). Dann muss nur die needs.lsp im System verankert werden. 

>> Ich frage wohl Sachen, die für euch selbstverständlich sind.

Für manche mehr, für andere weniger;-)

>> Für solche Tips ist aber dieses Forum doch da, oder?!

Natürlich!

>> Mit der Bitte um Nachsicht

Wofür denn? Dafür, dass du da ganz vernünftig vorgehst? Diskussionsbedarf weckt man hier, indem man gute Fragen stellt. Also war's eine;-)

Grüße, Justus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

So viel positive Resonanz freut mich! Das gibt Mut, weitere Fragen zu stellen.

5 Sachen von meiner Seite:

1. Danke an Thomas und Justus.

2. Danke an Justus und Thomas.

3. @Thomas: Könntest Du das "Pack´n go" etwas genauer erläutern? Was hat Benwisch gebastelt? Bin noch nicht fündig geworden...

4. @Justus: >>Noch eleganter ist dann ein (needs 'string 'math 'vector). Dann muss nur die needs.lsp im System verankert werden.

Was ist diese "needs.lsp"? Eine Lisp-Verwaltungs-Datenbank in lisp? Ein kleines Beispiel wäre hilfreich, um mein Verständnis zu erweitern...

5. DANKE!!!

Freddy

[Diese Nachricht wurde von Paulchen am 12. Dez. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

zu 3. schau mal speziellhier ... aber damit würde ich nicht unbedingt anfangen, das ergibt sich dann.

------------------
- Thomas -
"Bei 99% aller Probleme ist die umfassende Beschreibung des Problems bereits mehr als die Hälfte der Lösung desselben."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP