IT

Ich muss ja sagen dass ich codetechnisch ein sehr aufgeräumter Mensch bin.
Was wahrscheinlich daran liegt dass ich hauptsächlich in C++ programmiere und unsauberer oder undurchgängiger Stil dort unglaublich schnell die Lesbarkeit beeinträchtigt.

Aus gegebenem Anlass (mein Projekt wird immer größer) möchte ich nochmal betonen wie wichtig es für jeden Programmierer es ist sich eine praktikable Variante der ungarischen Notation anzugewöhnen.

Natürlich gibt es noch einiges mehr Optimierungsraum:

• Achtet darauf eure Deklarationsdateien (Sprich headerfiles) nicht für Definitionen zu missbrauchen (mit der Ausnahme von Template-Definitionen), dazu gehören Macros: Wenn ihr solche verwenden müsst, achtet darauf dass der Code kurz bleibt, wie gesagt, Deklarationsdatei und so.
• Globale Variablen sind zuallererst einmal als Designfehler zu sehen. Berechtigung haben sie nur sehr selten, und mit OOP hat das Ganze nichts mehr am Hut.
  Falls man doch meinen sollte sie zu brauchen: Zugriff sollte in C++ durch ::name umgesetzt werden.
• Lasst die Unterstriche aus Variablenbezeichnungen raus! Klar, ungarisch für Präfixe und so, aber: Innerhalb der Bezeichnung haben die Dinger nichts verloren.
  my_map_start_iterator = m_mp_my_map.begin() kann keiner lesen, itStart = m_mp.begin(); genügt völlig.
• Intelligente Namen geben. Zum Beispiel ist die Bezeichnung strText ziemlich sinnfrei.
• Stress sparen kann man sich auch in Funktionsaufrufen. Wird ein benutzerdefinierter Typ übergeben ist es am klarsten den Parameternamen gleich dem Typ zu setzen:
  LoadModel(Model* toLoad) ist pfui, ebenso LoadModel(Model* model3ds) und LoadModel(Model* reference) auch, LoadModel(Model* model) dagegen hui.
• Abkürzungen bitte nicht konsequent großschreiben: getHTMLPage() wird zu getHtmlPage().
• Redundanzen vermeiden was Namen angeht. Eine Matrix-Klasse  benötigt keine Funktion InvertMatrix() und eine Klasse Gui (man bemerke: G groß, Rest klein) benötigt keine Methode ShowGui(). Der Aufruf gui.show(); ist schneller und angenehmer zu lesen.
• Private Variablen sollten mit einem Unterstrich gekennzeichnet werden. _transformationMatrix oder transformationMatrix_ geht gleichermaßen – Beides lässt keinen Zweifel darüber aufkommen dass die Variable extern niemanden zu interessieren hat.
• Meine Klassen erweitere ich mit einem Präfix als Indikator um welches Design Pattern es sich handelt:
  C – Normale Implementierung
  I – Interface
  S – Singleton
  T - Template
  Dass dies Standard ist glaube ich nicht, aber mir hiflt es wirklich sehr.
  
• Nutzt kluge Umbrüche wenn die Zeile nicht reicht! Rechnungen nach dem nächsten Operator umbrechen, couts nach dem nächsten << und so weiter. Horizontale Scrollbalken haben im Editor nichts zu suchen. Achtet dabei auch darauf dass nicht jeder einen 24″ Bildschirm mit 16:10 Verhältnis besitzt und brecht dementsprechend früh um.
• Nutzt Boolean-Variablen um bedingte Ausdrücke zu vereinfachen:
  if ( (lstToDo.size() = 0 && !IsCalculation) || lstErrorCodes.size() !=0){ ist sehr, sehr schlecht.
  Besser ist:
  bool isDone = lstToDo.size() == 0 && !isCalculating;
  bool isError = lstErrorCodes.size() = 0;
  if (isDone || isError){
• Benutzt die Leertaste!
  for(int i=0;i<arr.length();i++)
  arr[i]+=(newPos+thisPos)*1/2;
  Grauenhaft.
  for  (int i = 0;  i < arr.length();  i++)
  arr[i]  +=  (newPos + thisPos)  /  2;
  Besser.
• Der Raum Zwischen Methoden und Klassen kann nicht unterschätzt werden. Ich persönlich lasse zwischen Methoden 2 Leerzeilen, zur nächsten Klasse 4.
• Kommentare sollte es viele geben, allerdings sollten sie auch eine Aussage haben.
  coords.x++;                            //  increment x by 1
  ist dumm.
  coords.x++;                           // move player to the right
  ist besser.
• Kommentare sind englisch.
  Immer.
• Rückt Kommentare bündig ein. Selbsterklärend. Kommentare sollten nicht die Sicht nehmen weil sie kreuz und quer im Code liegen. Dazu gehört auch, ganz wichtig:
• Soweit möglich, Kommentare hinter den Zeilen postieren, nicht über dem zu kommentierenden Code. Letzteres ist vor Methoden und Klassen schön übersichtlich, nicht jedoch im fließenden Code.
  Außnahme: Man erläutert die Aufgabe eines kompletten Codeblock. Das macht man dann natürlich vor dem Block.
  
• Achtet als generelle Regel darauf dass die Kommentare den Codefluss nicht stören oder unterbrechen, jedoch schnell zu sehen sind wenn man etwas vom Code nicht versteht.
  
• Über Klassen kommt bei mir zusätzlich eine Kommentarlinie die den Namen enthält, darunter eine kleine Definition:
  //————————————–CVec3f——————————————
  // Data structure holding three floating point coordinates and allowing all necessary vector operations
  // through its’ overloaded operators.
  Darunter (zu den 4 Leeren Zeilen darüber!) nochmals eine Leerzeile und dann der Klassenrumpf.

Es gibt der Regeln sicherlich noch hunderte mehr, aber soviel sprang mir gerade in den Kopf. Wer noch was wichtiges auf dem Herzen hat der sei Willkommen in den Kommentaren noch was zu schreiben

Ich arbeite ja im Moment sehr fleißig an meiner Grafikengine. Ein Problem über dass ich stolperte, erinnerte mich wieder daran wie wichtig es ist über die Sprache und die Bibliotheken mit denen man arbeitet Bescheid zu wissen. Diese Erfahrung möchte ich euch natürlich nicht vorenthalten

Schauen wir uns mal folgenden Versuchsaufbau an:

class Drawable{
public:
float position3f[3];
}

Irgendwo rufe ich nun auf: glLightfv(GL_LIGHT+light.index,GL_POSITION,light.position), wobei light natürlich von Drawable abgeleitet wird.

Das alles funktioniert so lange, wie ich den Code nicht folgendermaßen erweitere:

class Drawable{
public:
float position3f[3];
bool active;
}

Die Änderung führt dazu dass die OpenGL-Beleuchtung nicht mehr funktioniert. Idee warum?
Ein kleiner Tipp: Die Beleuchtung funktionierte wieder wenn ich active vor position deklariere.

Gelöst? Nicht schlimm, auch ich kam nicht auf Anhieb darauf.
Die Lösung des Ganzen erfordert Hintergrundwissen sowohl in OpenGL als auch in Speicherverwaltung:

1. OpenGL arbeitet wenn es um Positionierung (= Verschiebung) geht mit affinen Abbildungen (3×3 Matrix + Verschiebung), was durch die Nutzung von 4×4 Matrizen umgesetzt wird. Jetzt schnackelts. Ich nutze einen Vektor mit 3 Komponenten, OpenGL will aber 4. Die Vierte (sogenannte w-)Komponente ist eigentlich überflüssig, kann aber als Flag genutzt werden(wie in diesem Fall). Ich gehe mal davon aus dass openGL auf irgendeine Art eine 0 aus dem bad-pointer machte, so genau will ich das gar nicht wissen.
2. Die Variable position3f liegt auf dem Stack. Durch das übergeben des Pointers an glLightfv wurde für das vierte Element “ins Leere gegriffen”. Sicher warf dies irgendwo intern eine Exception, aber openGL verzichtet in solchen Fällen vollständig auf Funktionsrückgaben – Warum auch immer o.O
3. Jedenfalls. Durch Erstellen einer zweiten Variable auf dem Stack war der Bereich nach der 3. Float-Komponente nicht mehr leer, ganz fatal: Er war sogar von einem anderen Datentyp belegt. Und OpenGL liefert keinen Fehlercode, nein, die ganze Beleuchtung schaltet sich einfach aus.

Ich behob das Ganze natürlich damit dass ich position um eins vergrößerte. Kudos an Prof. Hahn und Prof. Kriha für die 1A-Vorlesungen in dem Bereich. An solchen Fehlern wird man ohne eingehendes Wissen über Kompiler und Sprache verzweifeln. Darum mein Aufruf:

Leute guckt euch gut an mit was ihr arbeitet!  Im Java-Sandkasten mag man sich austoben können, aber gerade in C hat man kaum eine Chance sauber zu programmieren, wenn man die Konzepte nicht versteht!

PS.: Bevor Missverständnisse aufkommen: C ist natürlich trotzdem (oder gerade deshalb) viel cooler als Java

Als ich mich heute auf mein Projekt einstellen wollte, mich reflektierend in meiner mitgenommenen schwarzen Cherry Tastatur verlor und nachsinnend in einer Welt von Templates, Makros und Funktionspointern zu driften drohte, fiel mein Blick auf einige unauffällige Tasten auf eben jener Tastatur. Wie wunderlich, waren diese doch nahezu unberührt von der vielzahl von Ablagerungen, welche sich doch sonst überall auf den Tasten breit machten. Nur eine dezente Staubschicht hatte sich sanft um die Objekte meiner Aufmerksamkeit gelegt:

Das man mit der PRINT-Taste unter Windows Screenshots erzeugt gilt als Common Knowledge, aber wusstet ihr dass die Kombination [ALT]+[PRINT] einen Screenshot des aktiven Fensters erzeugt? Sehr geschickt für Blogger.

Die SCROLL-LOCK-Taste, (oder einfach Rollen) erfüllte in längst vergangenen Zeiten die Funktion des Scroll-Rades, man konnte also den Bildausschnitt mit [ROLLEN]+[PFEIL OBEN/UNTEN] bewegen ohne den Cursor verschieben zu müssen. Die gleiche Funktion unterstützt das Visual Studio, allerdings nicht mehr mit der ROLLEN-Taste, sondern mit [STRG], sehr geschickt wenn man beim Programmieren keine Lust hat immer zwischen Tastatur und Maus zu wechseln.

Heute ist diese Taste unter Windows im Grunde völlig unsinnig geworden.  Mit [STRG]+2x[ROLLEN] lässt sich unter Windows XP zwar noch ein Memory Dump generieren, allerdings ist dies nur für Fehleranalysen nötig und die Funktion standardmäßig deaktiviert, in Vista soll diese Funktion gar nicht mehr existieren.

Jemand sollte sich die Mühe machen auszurechnen wieviel Geld gespart würde wenn die Taste mitsamt der damit verbundenen LED von den Tastaturen verbannt würde.

Die PAUSE/UNTBR-Taste war einmal dafür da das laufende Programm abzuschießen.

Ich erinnere mich an meine VB-Zeit (hach ja, als Programmierung noch so einfach war…), damals ließ sich mit [STRG]+[PAUSE] die Ausführung abbrechen, ein Relikt aus der DOS-Basic Zeit. Heute funktioniert das nur noch bei der Ausführung von Batches.
Gemeinerweise wird diese Abschießen-Funktion unter Linux durch die Kombination [STRG]+[C] erfüllt, ein hinterhältiger Kniff um Windows-User zu verwirren.

Für alle interessant: der BIOS-Start lässt sich noch heute mit einem Druck auf [PAUSE] pausieren und mit erneutem Druck wieder fortgesetzt werden.

Damit ist auch dieses Thema abgehandelt und der geneigte Leser hoffentlich wieder ein wenig klüger geworden

Es gibt kaum einen Rechtsbereich der für eine so breite Masse relevant ist und über den gleichzeitig so viel halbwissen herumschwirrt: Das deutsche Urheberrecht, kopieren von Medien und Nutzung von Tauschbörsen.

Da ich mir selbst über einige Sachen nicht klar war (und mich ein wenig von den anstehenden Klausuren ablenken musste) habe ich mir einige Zeit genommen und das Internetz nach Informationen von offizieller Seite durchsucht. Um ein wenig Klarheit in das Rechtsgewuschel zu bringen hier einige Erkenntnisse:

• Generell
  liegt Recht liegt auf der Seite des Urhebers, das heißt: Wenn es zu irgendetwas noch keine gesetzliche Schrankenbestimmung gibt ist es verboten. Diese Schrankenbestimmungen interessieren den Bürger natürlich am meisten.

• Privatkopie
  Da die Verbreitung von urheberrechtlich geschützten Inhalten in Haushalten irgendwann nicht mehr kontrollierbar war, wurde das Recht auf Privatkopien eingeführt, dafür allerdings die Urheberabgaben eingeführt (das heißt für euren Brenner habt ihr ca. 10€ an die Musik-, Film- und Verlagsindustrie abgegeben).  Der Bundesgerichtshof legt die Privatkopie so aus dass bis zu 7 Kopien im kleinen privaten Kreis herrumschwirren dürfen, im digitalen Umfeld jedoch weniger.
  Verboten sind Kopien aus offensichtlich rechtswidrig hergestellten Vorlagen und neuerdings auch aus offensichtlich rechtswidrig öffentlich zugänglich gemachten Vorlagen. Letzterer Zusatz wird allerdings kaum Auswirkungen haben, da sich sowas im Internet nur sehr schwer nachvollziehen lässt.
  Die Privatkopie darf sowohl analog als auch digital angefertigt werden.
• Gemeinsam genutzter Anschluss
  Auch wenn die Medienindustrie versucht zu verunsichern:
  Es besteht keine Störhaftung. Das heißt wenn ein Mitnutzer illegal Musik verbreitet besteht in der Regel keine Haftung, auch wenn die Abmahnung an den Eigner adressiert ist.
• Kopierschutz
  Kopiergeschützte Medien dürfen nicht kopiert werden. Das betrifft einige im Umlauf befindlichen Audio-CDs und fast alle DVDs.
  Allerdings(1): Interessanterweise gilt diese Regelung nicht für Computerprogramme(!).
  Das bedeutet: Von Computerspielen darf man trotz SecureRom und SaveDisk Sicherungen erstellen. Read the rest of this entry »

Vor kurzem kam ich bei einem Java-Projekt zum ersten Mal in die Situation externe Pakete einbinden zu müssen. Das sollte eigentlich auch gar kein so großes Problem sein, jedoch machten die zusätzlichen entstandenen Abhängigkeiten Probleme. Genau genommen musste ich letztendlich 4 zusätzliche Pakete finden und herunterladen, wobei innerhalb dieser Pakete wiederum probleme mit den unterschiedlichen Versionen entstanden. Man kann sich das Chaos also gut vorstellen.

Es sei X Anbieter eines freien Java-Paketes zum Automatisieren von Webseitenzugriffen. Y sei Anbieter eines extern Abhängigen Pakets zum verarbeiten der Log-Ströme. Nun stellt X die Entwicklung ein, während in Y eine revolutionäre Neuerung implementiert wird, die die Hälfte der Klassen des Pakets überflüssig macht. Ab Version 1.3.24 werden diese Klassen also einfach gelöscht. Noch besser: X nutzt in einigen seiner Klassen das com.*-package, in dem der Programmierer wohl wundersame und aufregende Klassen fand.

Fakt ist dass eben dieses Paket von Sun NICHT für den öffentlichen Gebrauch bestimmt ist, es enthält nur Klassen die sich in der Testphase befinden. Durchlaufen besagte Klassen diese Testphase erfolgreich, werden sie in die bekannten java.* bzw javax.*-Pakete geschoben. Wer das com.*-Paket nutzt kann also darauf wetten dass früher oder später die genutzte Klasse weg ist. Das selbst Entwickler wie Apache dies nicht kapieren, ist traurig.

Warum schreibe ich diesen Artikel?

1. Wenn offene Klassen verwendet werden, bindet diese in euer fertiges Paket ein!
2. Falls ihr doch nicht im Stande sein solltet externe Abhängigkeiten einzubinden bzw. falls lizenzielle Einschränkungen vorliegen, packt die VERSIONSNUMMER der externen Abhängigkeiten in die Dokumentation. Und betet dass der Hersteller der Abhängigkeiten ein Archiv früherer Versionen führt.
3. Schmeißt nicht einfach eine releaste Klassenstruktur um, und wenn dann dokumentiert das richtig.
4. Verwendet keine com.* Klassen. Falls das doch nötig sein sollte, siehe unten.

Da ich in einem anderen Projekt eben doch auf eine com.*-Klasse zurückgreifen musste (durchsichtige Fenster in AWT), hier ein Tipp falls ihr auch in so eine Situation kommt:

system.getProperty(“java.version”)

…gibt einen String mit der Version der JRE zurück. Nutzt ihr ein com.*-Paket, so checkt die Version und packt das Ganze in eine Bedingung.

Für alle die noch nichts davon mitbekommen haben:

Der “Neural Impuls Actuator”, kurz NIA ist “the new Thing” in der Spiele-HW und soll es ermöglichen Spiele mit den Gedanken zu steuern. Maus und Tastatur wären damit überflüssig. Klingt abstrus,  ist aber durchaus ernst gemeint und, man kann es kaum glauben, preislich massenkompatibel (ca. 170€).

Das ganze erinnert ein Wenig an die Mitte 90er, als viele bunte bewegte Bilder auf den Röhrenmonitor fanden und die IT-Welt ein bisschen zukunftsgeil war, ihr wisst schon, Virtual Reality und so, handliche Caves, kopfwehschwangere3D-Brillen und, Klassiker, der Cyberhelm:

Wundervoll, oder? Wär hätte damals gedacht dass wir 15 Jahre später immer noch nicht unseren Cyberhelm zur LAN-Party nehmen würden? o.O

Naja ist ja auch egal, jetzt haben wir ja NIA. Um den begeisterten Leser wieder runterzuholen: Die Maus benutzt man besser doch noch, der Einstieg kann wohl etwas deprimierend sein und mit Gedankensteuerung hat das Ganze wenig zu tun. Vielmehr werden Muskel- und Nervenimpulse auf der Haut überwacht. Dadurch werden Unterhaltungen während man Spielt sehr kompliziert, ein riesen Problem da parallel zum Spiel meist TS genutzt wird.
Ach ja, ein Kontra noch, beim Spielen sieht man selten bescheuert aus, siehe die Videos unten.

Potential hat das Ganze sicherlich nichtsdestotrotz:
In einem Testmatch gegen Klaus Widmann, dem aktuellen UT3-Weltmeister erzielte NIA-Entwickler Klaus Schuetten immerhin ein respektables Ergebnis von 5:12.
Ohne eine Ahnung von Shootern zu haben (sein Argument für NIA war er käme beim Spielen mit den vielen Tasten einfach nie zurecht o.O )

Wer sich gerne selbst ein Bild machen möchte, möge hier, hier und hier klicken.
Ein Interview gibts auch hier.