Sauberes und 'schlankes' Programmieren

Hallo zusammen,

da schon solche Fragen augetaucht sin und dass etwas ist, dass jeder brauchen kann, starte ich mal diese Gemeinschaftstutorial.

Jeder soll doch seine Tipps posten und ich trage dann - der Übersicht halber - alles in den ersten Post.

Habt ihr Regeln für saubere Programmieren?

___

Resource Sparen

- möglichst wenig und langsames Polling.

- möglichst wenig easy VIs verwenden besonders dan wenn zum Beispiel etwas in einem Loop in eine Datei gespeichert wird. Dan nur das Lesen im Loop und Referenz öffne un dschliessen vor bzw. hinter dem Loop.

- Array-bearbeitende VIs brauchen viel Ressourcen (wenn möglich nicht in Loops)

- Bei der Bearbeitung von Arrays: For-Schleifen den While-Schleifen bevorzugen, da die For-Schleifen in vorherein wissen wieviel Speicher benötigt wird und die While-Schleife bei jeder Iteration neuen Speicher allokiert.

- SubVIs dynamisch Aufrufen, da normal aufgerufene SubVIs immer beim Starten des HauptVIs geladen werden. (In LabVIEW 8 gibt es Schleifen die dies direkt Lösen.) genaueres unter Ausfuehrungsprioritaeten/Speicherallokierung in/von LabVIEW


Sauberes und Übersichtliches

- immer von Links nach recht Coden

- in SubVIs unterteilen (wird überischtlicher und der gesammte Code muss nicht auf einmal geladen werden)

- so wenig globale Variablen wie möglich verwenden

- kein wire-crossing (wenn irgend möglich)

- Datenströme sinnvoll zusammenfassen (Cluster, Arrays). Z.B. nicht zehn Connectors an ein SubVI, wenn nur einige vom User eingegebene Strings übergeben werden.

- Größe des Block-Diagramms auf möglichst eine Seite beschränken.

- "Icons eng gruppieren, aber nicht zu eng!" - Gleiches gilt für die Verbindungen. Die Verbindungen sollten mindestens soweit auseinander liegen, dass man sie mit den Augen (statt mit dem Mauszeiger oder Finger) verfolgen kann

- SubVI-Icons sinnvoll gestalten/beschriften (gibt nix schlimmeres, als wenn alle SubVIs gleich aussehen)

- Farbwahl bei Icons möglichst konsequent

- Viel/Geschickt kommentieren, besonders bei komplexen Abläufen, das hilft später oder anderen sich schneller in den Ablauf reinzudenken




___

Es gibt noch viele mehr. Also posted,schickt PMs oder mailt mir.

g markus

- kein wire-crossing (wenn irgend möglich)

- Datenströme sinnvoll zusammenfassen (Cluster, Arrays). Z.B. nicht zehn Connectors an ein SubVI, wenn nur einige vom User eingegebene Strings übergeben werden.

- Größe des Block-Diagramms auf möglichst eine Seite beschränken. Icons eng gruppieren, aber nicht zu eng! Wires müssen sichtbar bleiben.

Wurm

- SubVI-Icons sinnvoll gestalten/beschriften (gibt nix schlimmeres, als wenn alle SubVIs gleich aussehen)

- Viel/Geschickt kommentieren, besonders bei komplexen Abläufen, das hilft später oder anderen sich schneller in den Ablauf reinzudenken

- Farbwahl möglichst konsequent

- "Icons eng gruppieren, aber nicht zu eng!" - Gleiches gilt für die Verbindungen. Die Verbindungen sollten mindestens soweit auseinander liegen, dass man sie mit den Augen (statt mit dem Mauszeiger oder Finger) verfolgen kann

chiefwiegam schreib "-so wenig globale Variablen wie möglich verwenden (Referenzen sind besser) "

Auf Referenzen (properties) würde ich wenn möglich verzichten. Das Problem bei Referenzen ist, das die Methoden die mit der Referenze ausgeführt werden im Frontpanel Task ausgeführt werden d.h. LabVIEW muß immer einen Taskwechsel bei R|W von einer Property ausführen.
= hohe Systemauslastung

mfg

Mario

hi mario,

das ist ein tipp den ich am basis-kurs von ni erhalten habe.
habe den eintrag mal entfernt. würde dem aber gerne weiter nachgehen.
kennt sich sonst noch jemand damit aus?

g markus

Hallo

Du kannst es ganz leicht ausprobiern.
Eine while Schleife die in ein control den Incrementator Wert schreibt, mal über referenze Property->Value und mal über den indicator Node.

das Control wird bei jeden Wert der an das Property übergeben wird refreshed. Außerdem sind Refernzen zB. auch nicht thread safe soweit ich das weíß, Wires schon *g*


mfg

Mario

Anzeige

chiefwiegam schrieb:-möglichst wenig und langsames Polling.

-Array-bearbeitende VIs brauchen viel Ressourcen (wenn möglich nicht in Loops)

-in SubVIs unterteilen (wird überischtlicher und der gesammte Code muss nicht auf einmal geladen werden)

Um Polling ganz zu vermeiden ggf Queues verwenden
Wenn ein Array verarbeitet werden soll, dann nur mit For Schleifen arbeiten (bei For Schleifen weiß LV beim Compilieren des Codes wieviel Speicher allokiert werden muss - bei einer While Schleife muss LV bei jeder Iteration neuen Speicher allokieren!)
In SubVIs aufteilen ist schoen und gut jedoch wird beim Kompilieren (sprich klick auf den Run Button) der KOMPLETTE Code kompiliert - seis in einem SubVI das bereits von vornhinein in einem Case liegt der durch die statischen Einstellungen der Parameter mit Sicherheit nicht abgearbeitet wird oder nicht!
Wenn man diesen Effekt umgehen will kommt man um den dynamischen Aufruf von SubVIs nicht herum!
(in LV 8 stehen zwei neue Schleifenarten zur Verfuegung die die Eigenschaft haben, Cases die nicht abgearbeitet werden (auf Grund von statischen Einstellungen die beim Klicken auf den Run Button gegeben sind und waehrend der Laufzeit nicht geaendert werden) außen vor zu lassen, sprich NICHT in den Speicher laden!)

- Cases am besten immer mit kurzem Kommentar versehen, damit man schnell sieht welcher Fall nun vorliegt.

- Lange Verbindungen mit Beschriftung versehen, damit man weiß, ob auch die richtigen Daten ankommen.
Mein Vorschlag: 4 VIs mit jeweils einem Komentarfeld für alle vier Flußrichtungen. In der Palettenansicht noch den Haken bei "VI zusammenführen..." reinmachen und das Textfeld wird direkt eingefügt. (Frei nach dem "Kommentar-VI" von OpenG)


- VIs "An linker Kante" ausrichten. Bringt Übersichtlichkeit.
- Strg+J um unwichtigere Verbindungen in den Hintergrund zu bringen
- Strg+K um wichtigere Verbindungen in den Vordergrund zu bringen

heijeijiejieji

das stellt's mir teilweise echt die Zehennägel auf:

Arrays in while-loops:
Array von der benötigten Größe vor der while-loop initialisieren und die geänderten/einzufügenden Teile mit "replace array subset" ersetzen

sub-VIs NICHT dynamisch aufrufen!
VI-Server braucht immer mehr Ressourcen als ein normaler Call, ausserdem erzeugt man Spaghetti-Code, den keiner mehr lesen kann. Die Aussage, dass das VI nicht in den Speicher geladen wird stimmt nur zum Teil: Wenn man die "call by reference node" verwendet und eine "strictly typed refnum" verwendet wird das VI sehr wohl in den Speicher geladen. Wenn man die Referenz zum SubVI erst zur Laufzeit öffnet, muss man damit leben, dass die Runtime Engine auch Zeit zum Laden und Starten braucht!

Referenzen: Mario W hat recht ...[/quote]

' schrieb:Mein Vorschlag: 4 VIs mit jeweils einem Komentarfeld für alle vier Flußrichtungen. In der Palettenansicht noch den Haken bei "VI zusammenführen..." reinmachen und das Textfeld wird direkt eingefügt. (Frei nach dem "Kommentar-VI" von OpenG)

Hi Chris,
deinen Vorschlag verstehe ich nicht so recht. Könntest du davon wohl mal ein Beispiel machen und es hochladen? Das wäre echt klasse.
Gruß, Tobias