Programmierrichtlinen (Uni-Paderborn)
-
Gregor schrieb:
Optimizer hat in diesem Forum schon oft gezeigt, dass er weiß, wovon er spricht. Ich glaube, er hat hier bei vielen einen entsprechenden Ruf, da er auch schon vielen bei Problemen geholfen hat. Natürlich ist er schon deutlich weiter als ein Anfänger an der Uni. Und wenn er an einer FH studiert, dann ist das eher ein Zeichen dafür, dass ihm mehr in Richtung Softwaretechnik, Programmierung usw. in seiner Ausbildung begegnet als jemand, der an die Uni geht.
...ich gehe im Übrigen schon lange an die Uni. Ich weiß, was man hier lernt und was man nicht lernt. Und ich habe auch eine IMHO gute Vorstellung davon, inwiefern sich die Lehrinhalte von Uni und FH unterscheiden.
ich behaupte ja nicht, dass ich ich nichts von ihm lernen kann, sondern habe sogar explizit geschrieben, dass ich sicherlich vieles von ihm lernen kann auch oder grade im bezug aufs coden. Anderseits behauptet er, dass er nichts mehr von mir lernen könnten und mir damit in jedem erdenklichen Bereich überlegen sei. Das bezweifel ich nunmal sehr stark. Auch weil er den FH Weg eingeschlagen hat und Uni und FH inhalte sich doch deutlich unterscheiden.
Außerdem wäre ich ich grade in einem Bereich wie der Informatik vorsichtig zu schlussfolgern, dass man 10x mehr von einem Thema versteht, nur weil man schon 10x länger studiert, da dies doch ein Bereich ist, mit denen sich viele (und auch ich) privat viel beschäftigen und nicht nur ihr Wissen aus der Uni/FH beziehen.Vielleicht hat er ja sogar er ja sogar Recht und ist mir in jedem erdenklichen Gebiet überlegen, wie er behauptet und hat 10x mehr Wissen übers Programmieren als ich, dennoch wäre es aber ein Unverschämtheit einen sowas auf die Nase zu binden und damit zu argumentieren, dass er ja 10x mehr wisse als ich und daher er Recht haben müsse, zumal er es auch einfach nicht wissen kann. Deshalb ist seine Aussage imho ziemlich lächerlich
-
Vielleicht ist es bei so etwas hilfreich, sich noch einmal anzusehen, wie es angefangen hat mit Aussagen wie "schwer von Begriff" "Hirn einschalten" und der völligen Veräppelung der unsinnigen Idee, Funktionen aufzuteilen, mit der Antwort auf Gregor's Code. Nicht zu sprechen von dem Versuch, mir Grundlagen über das Programmieren nahezulegen.
Das vergleichsweise schwache Echo mit der Kernaussage "an deiner Stelle wäre ich lieber ein biiiisscchen zurückhaltender" musst du schon vertragen. Wenn du deswegen jetzt ein Jahrhundert lang schmollst, berührt mich das aber auch wenig. Überhaupt ist es nur eine Tatsachenbeschreibung die ich normal nur nicht erwähnt hätte. Sei ein harter Mann und sieh den Fakten ins Auge. Dass sich diese Skala auf jeden Bereich des Lebens oder der Informatik bezieht, hast übrigens du dazu erfunden.
-
bitte? ich hab einfach gesagt, dass du mehr darüber nachdenken sollst, was du postet bevor du postest, da ich weiß, das du sonst eigentlich nicht solche flüchtigkeitsfehler machst.. kein grund mich deshalb anzuflamen.. jedenfalls musste damit rechnen das ich zurückflame, wenn du es doch tust.. aber von mir aus können wir jetzt zum thema zurückkommen und den flamewar erstmal bis auf weiteres verschieben. >_<
btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..
-
Artchi schrieb:
Die meisten solcher Richtlinien sind bescheuert. Muß man ja einfach mal sagen. Genauso wie diese: "Alle Membervariablem müssen mit einem Unterstrich am Anfang versehen werden." Gibt es tatsächlich bei uns. Voll hohl!
// in irgend einer Klasse: public void foo(int a) { _b = _b + a; }Ohne Unterstrichvorschrift:
// in irgend einer Klasse: public void foo(int a) { b = b + a; }Kann mir jemand mal sagen, wo der Vorteil bei der ersten Variante sein soll? Wieso in Gottes Namen, soll ein Programmierer angeblich nicht an Variante 2 sehen können, das b eine Membervariable ist? Diesen Programmierer, der das nicht sieht, sollte nochmal über seinen Job nachdenken!
Zu diesem absolut bescheuerten Beispiel erwartest du sicher keine Antwort.
Wenn du generell Programmierrichtlinien "dieser Art" für Unsinn hälst solltest
du mal darüber nachdenken, das es nicht darum geht dem Compiler einen Gefallen
zu tun. Dem ist es egal ob dein Variablen X, rewrerwe oder KarlEgon heissen.
Es geht darum MENSCHEN die den Quellcode lesen (müssen) die Arbeit zu erleichtern.Und wenn du mal Projekte zu warten gehabt hättest die ein paar Jahre alt und nicht
10 sondern tausend Klassen enthalten, dann würdest du dich nicht nur
hin und wieder über ein paar (sinnvolle) Kommentare sondern auch über jede
sonstige Unterstützung freuen, und die "Kennzeichnung von Membervariablen"
gehört nach meiner Erfahrung dazu.
-
Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.
-
Walli schrieb:
Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.
Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.
-
Redhead schrieb:
Walli schrieb:
Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.
Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.
Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.
-
Walli schrieb:
Redhead schrieb:
Walli schrieb:
Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.
Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.
Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.
Woran erkennt man das denn bei dir. Ich würde gern mal ein Beispiel dazu sehen.
Aber bitte keinen 5- oder 10-Zeiler, oder wie von Artchi so einen genialen Einzeiler.
-
life schrieb:
btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..
Ich habe doch gar keine Probleme. Die Übertreibungen bringen genau auf den Punkt, was es zu sagen gibt. Irgendwo hab ich es ausgeschrieben, dass bei kürzeren Funktionen automatisch die Tendenz besteht, die Variablen am Anfang zu definieren. Das kann jetzt jeder glauben oder nicht. Aber natürlich kann man das auch veranschaulichen. Mach eine Funktion bestehend aus zwei Anweisungen, da muss die Variablendefinition die erste sein. Für etwas längere Funktion gilt das noch fast genauso.
Da du ja anscheinend die Übertreibung als solche erkannt hast, hättest du sie nicht veräppeln brauchen sondern stattdessen überlegen können, wo der wahre Kern liegt. Du hast doch nicht wirklich angenommen, dass ich strikt gegen jede Funktion bin, die länger ist als 2 Zeilen.
-
DEvent schrieb:
das ist eher bei zweideutigkeit:
class Blaaa { int foo; void machirgendwas(int foo) { foo = foo; } }in Eclipse gibts eine Compiler-Warnung und der Code wird Gelb unterstrichen. Keine Ahnung was eine C++ IDE da macht.
Aber ein Präfix für Attribute ist total altmodisch , weil die modernen IDEs Klassenatribute anders Färben als lokale Variablen.Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?
class Blaaa { int foo; void machirgendwas(int foo) { this->foo = foo; // Zweideutischkeit nicht mehr möglich } }Warum ich immernoch Membervariablen kennzeichnen muß, ist mir immer noch nicht klar.
-
Optimizer schrieb:
life schrieb:
btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..
Ich habe doch gar keine Probleme. Die Übertreibungen bringen genau auf den Punkt, was es zu sagen gibt. Irgendwo hab ich es ausgeschrieben, dass bei kürzeren Funktionen automatisch die Tendenz besteht, die Variablen am Anfang zu definieren. Das kann jetzt jeder glauben oder nicht. Aber natürlich kann man das auch veranschaulichen. Mach eine Funktion bestehend aus zwei Anweisungen, da muss die Variablendefinition die erste sein. Für etwas längere Funktion gilt das noch fast genauso.
Da du ja anscheinend die Übertreibung als solche erkannt hast, hättest du sie nicht veräppeln brauchen sondern stattdessen überlegen können, wo der wahre Kern liegt. Du hast doch nicht wirklich angenommen, dass ich strikt gegen jede Funktion bin, die länger ist als 2 Zeilen.
hättest du aufmerksam gelesen, wäre dir aufgefallen, dass ich dir schon attestiert habe, dass es einen wahren kern hat, obgleich es übertrieben war.
-
Redhead schrieb:
Wenn du generell Programmierrichtlinien "dieser Art" für Unsinn hälst solltest
du mal darüber nachdenken, das es nicht darum geht dem Compiler einen Gefallen
zu tun. Dem ist es egal ob dein Variablen X, rewrerwe oder KarlEgon heissen.
Es geht darum MENSCHEN die den Quellcode lesen (müssen) die Arbeit zu erleichtern.Und wenn du mal Projekte zu warten gehabt hättest die ein paar Jahre alt und nicht
10 sondern tausend Klassen enthalten, dann würdest du dich nicht nur
hin und wieder über ein paar (sinnvolle) Kommentare sondern auch über jede
sonstige Unterstützung freuen, und die "Kennzeichnung von Membervariablen"
gehört nach meiner Erfahrung dazu.Gaaanz ruhig brauner!
Woher willst du wissen, ob und in welchen Projekten ich noch nicht gearbeitet habe? Hab zwei Jahre lang in einem Projekt mit 10 bis 15 Leuten gearbeitet, das Packet mit Java-Archiven ist knapp 100 MByte groß. Also nichts kleines. Ansonst belaufen sich die Projekte bei 3 bis 6 Leuten (schwankt immer, je nach Anforderungen zum aktuellen Zeitpunkt). Bin also kein Greenhorn nach 7 Jahren Berufserfahrung.Hab auch 1 Jahr das Spiel Heroes of Might & Magic III von PC auf Dreamcast portiert. Hab den Code auch ohne Namenskonventionen verstanden.
Und nein, in keinem Projekt haben wir bisher solche Namenskonventionen gehabt und auch nicht gebraucht. Auch wenn immer Leute von "Aussen" uns solche Konventionen aufzwingen wollen.
-
Hi Artchi,
Es gilt ja bekanntlich
Geht nicht, gibts nicht.
Ich bezweifle nicht das du deine und andere Quellcodes auch ohne solche
Restriktionen "geregelt" bekommst. Meine Erfahrung zeigt das die Einhaltung
von gewissen Regeln mir das Lesen fremder Quellcodes oft erleichtert hat.
Meine Kollegen, auch in früheren Firmen, sind/waren meist sehr begeistert wenn
spezielle Kollegen ihren "privaten" Coding Styles gepflegt haben, unabhängig
vom Ergebnis ihrer Programmierung.
Und daher gehöre ich, wenn Projektleiter bin, zu denen die auf Einhaltung der
von dir ungeliebten Richtlinien bestehen.
-
Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?
naja stell dir vor, du arbeitest seit 12 Stunden, bis Nachst um 4 Uhr, uns machst sowas ( mein Beispiel ). Jetzt stellen wir uns vor, dieser armer Programmierer hat die billigste IDE die es gibt. Dem Compiler ist es scheiss egal ob der Programmierer so ein scheiss macht wie foo = foo.
Was kommt? der armer und überarbeiter Programmierer sucht noch die ganze Nacht bis zum Morgengrauen nach einem Fehler.
Mit Zweideutigkeit meinte ich, das es nicht ersichtlich ist ob foo eine Membervariable ist oder nicht.
Und jetzt sag blos, du weist Membervariablen immer mit this->xxxx zu.
PS: das mit den Unterschrichten ist brutal, schonmal den STL-Code gelesen?Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.
-
Ponto schrieb:
otze schrieb:
hats in C++ auch nicht. Die Compiler sind da schon intelligent genug
Das glaube ich nicht:
class Obj { public: Obj() { sock.open("127.0.0.1"); } ~Obj() { sock.close(); } void write(char const * str) { sock.write(str); } private: SocketObj sock; }; void func(int value) { Obj ob; if (value > 10) return; ob.write(value); }ich wette einfach mal mit dir, dass die compiler erkennen können, dass "ob" nichts mit "value" zu tun hat, und so die beiden zeilen getauscht werden können.
Helium schrieb:
Dann ist dein Compiler kaputt. Er sollte schon das machen, was du ihm sagst.
bei non pods stimm ich dir zu. bei pods trau ich den compilern aber alles zu
-
DEvent schrieb:
Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?
naja stell dir vor, du arbeitest seit 12 Stunden, bis Nachst um 4 Uhr, uns machst sowas ( mein Beispiel ). Jetzt stellen wir uns vor, dieser armer Programmierer hat die billigste IDE die es gibt. Dem Compiler ist es scheiss egal ob der Programmierer so ein scheiss macht wie foo = foo.
Dazu kommt erschwerend hinzu, dass es draußen regnet und die Lochkarten gerade aufgebraucht sind.
Redhead schrieb:
Woran erkennt man das denn bei dir. Ich würde gern mal ein Beispiel dazu sehen.
Aber bitte keinen 5- oder 10-Zeiler, oder wie von Artchi so einen genialen Einzeiler.Mehr als 10 Zeilen wirst du bei mir im nicht-GUI-Code eher selten antreffen (Leerzeilen und eventuelle Kommentare nicht mitgezählt).
-
otze schrieb:
ich wette einfach mal mit dir, dass die compiler erkennen können, dass "ob" nichts mit "value" zu tun hat, und so die beiden zeilen getauscht werden können.
Der Compiler darf auf keinen Fall den Aufbau der Socketverbindung unterschlagen. Das hat ja sichtbare Auswirkungen. Hier kann nur der Mensch entscheiden, ob das in jedem Fall gemacht werden soll, oder nicht. Meistens ist eine Verbindung, die sofort wieder geschlossen wird, sinnlos.