Aufruf zum sauberen "Coden"

  • Hallo,
    dies soll eine Diskussion starten.
    Ich habe den Quelltext einiger plugins angeschaut.
    Dort findet man Zeilen wie diese:

    Code
    DrawImage(mJob->GetSkin()->Button(), 93, 118 + i * 40);


    Dies ist ganz schlechter Stil.
    Jetzt regt euch bitte gleich wieder ab, ich weiss dass viele das Programmieren als Hobby betreiben. Oft ohne es richtig gelernt zu haben. Aber das kann man ja ändern .-)


    Zahlen haben im Code nichts zu suchen!
    Dafür gibts #define, const int, oder eine Variable.
    Dabei ist es wichtig, vernünftige Namen zu verwenden (nicht A, B oder C).
    Der Namen soll genau Aussagen um was es sich handelt.


    Die 40 im obigen Beispiel ist die Höhe der Zeile im DVD-Menü. Also wäre ein passender Name RowHight. (Und bitte nur Englische Bezeichner! Wir sind schlieslich international) .


    Quelltext wird nur einmal geschrieben, aber sehr oft gelesen. Also lohnt es sich, etwas mehr zu schreiben und KURZ zu kommentieren was in etwa eine Funktion macht (Eine Zeile reicht oft aus).


    Beispiel:

    Code
    const int RowHight=40;
    const int ButtonPosX=93;
    const int ButtonPosY=118;
    
    
    DrawImage(mJob->GetSkin()->Button(), ButtonPosX, ButtonPosY + i * RowHight);


    Dieser Code ist viel "verstehbarer" und änderungsfreundlicher/robuster. Wenn wir die Höhe einer Zeile programmatisch ändern wollen, müssen wir jetzt nur die Definition von RowHight ändern damit es eine Variable wird.


    Code
    int RowHight=40;
    const int ButtonPosX=93;
    const int ButtonPosY=118;
    .....
    RowHight=CalculateRowHight();
    .....
    
    
    DrawImage(mJob->GetSkin()->Button(), ButtonPosX, ButtonPosY + i * RowHight);


    Man sieht, es erleichtert die Arbeit wenn man es richtig macht.

    Grüße, Dieter :)

  • Kurze Anmerkung: Es sollte sicherlich height heißen und nicht hight, also bspw. RowHeight. Ansonsten stimme ich Dir sicherlich zu, leider wird in erster Linie auf Funktionalität geachtet und nicht auf Schönheit. Meist ist es aber so, dass wenn Quelltexte besser dokumentiert und Variablen besser benannt werden, sich Fehler einfacher finden lassen.


    Ansonsten freuen sich sicherlich auch die Plugin-Autoren über Verbesserungen dieser Art.


    Kann im Moment aus eigener Erfahrung sagen, dass ich bei meinem neuen Plugin auch erstmal Wert auf Funktionalität achte und nicht so auf Stil oder Schönheit... Leider.

    Hardware: AMD Duron 900 MHz, 256 MB Ram, 1 x 400 GB und 2 x 200 GB Maxtor, 1 x 500 GB USB 2.0, Nec DVD-RW ND-3500AG, 1 x TT 1.6 FF DVB-S, 1 x Twinhan Budget DVB-T
    Software: VDR 1.4.1, BigPatch, DMH-DVD-Archive-Patch, Kernel 2.6.12
    ---
    "Hörma, wie heißt nomma dat Instrument mit den 3 Knöppen oben drauf...? - Ja richtig, Flöte!"

  • Freudig über diesen Aufruf, möchte ich gleich mal ins selbe Horn stoßen:


    Zunächst mal zu meiner persönlichen Rechtfertigung ;D, das Burn-Plugin ist seinerzeit im Auftrag und unter Hochdruck entstanden. Das anschliessende Patch-Sammelsurium hat zu der Übersichtlichkeit nicht gerade beigetragen... In der aktuellen Pre von burn-0.1.0 sollten bereits Ansätze deutlich werden, wie mein Coding sich mittlerweile gestaltet. Wie bereits an anderen Stellen erwähnt befindet sich das Plugin dahingehend z.Zt. im Umbruch.


    Insgesamt ist die exzessive Verwendung von Preprocessor-Makros, Zeigern und die Verschmähung der C++-Standardbibliothek schon kein besonders guter Stil (im Sinne von sauberer C++98-Programmierung), womit ich niemanden kritisieren will, denn als VDR angefangen hat, gab es nicht einen Compiler, der den Standard sauber eingehalten hat, und die verfügbaren Standardbibliotheken waren nicht rundum effizient implementiert.


    Das hat sich nun geändert, g++ in den Versionen 3 und besonders 4 unterstützen den Standard nahezu 100%ig (von Template-Exporten mal abgesehen), und die Standardbibliothek ist gereift. Damit ist es nicht nur unnötig, sondern auch potentiell gefährlich, Container o.ä. selbst zu implementieren, da viele mögliche Fehler schon von anderen gemacht wurden ;)


    Wenn mich heutzutage jemand etwas zu C++ fragt, würde ich immer zunächst versuchen Verfahren aus der STL zu adaptieren. (Und die STL kann weit mehr als nur die Arbeit mit Strings und Arrays zu vereinfachen)


    Die Verwendung von Bibliotheken bleibt letztlich dem Geschmack jedes einzelnen überlassen, was die Benutzung von Referenzen statt Zeigern, Templates statt Makros, und natürlich Konstanten statt Literalen angeht, geht es tatsächlich um Code-Sicherheit (und damit Development-Time).

  • Na dann verfass doch mal n sauberes syle guide. Wo soll den die Reise hingehen? ANSI C++, ungarische Notation...? ?(
    Vielleicht kannst Du ja kls bei der Gelegenheuit auch gleich noch dazu übereden, die Plugin-Schnittstelle so zu designen, dass die Plugin-Binarys nicht für jede VDR-Version und jeden Patch-Level neu generiert werden müssen! :D
    Und bei der Gelegenheit: Patches sind das letzte (bestenfalls ne temporäre Lösung, bis der Maintainer sie übernommen hat)! :§$%

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Der Standard heisst ISO C++ 98, da brauch man kein Guide für (ausser den Standard) :D


    Die ungarische Notation wie sie ursprünglich gedacht war ist sinnvoll, die, wie sie von Microsoft übernommen, wie eine Seuche verbreitet und anschliessend wieder eingestampft wurde ist ein Krampf. Aber wie immer - Geschmackssache.


    Gegen Patches hilft nur eine breitere Plugin-Schnittstelle oder eine liberalere Politik was das Übernehmen von Patchen angeht (und nein, ich habe nicht vor Klaus hier zu irgendwas zu überreden ;D)


    Was die Plugin-Schnittstelle angeht gebe ich dir Recht, aber was ist die Alternative? Man könnte in einer "Grundstruktur" die sich nie verändert eine API-Versionsnummer mitzählen, und inkompatible Plugins beim Laden ablehnen. Aber was wäre die Konsequenz? Wenn die benötigte Teilmenge der API sich nicht geändert hat geht der Plugin-Maintainer her, zählt seine API-Version hoch, und compiliert neu 8o

  • klar gibt es viele Programmierer die es nicht von Grund auf an gelernt haben und die auch viele Fehler machen.
    Ich finde es aber auch nicht sooo schlimm.


    Ich selber achte bei meiner Software mehr auf Sicherheit als auf Geschwindigkeit. Optimieren kann man immernoch. Fehler sollte man bekanntlich so früh wie möglich erkennen. Jedoch um sie zu erkennen, sollte man auf einen guten Styl achten.


    Ich finde es aber auch wichtig das man "sauber" programmiert. Es nützt niemanden was wenn man super schnellen code schreibt den keiner versteht. (bits geschupse sollte man immer kommentieren!).
    Code wird immer öfter gelesen als geschrieben. Ich habe mir auch schon einige Plugins angesehen. Leider gibt es kaum Plugins die wirkich gut kommentiert sind. Leider nicht mal VDR selber. (naja zumindest die Header sind gut zu verstehen)


    Das mit den Coding Styl ist zwar wichtig aber ich würde mir lieber mehr gute Kommentare wünschen.


    Ich würde mir zZ gerne mal den Aufbau eines cDevices zu gemüte führen. Welches ist den da gut Programmiert? Lord Du hast doch auch da schon Erfahrungen oder?


    Anonsten habe ich gerade das Buch "Effektiv C++ Programmieren" durchgelesen. Sehr interessant und viel nette Tips.

  • Bei der Programmierung von Devices habe ich immer einen weitaus pragmatischeren Ansatz verfolgt:


    Schreibe eine Device-Klasse, überschreibe jede virtuelle Funktion, plaziere in jeder Funktion ein aussagekräftiges printf, und starte VDR.


    Nach und nach sind die printf's dann sinnvollem Code gewichen, so wie man wusste was wann in welcher Reihenfolge aufgerufen wird (die PLUGINS.html hat ja auch schon ein paar Infos).

  • Zitat

    Original von LordJaxom
    Der Standard heisst ISO C++ 98, da brauch man kein Guide für (ausser den Standard) :D


    Dumm nur, das solche Normen für/von Fachleuten geschrieben sind, d.h. dem Grossteil der hier tätigen Hobbycoder (Autodidakten) die Grundlagen fehlen dürften, zu verstehen was darin steht. Wenn, dann müsste man das mal auf das Notwendigste und 'allgemein verständliche Formulierungen' herunterbrechen...


    Zitat

    Original von LordJaxom
    Die ungarische Notation wie sie ursprünglich gedacht war ist sinnvoll, die, wie sie von Microsoft übernommen, wie eine Seuche verbreitet und anschliessend wieder eingestampft wurde ist ein Krampf. Aber wie immer - Geschmackssache.


    Also, nehemen wir doch die, wie sie ursprünglich gedacht war!? Warum in diesem Zusammenhang immer die Verknüpfung mit MS?


    Zitat

    Original von LordJaxom
    Gegen Patches hilft nur eine breitere Plugin-Schnittstelle oder eine liberalere Politik was das Übernehmen von Patchen angeht (und nein, ich habe nicht vor Klaus hier zu irgendwas zu überreden ;D)


    Ich möchte jetzt kls nicht zu nahe treten (u.a., weil er das hier vielleicht gar nicht mitbekommt) und gleich vorweg nehmen, dass ich seine Arbeit prima finde...
    und die Veröffentlichung einer Software von so breitem Interesse schaft m.E. - ob 'man' will oder nicht - auch die Verpflichtung, dem Interesse der Merheit zu folgen!


    Zitat

    Original von LordJaxom
    Was die Plugin-Schnittstelle angeht gebe ich dir Recht, aber was ist die Alternative? Man könnte in einer "Grundstruktur" die sich nie verändert eine API-Versionsnummer mitzählen, und inkompatible Plugins beim Laden ablehnen. Aber was wäre die Konsequenz? Wenn die benötigte Teilmenge der API sich nicht geändert hat geht der Plugin-Maintainer her, zählt seine API-Version hoch, und compiliert neu 8o


    Es kann m.E. nicht so schwierig sein, eine (in weiten Grenzen)abwärtskompatible Plugin-Schnittstelle zu schaffen. Weil Du MS ins Spiel gebracht hast: Eine Windows-Applikation, die sich nur an die definierte API gehalten hat, und ursprünglich für 95 geschrieben wurde, läuft ohne neue Übersetzung auch heute noch unter XP...Ob man es nun soweit treiben muss, das CPM- (8080) Binaries noch heute in ner DOS-BOX laufen...?
    Ich weiss gar nicht, warum genau man ein Plugin für jede VDR-Version / jeden Patchlevel neu übersetzen muss, jedoch dass z.B. es die Beschaffung der Plugins für normal Sterbliche extrem erschwert und sich kleine, nette Plugins damit nicht durchsetzen können. Viel Plugins setzen keine Patches voraus, d.h. würden auch problemlos mit einem vanilla VDR laufen. Und warum sollte ein Plugin in einer aktuelleren Version des VDR nicht laufen, bloss weil der ein paar neue Features bekommen hat...?

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

    Einmal editiert, zuletzt von habichthugo ()

  • Zitat

    Code wird immer öfter gelesen als geschrieben.


    Aber noch öfter ausgeführt. Von den 1000den VDR-Benutzern sehen sich wahrscheinlich net so viele tatsächlich den Code an, sondern erfreuen sich vielmehr an der Funktionalität der Plugins. Höchste Priorität ist da - meiner Meinung nach - natürlich die Funktionalität. Dann könnte man nämlich gleich noch anfangen zu meckern und sagen, dass es auch keine ausreichende Doku für die Plugins gibt. Also zur Bedienung meine ich jetzt.


    Es war ja auch nur ein Hinweis von Dieter. Eine Art wieder ins Gedächtnis rufen. Bei mir hat es zumindest gewirkt. Wären wir hier im Closed-Source-Bereich wäre das natürlich niemandem aufgefallen, wie schlecht manch ein Stil ist.


    Die Frage ist dann aber auch, ob es tatsächlich mehr Plugins gäbe, wenn alle Plugins im Code sehr gut dokumentiert wären...

    Hardware: AMD Duron 900 MHz, 256 MB Ram, 1 x 400 GB und 2 x 200 GB Maxtor, 1 x 500 GB USB 2.0, Nec DVD-RW ND-3500AG, 1 x TT 1.6 FF DVB-S, 1 x Twinhan Budget DVB-T
    Software: VDR 1.4.1, BigPatch, DMH-DVD-Archive-Patch, Kernel 2.6.12
    ---
    "Hörma, wie heißt nomma dat Instrument mit den 3 Knöppen oben drauf...? - Ja richtig, Flöte!"

  • ich könnte ja das bestreben nach Kompatibilität zwischen Stable Version verstehen. Fakt ist aber das 1.3.x ein developer Zweig ist. Dort liegt der schwerpunkt wo anders.


    Das ein Win95 Programm noch mit WinXP läuft verdanken die Leute aber auch das Windows noch extrem viele Altlasten mit sich daher bringt. Das es unter Linux nicht so ist, ist vielleicht durchaus ein Nachteil, aber das ist bei Linux "fast" immer so.
    Klaus versucht doch schon die Schnittstellen Änderungen sehr gering zu halten. Es lassen sich doch auch fast immer alle Plugins mit der neuen Version übersetzen. Aber eine Binäre Kompatibilität wird es wohl nie geben.
    Wenn Du ein Plugin mit VDR 1.2.6 übersetzt, dann wird es wohl nicht mit 1.3.45 laufen. Leider ist es auch so das man ein Plugin nicht auf SuSE übersetzen kann und dann mit Debian benutzen kann.
    Um so etwas zu erreichen müsstest Du dich eher an die Leute von gcc oder libs wenden.
    Aber wir weichen vom Thema ab.


    Was das Coden von Plugins angeht, könnte man hier im wiki mal ein paar mehr Seiten ausfüllen.
    Ich war mal mit den Skins angefangen:
    http://www.vdr-wiki.de/wiki/index.php/Entwicklung_Skins
    (sowas brauche ich für devices) ?(


    Ein paar Tips und Tricks habe ich auch mal zusammengefasst:
    http://www.vdr-wiki.de/wiki/in…Entwicklung_TipsundTricks


    Zitat

    Original von dmh
    Die Frage ist dann aber auch, ob es tatsächlich mehr Plugins gäbe, wenn alle Plugins im Code sehr gut dokumentiert wären...

    Zumindest würden mehr Fehler gefunden und beseitigt werden können. Nicht nur die Menge sonder auch die Qualli zählt.

  • Hi,
    ja diese Buch ist gut (Autor ist Mayer?)


    Hight Higth verwechsele ich seit Jahren. Same with chnage and change.

    Grüße, Dieter :)

  • Mensch das geht ja ab hier. Während ich meine letzte Post schrieb kamen mehrere an :)


    Ungarische Notation braucht man wenn man
    1. nicht programieren kann
    2. keine typsicheren Compiler einsetzt
    3. heute nur in start abgeschwächter form


    Ich setze es ein für Zeiger (pPointToSomething) und als "classmember" m_Name (ich bin MSVC/MFC verseucht).
    Konstrukte wie pnublapblaName erhöhen nicht die Lesbarkeit! Und was macht man bei Objekten?


    Beruflich sehe ich sehr viel Closed Source Code von Kunden (und Kollegen). Da ist mehr Schrott als guter Code vorhanden. Leider.

    Grüße, Dieter :)

  • M.E. wäre schon viel erreicht, wenn die Patch-Level-Äbhängigkeit mal weg wäre. Dispri. x VDR-Version x Patch-Level ergibt einfach zu viele Permutationen, die gerade den 'kleinen' Plugins das Leben schwer machen. Da sterben doch viele schon bei der Geburt, weil ein Grossteil der (anfangs wenigen) Interessenten nicht in der Lage ist, das aus zu probieren (weil's niemand passend übersetzt). Wer weiss, wie oft ein und die selbe Plugin-Idee so schon im Nirvana verschwunden ist...


    btw: Gibt es eigentlich mitlerweile eine Schnittstelle, um Plugins aus anderen Plugins mit Daten(-Pfaden) zu rufen? Ich meine so nix DVDSelect /dev/dvd verbiegen...? Mir schwebt da ein schönes Plugin zur Verwaltung von Videos, Bildern und Musik vor...

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • meinst Du damit die Übergabe von Parametern an andere Plugins?
    Ja das geht mit den Services. Ist im Grunde ganz einfach. Klaus liefert zwei Beispiele dafür aus. Einen Server und einen Client.
    Wenn Du so die Parameter übergeben hast, dann kann Du das Plugin auch noch starten.
    Siehe hier:
    http://www.vdr-wiki.de/wiki/in…s#Andere_Plugins_aufrufen
    (ist aber etwas dirty)

  • Zitat

    Original von Dieter
    Ungarische Notation braucht man wenn man
    1. nicht programieren kann
    2. keine typsicheren Compiler einsetzt
    3. heute nur in start abgeschwächter form


    4. Man keine ordenliche, integriere Entwicklungsumgebung mit Klassenverwaltung, eingebundener API-Referenz...hat, also man wie hier wohl eher üblich mit nem Rohtexteditor, make und x konfusen Bibliotheksreferenzen ohne ordentliche Suchfunktion ... rummacht.
    ...
    1e999. Man nach CMMI 5 dazu verpflichtet ist.

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Zitat

    Original von decembersoul
    meinst Du damit die Übergabe von Parametern an andere Plugins?


    Was ich meine ist, das ich z.B. mit einem Plugin Bilder (aus einer Datenbank) auswähle (z.B. von 23.12.2004-31.1.2004) und mit denen dann das PicturePlugin zur Darstellung rufe. Und wenn ich daraus zurückkehre, bin ich wieder in der Bilderauswahl (z.B. 'unsere Hochzeit')...

    yaVDR 0.6.2; H61M/U3S3 / G530 / 4GB / GT 520 (passiv) / Cine S2 (Rev. V5.5) + DuoFlex S2 / 120GB SSD (System; SATA>USB) + 3TB SATA 6Gb/s; LCD-TV Toshiba 42VL863G; AVR Yamaha RX-S600...

  • Hi,


    selbst weit davon entfernt ein Programmierer zu sein, will ich nur mal auf die schnelle ein Stichwort eingeben: Inspektion. Darunter versteht man Techniken, in denen ein Experte unter zu Hilfenahme von Checklisten, Guidelines oder perspektivenbasierten Szenarien mögliche Fehler und Schwachstellen im Code (oder anderen Entwicklungsartefakten) identifiziert.


    Diese Methoden haben im Software Engineering eine lange Tradition und haben sich als sehr effizient erwiesen. Sollte sich dieser Thread weiter entwickeln und Interesse bestehen, kann ich dem gern mal genauer nachgehen. Ich sitze hier in einem Forschungsinstitut, an dem viel in dieser Richtung gemacht wurde.


    Als Checkliste für die Inspektion könnten zum Beispiel sog. Bad Smells dienen:
    Beispiel 1, Beispiel 2


    In jedem Fall erforderlich wäre aber eine Art Review Prozess innerhalb der Community.


    --schmettow.

    VDR 1.4.0 [dvd, dvdselect, mp3ng,remote, control, graphTFT, taste, tvonscreen, streamdev-server] - FW f32623
    OpenSuse 10.0 Vanilla 2.6.15.4 - vdrconvert - Noad
    Dign HV5, Asus P4P800 deluxe, Celeron M (silent modded) - TT 1.5 - Budget-S - AVBoard 1.3 - 12" TFT
    Peripherals: Kameleon 8060 - Philips DFR-9000 - Sharp 26GA4E - Pinnacle Showcenter 1000g

  • Nochmal zur ungarischen (und warum ich dabei MS ins Spiel gebracht habe):


    Wenn man seine Variablen sinnvoll benennt, braucht man auch ohne hochintegrierte Entwicklungsumgebung in den allermeisten Fällen keinen Typbezeichner im Variablennamen. Im Gegenteil, mit einem ordentlichen OO-Ansatz erwarte ich von einem speziellen Objekt (z.B. "text"), dass es ein bestimmtes Verhalten hat. Will heissen dass Methoden, die etwas gleichartiges tun, auch die gleichen Namen haben. So kann ich ein Objekt "texte" problemlos von vector<string> auf list<string> ändern, sofern ich nur Methoden benutze die beide gemein haben. Mit der MS-ungarischen müsste ich im Code unzählige vecTexts in lstTexts o.ä. ändern.


    Die Eigenart, den Typ mit in den Namen zu packen, wurde übrigens verstärkt von MS verbreitet (deshalb kam ich drauf), und selbst sie nutzen es inzwischen (wieder) nicht mehr. Die ursprüngliche ungarische Notation sah vor, dass man einem Variablennamen (und möglicherweise Methodennamen) einen Context zuordnen kann. Im Web habe ich mal ein schönes Beispiel dazu gelesen, da ging es um eine Webanwendung, in der mit Escaped'ten und Unescaped'ten Strings jongliert wurde.


    Hier wurden unescaped'ten Strings das Kürzel ue und den escaped'ten das Kürzel e vorangestellt. Den Konvertierungsmethoden ebenso. Dadurch kann man Sinn-Fehler bereits durch anschauen des Codes sehen:


    Code
    ueQuery = ueEscape(..); 
    eQuery = eUnescape(..);
    ueQuery = eEscape(..); // hier stimmt was nicht


    Ich persönlich kennzeichne alle Variablen nach einem bestimmten Schema (z.B. Member m_Xyz) und nutze o.a. wenn im Context angebracht. Von Namen wie m_lpCStrQuery halte ich nicht viel, zumal (wie ich zur Zeit auf der Arbeit feststelle) die meisten Variablen dann sowieso m_oName heissen (weil man für alle Arten von nicht-integralen Typen o wie Objekt nimmt).


    Wenn man zusätzlich noch Namespaces gewinnbringend einsetzt, kann man prinzipiell alle Namen, die aussen gebraucht werden (was ich intern in meiner Klasse mache interessiert den Anwender im Zweifel nicht), als Klartext-Wörter ohne Schnörkel formulieren (nein, nichtmal c, C oder T vor jedem Klassennamen ist nötig ;) )

  • Schön wär ja, wenn es da nen "Leitfaden für Dummies/Anfänger" gäbe, also ne Anleitung von jemandem der's gelernt hat und auch beruflich ausübt.


    Ich denke da an eine echte Style Anleitung, nicht Hinweise auf CMMI ?( , MSVC/MFC (darunter kann man sich ja noch wenigstens was vorstelln), ISO C++ 98 (dazu findet google nur Schrott und Complience Aussagen..) usw.


    Vielleicht macht sich ja mal einer von euch die Mühe..

  • Ich würde mich ja gerne mal an so etwas versuchen, jedoch weiss ich nicht so recht wie ich da ran gehen soll. Kann man Grundlagen voraussetzen? Wenn ja, welche? (Einige gute C Programmierer sind z.B. lausige C++-Programmierer) Womit fängt man an, wenn man Plugins programmieren möchte und was kann man schon?


    Soll so ein Leitfaden mit Designtechniken beginnen, mit Programmieridiomen, oder doch besser eine Einführung in die Standard-Bibliothek geben, oder sollte man im Bezug auf VDR-Programmierung sogar gänzlich auf diese verzichten, damit es nicht zuviel Vermischung mit den VDR-internen Datenstrukturen gibt?


    Ich kann Euch gerne meinen (mit der Zeit gereiften, und auf Standard-C++ ausgerichteten) Stil näherbringen, und einige Techniken erläutern mit denen ich gerne arbeite um mir das Leben zu erleichtern, aber ich fürchte das wird eher eine lose Artikelsammlung als ein zusammenhängender Leitfaden (zudem glaube ich dass es da in entsprechenden Fachforen kompetentere Leute gibt, da nur leider nicht auf VDR bezogen), und letztenendes wäre es immer noch mein eigener Stil (nicht zumsonst unterscheiden sich Lehrmaterialien und Vorlesungsskripte zu C++ bisweilen erheblich).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!