Ich hab hier mal zwei Ausschnitte aus den Musterlösungen unserer Prog. Professorin, und möchte mal dazu eure Meinung hören. Die Formatierung ist übrigens nicht verändert: #include<iostream.h> void paritaet_entf(char & z) {z = z&127;} ... .... double x1=1.2, y1=2.3, x2=1.0, y2=2.5; double w1,r1,w2,r2; if(polar(x1,y1,w1,r1)) cout<<"Winkel: "<<w1<<" Radius: "<<r1<<endl; else cout<<"Fehler";<<endl; if(polar(x1,y1,w2,r2)) cout<<"Winkel: "<<w2<<" Radius: "<<r2<<endl; else cout<<"Fehler";<<endl; ... Meiner Meinung nach ist das schon allein wegen der Formatierung schlichtweg Schrott
Ja, das ist kein Beispiel fuer guten Code. Die Zeile else cout<<"Fehler";<<endl; ist uebrigens ein Syntax-Fehler wegen des Semikolons hinter dem string. Das spricht nicht dafuer, dass du unveraendert copy&paste gemacht hast. Ich koennte noch viele weitere Punkte aufzaehlen, aber was erwartest du dir davon? Sinnvoller waere es vielleicht der Professorin eine E-Mail zu schreiben, wo du ihr sagst dass der Code sich bei dir nicht kompilieren laesst aus den und den Gruenden (iostream.h, etc.). Vielleicht bekommst du dann naechstes Mal besseren Code. Aber einfach hier im Forum fremden Code kritisieren zu lassen halte ich fuer ueberfluessig, denn davon hat niemand was.
> möchte mal dazu eure Meinung hören. Die Formatierung > ist übrigens nicht verändert: Grauenvoll. Unleserlich. Leider aber nicht ungewöhnlich für Leute, die C++ lehren. Außerdem wird ein Header benutzt, der veraltet ist, und zwar seit C++ vor nunmehr rund 9 Jahren zur ISO-Norm wurde. Er war nie Teil von ISO C++. > Ich koennte noch viele weitere Punkte aufzaehlen, aber was erwartest du > dir davon? Ich schätze, daß er sich nicht sicher ist und deshalb mal nachfragt. Immerhin ist er der Student, und Professoren sollten eigentlich mehr Ahnung von dem haben, was sie lehren, als ihre Studenten.
Naja ich wollt einfach mal ein paar Meinungen provozieren. Ich selber kann denk ich schon ganz gut programmieren. Da das was ich bissher von ihr bekommen und gehört hab einfach komplett meinen Vorstellungen von "gutem" Programmiren wiederspricht wollt ich einfach mal ein paar andere Meinungen bekommen um mir sicher zu sein dass ich das ganze nicht mit den "falschen" Vorstellungen betrachte. Aber ich denke die oberen zwei Beiträge beschreiben genau das was ich auch von dem Ganzen halte. Die Frau ist leider nicht zu überzeugen, deshalb bleib ich einfach der Vorlesung fern und lern das Zeug selber... Viele Grüße Der Student
> Ich selber kann denk ich schon ganz gut programmieren.
Obacht ;-) Zeig' mal was von dir...
Hab ja nicht behauptet dass ich gut bin, aber immerhin hab ich gemerkt dass das Müll is.... ;-) Aber warum nicht, zum meckern findet man ja immer was also hier mal ein beliebiger Ausschnitt aus dem aktuellen Projekt
1 | //------------------------------------------------------------------------------------------------//
|
2 | //Kopiert den RAM Buffer in den LCD-Speicher
|
3 | void LCD_Update(void){ |
4 | |
5 | unsigned char x; |
6 | unsigned char Line; |
7 | unsigned char *RAMptr = (unsigned char*)LCD_RAM_Buffer; |
8 | |
9 | //Alle Pages durchlaufen
|
10 | for(Line = 0; Line < LCD_Lines; Line++){ |
11 | |
12 | //Set Page Address
|
13 | LCD_WriteCMD(CMD_Set_Page | Line); |
14 | |
15 | //Set Column Address to 0
|
16 | LCD_WriteCMD(CMD_Set_Col_Lo | 0); |
17 | LCD_WriteCMD(CMD_Set_Col_Hi | 0); |
18 | |
19 | for(x = 0; x < LCD_Width; x++){ |
20 | LCD_WriteData(*RAMptr++); |
21 | }
|
22 | }
|
23 | }
|
jetzt kann ja jeder für sich entscheiden was ihm besser gefällt...
Nur eine Kleinigkeit: Ich gehe davon aus, dass das C-Dateien sind, denn bei C++ wuerde ich versuchen die Variablen so lokal wie moeglich zu deklarieren. Ich poste das nur, weil der Code im Originalpost anscheinend C++-Code darstellen sollte und die coding styles sich je nach Sprache schon unterscheiden.
> Nur eine Kleinigkeit: Ich gehe davon aus, dass das C-Dateien sind, denn > bei C++ wuerde ich versuchen die Variablen so lokal wie moeglich zu > deklarieren. Dieses Feature wurde bereits im letzten Jahrtausend auch in C eingeführt ;-)
Das is C Code für ein AVR, das find ich is C auch ganz gut aufgehoben. In der Vorlesung lernen wir C(++) am Rechner. C++ mag ja irgendwie schon seine Berechtigung haben, aber ich find die Sprache für "normale" Anwendungen unter Windows (DOS) etwas überholt...
Außerdem sind außer LCD_RAM_Buffer alles defines, und LCD_RAM_Buffer is ein ziemlich großes Array das im Stack nichts verloren hat und von verschiedenen Funktionen manipuliert werden können muss..
Dazu muss ich auch noch etwas klarstellen: >ist uebrigens ein Syntax-Fehler wegen des Semikolons hinter dem string. >Das spricht nicht dafuer, dass du unveraendert copy&paste gemacht hast. Ich hab WIRKLICH nur Copy&Paste gemacht, der Code wimmelt nur so von Syntaxfehlern, mich wundert dass da nur einer (zwei) drin ist...
Student wrote:
> jetzt kann ja jeder für sich entscheiden was ihm besser gefällt...
Keine ungarische Notation, schonmal gut.
Coding-Style nicht in Richtung BSD oder GNU mutiert, noch besser.
Wenn jetzt noch die Groß/Kleinschreibung für lokale/globale Variablen
und Defines und die Einrückungen konsistent wären...
Coding Styles haben ja unter anderem die Eigenschaft, dass sie dem Compiler egal sind, sogar sein müssen. Also warum darüber diskutieren ? Hilfsmittel zur P2P-Kommunikation, mag sein. Wer hier ein Dogma kreiert (blos nicht GNU etc), der bringt nicht mehr als seine persönliche Meinung rüber. Mein Rat: Baue korrekten Code, den Du auch noch nach einem Jahr selber nachvollziehen kannst! Das kann dann ein anderer auch, denn Du hast passende Kommentare dort platziert, wo es nötig ist...
Es geht aber nicht nur darum, dass du den Code verstehen kannst (wie du schon selber bemerkt hast), sondern auch dass andere den Code einfach erfassen können. Deshalb ist es sinnvoll, dass zumindest in einem Projekt ein einheitlicher Coding-Style verwendet wird. Das kann der K&R-Stil sein, das kann der ISO-C-Stil sein, das kann der GNU-Stil sein, aber bitte wenigstens einheitlich. Ein einheitlicher GNU-Stil ist mir immer noch tausendmal lieber (obwohl ich ihn nicht besonders mag) als ein Kraut-und-Rüben-Stil Marke Eigenbau ...
> Wer hier ein Dogma kreiert (blos nicht GNU etc), der > bringt nicht mehr als seine persönliche Meinung rüber. Hier sind Dogmen durchaus angebracht, weil die Althergebrachten sinnlos sind. 1. Man soll sich z.B. (GNU) an Emacs orientieren: "Insert extra parentheses so that Emacs will indent the code properly" Die Tools müssen das tun was der Programmierer will und nicht umgekehrt. 2. Klammern in einer neuen Zeile reduzieren den erfassbaren/überblickbaren Code und verringern damit letztendlich die Produktivität. 3. Einrückungen ala Tab = 8 damit keine Zusammenhänge mehr erkennbar sind und die uralt Apps damit klarkommen u.v.a.m.
Ich hatte in den letzten Monaten mit mehreren "Profis" (Lehreren und Lehrerinnen) zu tun, die viel Kohle für das Lehren von diversen Dingen bekamen (viel Kohle, weil "spezialisiert" und extern mit öffentlichn Geldern finanziert). Mein Fazit möchte ich hier aber nicht Preis geben, denn das würde sicherlich gelöscht. Daher wundern mich solche Codeausschnitte wie im EP nicht im Geringsten.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.