Was sind eure lieblingsvariablen [Archiv]

Gast

2008-02-28, 17:10:45

Also trennt ihr eure Variablen lieber mit underscores oder schreibt die zusammen mit Großbuchstaben.

Ich tendiere eher dazu alles klein zu schreiben und dann, wenn nötig mit underscores zu trennen. Natürlich sind kurze Variablennamen, die auch etwas aussagen immer besser, das ist keine Frage ;)

Groß-/Kleinschreibung
Membervariablen beginnen mit kleinem "m", gefolgt von einem großen Buchstaben.

Abkürzungen gewöhnt man sich nach einige Zeit ab, da sie nach spätestens einem Jahr Arbeit an einem Modul auch für einen selbst garkeinen Sinn mehr ergeben. Falls man doch welche verwendet, werden die Abkürzungen durchgehend groß geschrieben.

rotalever

2008-02-28, 17:13:53

Ja das mit den Abkürzungen hatte ich auch mal festgestellt ;). Seitdem nie wieder.

Am besten lesbar sind IMO Namen mit Bindestrichen, die gibt es aber nur in Sprachen ohne binäres -.

example-variable-number-3
In welcher Sprache geht denn sowas?

Monger

2008-02-28, 17:16:28

Ich finde die Höckernotation so wie Java sie verwendet auch am angenehmsten.
Sonderzeichen wie _ oder - stören imho fürchterlich den Textfluss. Man muss erst gedanklich solche Füllzeichen ausblenden um den eigentlichen Text zu sehen.

Trap

2008-02-28, 17:17:51

Bindestriche in Namen gehen in Scheme, Common Lisp und anderen lispartigen Sprachen. Eventuell gibt es noch mehr Sprachen (nur " - " als Minus lesen reicht um solche Identifier zu erlauben), aber ich kenne keine.
Man muss erst gedanklich solche Füllzeichen ausblenden um den eigentlichen Text zu sehen.
Das ist bei Bindestrichen weit weniger ausgeprägt (bei _ stört es micht auch sehr), die werden auch in normalen Text in genau der Funktion benutzt. Ich hab bei Gemischtschreibung immer Probleme die Wortanfänge zu sehen.

Gnafoo

2008-02-28, 17:17:53

Ich mag die Konventionen von .NET eigentlich ganz gerne:
http://msdn2.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx

Soll heißen: Camel Case.

Aber ich kann mit beiden Versionen leben. Wichtiger ist, dass es in einem Projekt einheitlich ist.

Abnaxos

2008-02-28, 17:22:43

Als Java-Entwickler bevorzuge ich natürlich camelCase. :)

Am besten lesbar sind IMO Namen mit Bindestrichen, die gibt es aber nur in Sprachen ohne binäres -.

example-variable-number-3
In welcher Sprache geht denn sowas?

Beispielsweise in Lisp, dort ist es sogar Konvention, seine Bezeichner so zu schreiben (jedenfalls in Emacs-Lisp, dem einzigen Lisp-Dialekt, mit dem ich bisher gearbeitet habe). Und ja, das finde ich eigentlich auch das lesbarste, aber in den meisten Sprachen führt das halt nunmal zu einem Konflikt mit diversen Operatoren ...

Pinoccio

2008-02-28, 18:43:57

Und ausgerechnet Variablen sind ausgeschlossen (except), wo's doch gerade darum geht. :tongue:Hm, stimmt, der zitierte Teil ist falsch, aber trotzdem werden in Java i.d.R. Variablennamen klein mit Großbuchstaben bei Wortanfangen mittendrin geschrieben.

mfg

noid

2008-02-28, 19:03:14

interesanter ist doch: mit präfix für Typ oder nicht (p für pointer etc.)

Nvidia5

2008-02-28, 19:14:31

hmm, eigentlich x,y,z und a,b,c.
Sonst[x]CamelCase

MooN

2008-02-28, 19:22:10

hmm, eigentlich x,y,z und a,b,c.

Bei mir auch, damit stelle ich Leute, die meinen Code lesen möchte, ständig vor massive Probleme.
"Wofür steht n12 jetzt wieder?!"

Sprechende Variablen sind ja an und für sich was feines, aber mir beim Scripten meistens zu aufwändig zu schreiben.

noid

2008-02-28, 19:24:29

Bei mir auch, damit stelle ich Leute, die meinen Code lesen möchte, ständig vor massive Probleme.
"Wofür steht n12 jetzt wieder?!"

Sprechende Variablen sind ja an und für sich was feines, aber mir beim Scripten meistens zu aufwändig zu schreiben.

so Geraffel sortieren wir gerade aus, kann später keiner mehr lesen.

Trap

2008-02-28, 19:46:44

Variablen ohne sprechende Namen benutz ich meist nur als Schleifenvariable (i,j,k) oder für Variablen die nur sehr kleinen Gültigkeitsraum haben (5 Zeilen oder so). Das bleibt überschaubar, sowohl beim Bedeutung merken als auch beim Nachgucken.

Bei allem nicht-lokalen ist klar, dass man es sprechend benennen muss.

Coda

2008-02-28, 19:48:56

PHuV

2008-02-28, 19:50:14

ich mache gerne sprechende und ausführliche Variablennamen, nichts ist schlimmen, als wenn man seinen alten Code nicht mehr blickt. :redface:

The_Invisible

2008-02-28, 20:46:27

wori

2008-02-28, 21:20:45

Ungarische Notation

Kenny1702

2008-02-28, 21:33:01

i ist wohl meine Lieblingsvariable. Bei jeder einfachen for-Schleife taucht die auf.

Früher habe ich meist auch nur a,b,c,... benutzt, mittlerweile bin ich auf kurze und verständliche Variablen geschwenkt.

wori

2008-02-28, 21:38:05

Ja i finde ich auch Klasse genau wie j. Im alten Fortran gabs so hübsche Platzhalter.

ne0

2008-02-28, 21:42:43

i ist wohl meine Lieblingsvariable. Bei jeder einfachen for-Schleife taucht die auf.

warum benutzt man bei for schleifen generell eigendlich das i ? hat das nen speziellen grund warum nicht das o? wäre mal interessant zu erfahren wie sich sowas entwickelt/gebildet hat.

Xanatos

2008-02-28, 22:04:10

i = Integer

noid

2008-02-28, 22:13:13

ich habe bei php lange zeit präfixe für deren sichtbarkeit verwendet zb __ für private, _ für protected und normal für public, gottseidank ist das jetzt nicht mehr nötig.

darum verwende ich eigentlich bei jeder sprache gerne _, bei Java und C# wird mir jetzt aber CamelCase immer lieber. variablennamen nehme ich immer was mir auf die schnelle einfällt, ich verbrate sonst irgendwie immer die hälfte der zeit mit dem namen.

ein functionsname zb in python: astrtvarwoc = "append string to var without copy", mein kollege musste da erst mal schmunzeln.

mfg

sasquatsch = static array string qonverted from unsigned ascii type string char huge....
edit: nicht richtig, aber sowas mit 8 zeichen habe ich auch schon gesehen... :uup:

X-(
Sorry, aber deine Funktion sollte AppendStringToVarWoCopy heißen... ehrlich.
Ich hab hier Code, da gibt es Variablen G13- G19 und dann so eine Kommentar wie "//declaring G15"
oder "a++ //incrementing variable"
X-(
.oO(sagte ich schon, dass wir alles neu implementieren?)

Gast

2008-02-28, 22:23:14

i = Integer
Kommt wohl eher von iterieren.
ein functionsname zb in python: astrtvarwoc = "append string to var without copy", mein kollege musste da erst mal schmunzeln.
In nem Einstellungstest bedeutet das ein KO, in der Probezeit verstärkte Beobachtung und immer egal bei wem ein Donnerwetter.

Wer darüber schmunzelt, dem ist die Codequalität vollkommen egal.

noid

2008-02-28, 22:32:06

Kommt wohl eher von iterieren.

In nem Einstellungstest bedeutet das ein KO, in der Probezeit verstärkte Beobachtung und immer egal bei wem ein Donnerwetter.

Wer darüber schmunzelt, dem ist die Codequalität vollkommen egal.

Führt sicherlich dazu:
http://www.osnews.com/images/comics/wtfm.jpg

Gast

2008-02-28, 22:36:49

Führt sicherlich dazu:
http://www.osnews.com/images/comics/wtfm.jpg
GEIL!
Danke. :massa:

Das landet in DIN A3 an der Bürotür. :cool:

noid

2008-02-28, 22:38:19

GEIL!
Danke. :massa:

Das landet in DIN A3 an der Bürotür. :cool:

Lustige Bilder Thread war's auch schon...
;)
Auch A3 X-D

Coda

2008-02-28, 22:47:20

i = Integer
Eher index

Führt sicherlich dazu:
http://www.osnews.com/images/comics/wtfm.jpg
Wie wahr, wie wahr...

RMC

2008-02-28, 23:11:43

Was mich mal interessiert, welche Variablennamen mögt ihr lieber, so etwas wie
aaaaa_bbbbbb_ccccccc = 1;
oder
aaaaaBbbbbbCcccccc = 1

Ich hab längere Zeit Ersteres verwendet (war irgendwie überzeugt davon, kA wieso), seit den Coding Conventions am Arbeitsplatz hat natürlich die zweite Variante vermehrt Einzug in Privatprojekte gefunden.

Übercoda

2008-02-29, 03:36:57

Ich erstelle von den Variablen MD5 Fingerprints und verwende dann diese als Referenz auf die Variablen.

So erspare ich mir Underscores und das Schreiben von Unterstrichen.

Gast

2008-02-29, 07:51:31

Ich mixe...

Member in Camel-Case mit einem kleinem "m" davor, lokale Variablen in Kleinschreibung und die Wörter mit "_" getrennt.

rotalever

2008-02-29, 13:01:46

Ich erstelle von den Variablen MD5 Fingerprints und verwende dann diese als Referenz auf die Variablen.

So erspare ich mir Underscores und das Schreiben von Unterstrichen.
Hmm. Darauf war ich irgendwie noch gar nicht gekommen.

Hab jetzt mal testweise ein Programm so umgewandelt. Sieht jetzt sehr einheitlich aus. Der kompilierte auch, aber dann gab es Fehler beim Ausführen. Ich vermute das liegt daran, dass das Programm so viele verschiedene Variablen benutzt, dass Kollisionen zwischen den Hashes entstanden sind. Also ich finde die Methode aufgrund dieses Problems nicht gut. Das ist einfach eine zu hohe Fehlerquelle.

Gast

2008-02-29, 13:15:55

Nimm besser SHA-512, um auf der sicheren Seite zu sein; das macht Dein Programm dann auch für die Zukunft erweiterbar, man kann ja nicht davon ausgehen, daß man allein an dieser Software arbeitet. So geht auch zukünftigen Entwicklern nicht die Möglichkeit für Variablen aus. Für namespace reichen aber IMHO noch SHA-384 Hashes aus. Für Dateinamen und Enum Typen nehme ich der besseren Unterscheidung willen aber Whirlpool Hashes - das sollte man aber nicht vergessen sorgfältig zu kommentieren.

Ectoplasma

2008-02-29, 17:19:09

Ich verwende Klein/Großschreibung. Es gibt keine technische Notation wie ein m_ bei Memebervaribalen. Ich bin der Meinung, dass das die Symantik bzw. deren Lesbarkeit versaut. In größeren Firmenprojekten im Java-Umfeld, wird auch nur die Klein/Großschreibung von Variablen verwendet.

astro

2008-03-03, 12:35:49

kamelNotationRocktBeimCoden ;)

FlashBFE

2008-03-03, 15:36:22

Der_Donnervogel

2008-03-03, 16:53:16

i = Integer
Kommt wohl eher von iterieren.
Eher index
Ich denke auch, dass es von Index kommt. Ich vermute mal das wird aus der Mathematik übernommen worden sein. Dort wird ja auch z.B. bei Summen der Summatationsindex mit i bezeichnet, bzw. weitere Indexe dann mit j und k.
Noch so eine wichtige Frage in dem Zusammenhang:
Wer von euch schreibt deutschen code? :)
Die Frage kann man nicht so einfach beantworten. Bei privaten Projekten immer deutsch, ansonsten englisch.

@Topic
Eigentlich verwende ich eine Mischung. Membervariablen beginnen mit m_ aber ansonsten wird fast nur mit Groß/Kleinschreibung gearbeitet. Ausnahmen gibt es nur bei sehr langen Variablennamen, wo es die Lesbarkeit erhöht. So etwas kommt aber fast nie vor.

rotalever

2008-03-03, 17:16:08

Also ich mache nur Englisch, inklusive Kommentare, außer wenn es ausdrücklich anders von anderen gewünscht wird. Wer weiß, wenn man ein Programm(-teil) doch veröffentlichen will, dann muss man nichts mehr ändern.

Novox

2008-03-03, 21:28:36

Ich denke auch, dass es von Index kommt. Ich vermute mal das wird aus der Mathematik übernommen worden sein. Dort wird ja auch z.B. bei Summen der Summatationsindex mit i bezeichnet, bzw. weitere Indexe dann mit j und k.

Vermutlich; möglicherweise auch indirekt über Fortran, das sich selbst wiederum an der in der Mathematik üblichen Notation orientiert. Bis mindestens FORTRAN 77 (oder gar Fortran 90/95?) ist eine Variable "i" implizit ein Integer, sofern man es nicht explizit anders festlegt.

Xanatos

2008-03-04, 00:18:12

Noch so eine wichtige Frage in dem Zusammenhang:
Wer von euch schreibt deutschen code? :)

Zur Threadfrage: Das was die .net-Konvention "pascal" nennt. Also Camel mit großem Variablenanfangsbuchstaben.

Präfixe mag ich nicht, das erhöht mir zu sehr die Tipparbeit, da ich schon sehr an das Intellisense Tipp-Tab gewöhnt bin. Wenn überhaupt benutze ich Suffixe, vor allem bei ArrayxyzA() und TextBoxxyzTB.
Englisch ftw! Deutscher Code sieht fuer mich einfach "komisch" aus...Dazu muss man aber auch sagen, dass ich in England studiere, also wenn ich Deutsch code wuerde, waere das sehr seltsam fuer den Dozenten;)

Trap

2008-03-04, 02:24:43

In Sprachen mit Unicodeunterstützung bietet sich auch andere Alphabete an:

-für wissenschaftlichen Code:
double λ = ρ(ψ*ω);
-für hacker-tools:
int Хир=Гцс();
-für mehr Aufmerksamkeit beim CIA:
char غسچ = ڳ؂();
-oder einfach nur zum nett aussehen:
return देवनागरी();

Da Code sowieso öfter gelesen als geschrieben wird, ist die umständliche Eingabe ja kein echter Hinderungsgrund ;)

Xanatos

2008-03-04, 07:25:35

Wer solche Vars beruflich benutzt, gehoert gefeuert. Trotzdem ganz lustig:D

Grestorn

2008-03-04, 07:46:35

Und ganz schlimm ist auch Hungarian Notation. Das kann ich gar nicht sehen und vermisse es auch nie.

QfT!!!

Nicht ganz OnT, aber auch sehr interessant...

Steht ihr auf "Kerningham/Ritchie" (C-Gurus) Style-Formatierung? Also so:

void function(int a, int b) {
Klasse blubber;
int x,y,z;
if(a == b){
while(i != 0){
doSomething();
}
}
}
Oder seit Ihr ein Freund von modernen Monitoren & Oberflächen, bei denen die Zahl der Textzeilen nicht mehr so sehr limitiert ist und man der Spezies der Leerzeilen wieder etwas Raum geben kann:

void function(int a, int b)
{
Klasse blubber;
int x;
int y;
int z;

if(a == b)
{
while(i != 0)
{
doSomething();
}
}
}

Da sollte man vielleicht mal ne eigene Umfrage machen :)

Wenn ich K/R sehe drücke ich zu allererst mal Ctrl-Shift-F ("Format all" in Eclipse) damit ich kein Augenkrebs kriege...

astro

2008-03-04, 07:59:10

Wenn ich K/R sehe drücke ich als allererstes Mal Ctrl-Shift-F (Format all in Eclipse) damit ich kein Augenkrebs kriege...
Amen.
Wir arbeiten ja nicht mehr an 14"-Monitoren, mein Code soll gut lesbar sein. Da schadet die ein oder andere Leerzeile nicht ;)

Variablen und Kommentare sind bei mir i.d.R. komplett auf englisch.

Gast

2008-03-04, 07:59:52

Letzteres, da kann man schön die Blöcke überblicken; sieht IMHO einfach aufgeräumter aus.

Ich setze zwar noch zwischen Ausrücke in Klammern (Parameter, Signaturen) an den Klammern jeweils Leerzeichen, aber sonst eben das Verschwenderische.

noid

2008-03-04, 09:40:55

QfT!!!

Nicht ganz OnT, aber auch sehr interessant...

Steht ihr auf "Kerningham/Ritchie" (C-Gurus) Style-Formatierung? Also so:

void function(int a, int b) {
Klasse blubber;
int x,y,z;
if(a == b){
while(i != 0){
doSomething();
}
}
}
Oder seit Ihr ein Freund von modernen Monitoren & Oberflächen, bei denen die Zahl der Textzeilen nicht mehr so sehr limitiert ist und man der Spezies der Leerzeilen wieder etwas Raum geben kann:

void function(int a, int b)
{
Klasse blubber;
int x;
int y;
int z;

if(a == b)
{
while(i != 0)
{
doSomething();
}
}
}

Da sollte man vielleicht mal ne eigene Umfrage machen :)

Wenn ich K/R sehe drücke ich zu allererst mal Ctrl-Shift-F ("Format all" in Eclipse) damit ich kein Augenkrebs kriege...

Unteres ist mir als BSD-Style bekannt, wird auch ausschliesslich so von mir verwendet.
Ich hab den Code, den ich geerbt habe erstmal komplett umformatiert, damit man eben die Blöcke etc wieder richtig sieht. Das war ja nichtmal K/R-Artig.

Xanatos

2008-03-04, 10:11:02

Bei mir ne Mischung aus beiden, Leerzeilen gerne, aber { kommen bei mir ans Ende der Zeile.

SgtTynis

2008-03-04, 11:45:44

K/R find ich furchtbar. Einziger Fall in dem die { auf der Zeile bleiben darf sind die Einzeiler im C# wie z.B. get { return irgendwas; }.

Ectoplasma

2008-03-04, 11:54:27

K/R find ich furchtbar. Einziger Fall in dem die { auf der Zeile bleiben darf sind die Einzeiler im C# wie z.B. get { return irgendwas; }.

Im Java-Umfeld geht man auch mehr dazu über den K/R Style zu verwenden. Ist halt nur eine Gewöhnungsfrage. Wichtig ist aber, dass alle in einem Team die gleichen Codingstyles verwenden.

Wenn sich einer nicht daran hält, dann -> Arschtritt ... und ihm erzählen dass der Code sowieso durch einen Autoformatter geschickt wird ;)

Kenny1702

2008-03-04, 13:54:49

QfT!!!

Nicht ganz OnT, aber auch sehr interessant...

Steht ihr auf "Kerningham/Ritchie" (C-Gurus) Style-Formatierung? Also so:

void function(int a, int b) {
Klasse blubber;
int x,y,z;
if(a == b){
while(i != 0){
doSomething();
}
}
}

...

Wenn ich K/R sehe drücke ich zu allererst mal Ctrl-Shift-F ("Format all" in Eclipse) damit ich kein Augenkrebs kriege...
Ich weiß gar nicht, was du hast, K/R ist doch ganz in Ordnung. Es gibt ja auch Mischmasch-Formen, schau dir z.B. den Quake3-Quellcode an. Da bekommt jede Variable ihre eigene Zeile, die Klammerung ist jedoch wie bei K/R.

rotalever

2008-03-04, 14:11:28

Also ich mach auch das untere. Ist definitv besser lesbar. Allerdings mach ich vor einer Klammer immer ein Leerzeichen, also z.b.:

if (var == get_true (true == true))
{
return true;
}

Grestorn

2008-03-04, 14:20:34

Wie man die Spaces setzt ist sicher Geschmacksfrage. Ich habe kein Problem wenn einer mehr oder weniger nutzt als ich (nur ganz ohne Spaces zu arbeiten macht komplexe Ausdrücke oft schwer lesbar - ich setze persönlich Spaces am liebsten um logisch zusammengehörendes auch optisch abzusetzen).

Was mich aber echt ankotzt ist superkompakter K/R Code. Variablen so kryptisch und kurz wie möglich, den Code so kurz und knapp wie es nur geht und mit allen Tricks versehen, die man sich denken kann.

Man sieht das sehr extrem oft, gerade bei systemnaher Software und im OOS Bereich. Ich behaupte: Dort wo besonders viele "Coder" hocken - Leute die wirklich viel können, aber sich auch unheimlich viel darauf einbilden. Nach dem Motto: wer den Code nicht lesen kann, der hat es auch gar nicht verdient.

Da ist nur noch ein sehr kleiner Schritt zum Obfuscated Code (http://en.wikipedia.org/wiki/Obfuscated_code) ...

Übrigens:

if (var == get_true (true == true))
{
return true;
}

finde ich nicht gut lesbar. Man muss zweimal hinsehen um zu kapieren, was da steht.

Ich würde es so formatieren:

if( var == get_true(true == true) )
{
return true;
}

Ein Space nach if - meinetwegen. Aber ganz bestimmte nicht für die Parameterliste bei einem Methodenruf. Das sieht optisch so aus, als gehörte die Klammer samt Parameter gar nicht zu dem Aufruf.

Man schreib in der Mathematik ja auch nicht "f (x)" sondern "f(x)"

Hucke

2008-03-04, 15:36:51

ich mache gerne sprechende und ausführliche Variablennamen, nichts ist schlimmen, als wenn man seinen alten Code nicht mehr blickt. :redface:

So siehts aus. Und bevorzugen tu ich dabei auch camelCase.

Coda

2008-03-04, 15:56:28

Steht ihr auf "Kerningham/Ritchie" (C-Gurus) Style-Formatierung?
Ja tue ich. Ich spare jede Zeile (http://www.mental-asylum.de/files2/Terrain.cpp). Und zwar auf 8pt Fonts und nem 1200 Zeilen Monitor.

Ich produziere genug Code, dass sich das immer noch lohnt.

Chris Lux

2008-03-04, 17:45:53

Ich produziere genug Code, dass sich das immer noch lohnt.
sehe ich ähnlich. nur bei klassen- und funktionsdefinitionen kommt die { auf eine neue zeile, sonst immer auf die gleiche.

ich bevorzuge auch die _ variante... wie es auch von boost genutzt wird. member variablen bekommen bei mir auch noch einen _ an den anfang. aber das ist persönliche vorliebe von mir...

edit: sehe gerade, dass du es genau so machst wie ich es meine ;)

DavChrFen

2008-03-04, 18:59:58

noid

2008-03-04, 19:06:54

RMC

2008-03-04, 19:20:29

Also ich benutze meist als Abkürzungen den jeweils ersten Buchstaben. Und damit das lesbar bleibt, schreibe ich, wenn ich die Variable das erste mal vergebe, kommentiert dahinter, was diese Abkürzung ausgeschrieben ist.
z.B.:
int mev; //MeineErsteVariable

Find ich auch nicht gut, denn wenn sich andere deinen Code anschauen und solche Abkürzungen finden kennt sich kein Schwein mehr aus. Und wenn du nach ein paar Wochen wieder reinschaust weißt du es selbst nicht mehr, ich spreche aus Erfahrung ;)

Da tu ich mir lieber die Arbeit an und schreibe die Namen aus. So bleibt alles leserlich.

Für die Lesbarkeit ist bei mir auch wichtig, dass {}- Klammer in eine neue Zeile kommen. Man sieht auf den ersten Blick wo ein Block zu Ende ist.

Und neue Zeilen für Variablen, Funktionsparameteraufzählung (falls zu lang), if-Abfragen etc. schadet niemandem.

Sparen in jeglicher Form ist in sinnlos, man ärgert sich später nur drüber.

Ich seh grad...

if(node->aabb.min_v[0] <= affected_rect_right && node->aabb.max_v[0] >= affected_rect_left &&
node->aabb.min_v[2] <= affected_rect_bottom && node->aabb.max_v[2] >= affected_rect_top)
{
if(node->is_leaf) {
TerrainLeaf *leaf = (TerrainLeaf*)node;
leaf->layers.clear();

unsigned int last_opaque_layer = 0;
for(unsigned int i=0;i<layers.size();++i) {
bool is_opaque = true;
unsigned char *layer_alphas = layers[i].GetLayerAlphas();

for(unsigned int y=0;y<=chunk_size;++y) {
for(unsigned int x=0;x<=chunk_size;++x) {
unsigned int heightmap_offset = x+leaf->chunk_pos[0] + (y+leaf->chunk_pos[1])*heightmap_width;
if(layer_alphas[heightmap_offset] != 255) {
is_opaque = false;
goto early_out_opacity;
}
}
}

Da hauts man Beidl auf d'Seitn. Ist ja gräßlich

Außerdem habe ich mir folgendes angewöhnt:

if(!empty)
{
....
}

wird zu:

if(empty)
return;

Chris Lux

2008-03-04, 20:05:41

Da hauts man Beidl auf d'Seitn. Ist ja gräßlich

ich glaub das sieht im browser nur so grausam aus, weil er tabs benutzt.

da könnte man auch eine umfrage machen: auf was steht eure tabsize?
meine ist 4 und ich lasse tabs durch genau diese anzahl an spaces ersetzen.

Außerdem habe ich mir folgendes angewöhnt:

if(!empty)
{
....
}

wird zu:

if(empty)
return;

hmm, das mag ich wiederum gar nicht. ich mag es klarer, was passieren soll im fall von !empty und kann später einfach den empty fall abhandeln ohne vielleicht das return am anfang zu übersehen.

Coda

2008-03-04, 20:14:47

Tabsize ist 4 ja. Das ist nicht wirklich so breit.

Für die Lesbarkeit ist bei mir auch wichtig, dass {}- Klammer in eine neue Zeile kommen. Man sieht auf den ersten Blick wo ein Block zu Ende ist.
Hab ich auch mal gedacht. Reine Gewohnheit. Man erkennt die Blöcke auch an den keywords.

rotalever

2008-03-04, 20:42:52

Also ich hab den Editor auch auf 4 eingestellt, und lasse alle Tabs durch Leerzeichen ersetzen. Leerzeichen sind genausogut und wenn man ab und zu was mit python macht, sollte man eh lieber nur Leerzeichen nehmen. Wenn ich mir irgendwoher mal was paste mache ich am Anfang erst einmal ein find & replace.

Nasenbaer

2008-03-04, 20:51:50

Ob abc_def oder abcDef ist mir persönlich eigentlich egal bei fremdem Code, auch wenn ich ersteres persönlich bevorzuge und camelCase nur für Memberfunktionen einsetzen um es besser unterschieden zu können. Viel wichtiger sind gute Variablennamen.

Und ganz schlimm ist auch Hungarian Notation. Das kann ich gar nicht sehen und vermisse es auch nie.
Was hast du gegen uuluwchCounter? *ggg*
Ne aber im Ernst wenn man sie sparsam einsetzt finde ich sie durchaus brauchbar. Also iCounter oder fColor, mMember schreib ich eigentlich immer so. Sicher mit ner ordentlichen IDE bekommt man heutzutage die Typ auch direkt mitgeteilt aber hat sich bei mir irgendwie so eingewöhnt.

Ansonsten auch
[x] Binnenmajuskel :biggrin: (der deutsche Begriff für CamelCase)

RMC

2008-03-04, 21:13:58

ich glaub das sieht im browser nur so grausam aus, weil er tabs benutzt.

Naja bei so vielen verschachtelten Schleifen und Abfragen und dann noch mit Tabsize 4 (was ich auch verwende) wirds schon unübersichtlich. Da mache ich lieber eine Funktion mehr oder vermeide eben unnötiges Verschachteln, indem ich den Fehlerfall vorher abprüfe.

hmm, das mag ich wiederum gar nicht. ich mag es klarer, was passieren soll im fall von !empty und kann später einfach den empty fall abhandeln ohne vielleicht das return am anfang zu übersehen.

Naja eben, später...weil da aber, wie du in dem Beispiel siehst (war nur ein Ausschnitt), verdammt viele Schleifen sind, kommt die else-Behandlung erst viel später, nachdem 3-4 Klammern zugehen. Da kennt sich dann keiner mehr aus. Ich habs lieber, wenn es gleich passiert und zusammenpasst.

Was ich auch noch gerne mache ist folgendes:

if( x > 0 && (y == 4 || z < 10) )
{
...
}

wird bei mir zu

bool isVisible = x > 0;
bool isInReach = y == 4 || z < 10;

if ( isVisible && isInReach )
{
...
}

Vorteil: man erspart sich unmögliche ifs, die man auch noch ev. in 2-3 Zeilen schachteln muss. Man kann es sehr viel leichter lesen und auch bearbeiten. Es ist sofort ersichtlich, was die Bedingung macht, wenn sie in Worte gefasst ist.

Nochmal zu Coda's Extrem-Negativbeispiel (http://www.mental-asylum.de/files2/Terrain.cpp) :
Viel schlechter gehts eigentlich kaum ;) Wenn ich derjenige bin der den Fehler suchen muss, kann ich mir die Kugel geben. Vorallem wenn auch nur eine der vielen x, y und Indizes falsch zählt, was ganz bestimmt vorkommen wird.

rotalever

2008-03-04, 21:31:30

bool isVisible = x > 0;
bool isInReach = y == 4 || z < 10;

if ( isVisible && isInReach )
{
...
}

Das werd ich ab jetzt auch so machen. Wieso bin ich nie auf eine solche Idee gekommen?:eek:

noid

2008-03-04, 21:34:22

Das werd ich ab jetzt auch so machen. Wieso bin ich nie auf eine solche Idee gekommen?:eek:

Jetzt noch MISRA-Regel 34 und es ist gut ;)

Coda

2008-03-04, 21:49:34

Nochmal zu Coda's Extrem-Negativbeispiel (http://www.mental-asylum.de/files2/Terrain.cpp) :
Viel schlechter gehts eigentlich kaum ;) Wenn ich derjenige bin der den Fehler suchen muss, kann ich mir die Kugel geben. Vorallem wenn auch nur eine der vielen x, y und Indizes falsch zählt, was ganz bestimmt vorkommen wird.
Die Variablen haben alle bezeichnende Parameter. Das ist nicht negativ, das ganze Ding ist einfach komplex wie sau. Wie soll ich deiner Meinung nach denn Indizes in ein 2D-Heightfield deiner Meinung nach sonst nennen? Das ist halt kein Blumenwiesencode.

Ich halte das Ding nach wie vor für sehr leserlich. "Normaler" Code sieht wesentlich angenehmer aus, ich wollte nur gezielt mal was extremes bringen.

Was da primär fehlt sind allerdings sehr ausführliche Kommentare, sonst kann das ein anderer gar nicht in angebrachter Zeit verstehen - das ist mir auch klar. Vielleicht würdest du dann verstehen warum der Code so wüst ist an manchen Stellen - da wird an jedem Index und Polygon gespart ;)

RMC

2008-03-04, 22:11:27

Ich halte das Ding nach wie vor für sehr leserlich. würdest du dann verstehen warum der Code so wüst ist an manchen Stellen"Normaler" Code sieht wesentlich angenehmer aus, ich wollte nur gezielt mal was extremes bringen.

Leserlich? ;D

Geh komm, jetzt im Ernst: Das kann keine Sau mehr lesen. Wüst ist der Code nicht weil er komplex ist, sondern weil er einfach unordentlich ist. Mehr nicht. Jeder Arbeitskollege gäbe dir ein paar ordentliche Kopfnüsse für sowas.

Mehr Zeilenabstände(!), leserlich gestaltete Bedingungen und Schleifen (!!), mehr Funktionen, viiiel mehr Kommentare(!!!), gscheite Benennung der Variablen (ich hab erst jetzt gesehen dass chunk_size ein static const ist...woher soll man das wissen? Das ist schon mal essentiell, weil es überall vorkommt) und auch Zwischenspeichern mancher Ergebnisse.

Aber so nicht

for(unsigned int y=0;y<=chunk_size;++y) {
for(unsigned int x=0;x<=chunk_size;++x) {
unsigned int heightmap_offset = x+leaf->chunk_pos[0] + (y+leaf->chunk_pos[1])*heightmap_width;
if((float)heightmap[heightmap_offset] * terrain_scale > max_height) max_height = (float)heightmap[heightmap_offset] * terrain_scale;
else if((float)heightmap[heightmap_offset] * terrain_scale < min_height) min_height = (float)heightmap[heightmap_offset] * terrain_scale;
}
}

Coda

2008-03-04, 22:19:34

Geh komm, jetzt im Ernst: Das kann keine Sau mehr lesen.
Ich kann das ohne Probleme so lesen. Und ich kenne etlichen C++-Code der genauso aussieht (Boost). Und erzähl mir nix davon, dass das nicht professionell wäre.

sondern weil er einfach unordentlich ist.
Da ist gar nichts unordentlich. Ich schlampe nicht beim programmieren.

Mehr Zeilenabstände(!)
Nö, brauch ich nich.

leserlich gestaltete Bedingungen und Schleifen (!!)
Ansichtssache. Ich seh da drauf und weiß um was es geht.

mehr Funktionen, viiiel mehr Kommentare(!!!)
Mehr Funktionen? Dann wird das Ding noch monströser. O(n²) brauch ich von der Übersicht garantiert nicht in Funktionen verpacken. Das mit den Kommentaren hab ich schon festgestellt. Das ist auch der einzige wirkliche Mangel. Ist aber ein Hobbyprojekt von mir, von daher im Moment nicht sehr wichtig.

gscheite Benennung der Variablen (ich hab erst jetzt gesehen dass chunk_size ein static const ist...woher soll man das wissen? Das ist schon mal essentiell, weil es überall vorkommt) und auch Zwischenspeichern mancher Ergebnisse.
Och bitte. Das sagt dir die IDE. Ich hasse Hungarian Notation. Hab ich schon früher gesagt.

Du musst auch bedenken, dass ich jetzt schon etliche Jahre C++ schreib. Irgendwann sieht man so Dinge eben schneller und dann ist der Zeilenabstand nur noch verschwendeter Platz. Das Projekt hat mal eben 1MB Sourcecode.

Auch bedenken musst du dass ich mit Visual Assist sehr gutes Syntax-Highlighting habe. Das macht die Sache nochmal deutlich lesbarer:
http://www.mental-asylum.de/files2/terrain.png

Mal Hand aufs Herz: Wie lange programmierst du schon?

Ectoplasma

2008-03-04, 22:26:21

void function(int a, int b) {
Klasse blubber;

int x;
int y;
int z;

if (a == b) {
while (i != 0) {
doSomething();
}
}
}

Obige Formatierung ist in Java Standard. Man beachte die Leerzeichen nach Kontrollstrukturen wie if oder while. Außerdem gibt es ein Leerzeichen vor jeder geschweiften Klammer.

RMC

2008-03-04, 22:31:10

Ich kann das ohne Probleme so lesen. Und ich kenne etlichen C++-Code der genauso aussieht (Boost). Und erzähl mir nix davon, dass das nicht professionell wäre.

Ähm...es sieht extrem unprofessionell aus. Das macht auf mich, und auf jeden vernünftigten außenstehenden Programmierer absolut keinen guten Eindruck.

Nö, brauch ich nich.

Ansichtssache.

Sagst du. Schon mal mit anderen zusammengearbeitet? Oder schon mal nach längerer Zeit in deinen eigenen Code geblickt?

Agreed. Aber dann wird das Ding noch monströser. Das mit den Kommentaren hab ich schon festgestellt. Das ist auch der einzige wirkliche Mangel. Ist aber ein Hobbyprojekt von mir, von daher im Moment nicht sehr wichtig.

Monströs ist es jetzt. Mit mehr Funktionen, mehr Klassen wird es übersichtlicher. Du wirst es dir selber danken, wenn du das Projekt nach 6 Monaten zum ersten Mal wieder erblickst.

Och bitte. Das sagt dir die IDE.

Du musst auch bedenken, dass ich jetzt schon etliche Jahre C++ schreib. Irgendwann sieht man so Dinge eben schneller und dann ist der Zeilenabstand nur noch verschwendeter Platz. Das Projekt hat mal eben 1MB Sourcecode.

Sry Coda, aber gerade dann solltest du es besser wissen. Wenn der Rest auch so aussieht...

Und bitte, das mit den Zeilenabständen ist Augenauswischerei. Verschwendeter Platz, da fällt es mir schwer dich noch ernst zu nehmen.

Wartungsfreundlichkeit (dazu zählt Übersichtlichkeit) sollte nicht so niederen Bedürfnissen wie Platzverbrauch weichen müssen. Wir sind nicht mehr in den 80ern.

Coda

2008-03-04, 22:38:15

Ähm...es sieht extrem unprofessionell aus. Das macht auf mich, und auf jeden vernünftigten außenstehenden Programmierer absolut keinen guten Eindruck.
Nein tut es nicht? Schau dir mal Carmacks Quake-Code an oder was geleaktes von Valve. Das ist noch viel schlimmer.

Selbst das so viel gelobte OGRE sieht genauso aus, außer dass sie die { in die Zeile darunter hauen. Darüber kann man aber wunderbar streiten. Und nein, das ist nicht "unprofessionell". Das machen mindestens 50% der Sources.

Bitte geh nicht von dir aus. Ich hab schon sehr viel Code aus der Industrie gesehen von NVIDIA, Microsoft usw. Da sieht sehr vieles genau so aus.

Sagst du. Schon mal mit anderen zusammengearbeitet? Oder schon mal nach längerer Zeit in deinen eigenen Code geblickt?
Ja? Teile des Codes sind uralt.
Was teilweise fehlt sind Kommentare, das war's dann aber schon.

Monströs ist es jetzt. Mit mehr Funktionen, mehr Klassen wird es übersichtlicher. Du wirst es dir selber danken, wenn du das Projekt nach 6 Monaten zum ersten Mal wieder erblickst.
Nein werd ich nicht. Ich kenne so Fälle.

Und bitte, das mit den Zeilenabständen ist Augenauswischerei. Verschwendeter Platz, da fällt es mir schwer dich noch ernst zu nehmen.
Dann nehm mich halt nicht ernst. Ich habe es gerne viel Code auf einmal im Blick zu haben.

Wartungsfreundlichkeit (dazu zählt Übersichtlichkeit) sollte nicht so niederen Bedürfnissen wie Platzverbrauch weichen müssen. Wir sind nicht mehr in den 80ern.
Ich brauche nicht mehr Zeilenabstände um es besser überblicken zu können.

Schau dir das PNG weiter oben an und urteile dann nochmal drüber. Die Browser-Ansicht täuscht auch gewaltig.

RMC

2008-03-04, 23:00:49

Nein tut es nicht? Schau dir mal Carmacks Quake-Code an oder was geleaktes von Valve. Das ist noch viel schlimmer.

Weil wir ja seit 12 Jahren nichts gelernt haben.. :rolleyes:

Selbst das so viel gelobte OGRE sieht genauso aus, außer dass sie die { in die Zeile darunter hauen. Darüber kann man aber wunderbar streiten. Und nein, das ist nicht "unprofessionell". Das machen mindestens 50% der Sources.

Bitte geh nicht von dir aus. Ich hab schon sehr viel Code aus der Industrie gesehen von NVIDIA, Microsoft usw. Da sieht sehr vieles genau so aus.

Und jetzt erzähl ich dir mal was ganz neues :) 90% der Sources sind Mist. Soll ichs deshalb genauso machen? Schlechte Beispiele gibts zu Hauf, daran orientier ich mich nicht. Du scheinbar schon.

Schau dir das PNG weiter oben an und urteile dann nochmal drüber. Die Browser-Ansicht täuscht auch gewaltig.

Ich finds noch immer unvorteilhaft und sehr verbesserungswürdig.

Coda

2008-03-04, 23:03:30

Weil wir ja seit 12 Jahren nichts gelernt haben.. :rolleyes:
Weil die Source-Engine ja auch 12 Jahre alt ist. OGRE ist brandaktuell.

Ganz krank ist auch das 3D-Studio-Max-SDK. Das musst du dir mal reinziehen wenn du wirklich schlechten Code sehen willst.

Und jetzt erzähl ich dir mal was ganz neues :) 90% der Sources sind Mist. Soll ichs deshalb genauso machen? Schlechte Beispiele gibts zu Hauf, daran orientier ich mich nicht. Du scheinbar schon.
Nein. Ich orientier mich an OGRE und Boost. Beides sehr große und für ihren Programmierstil gelobte Projekte.

Das ich keine Kommentare setzte ist reine Faulheit. Das hat aber nichts mit der Codequalität zu tun. Ich kann auch anders wenn ich Code für die Arbeit schreibe.

Ich finds noch immer unvorteilhaft und sehr verbesserungswürdig.
Wieviel Erfahrung hast du? (Ich frag zum 3. Mal) Mein erster C++-Code ist von 2000 und ich hatte immer mehrere Projekte am laufen. Das dürften inzw. so >5MB sein die da zusammengekommen sind. Es ist nicht so, dass ich es nicht im Griff hätte was da steht.

Den Terraincode könnte ich wohl schöner machen, wenn ich Performance opfern könnte. Tue ich aber genau an dieser Stelle nicht. Die Stellen in der Engine die Performanceunkritisch sind, sehen nochmal anders aus. Das ist Low-Level Performance-Code und keine Blumenwiese an Interfaces und Abstaktionsebenen drüber. Ich sag's nochmal. Es ist eben nicht immer 100% Wartbarkeit alles, vor allem wenn man am Machbaren kratzt.

Wenn es abstrahiert ist kann Code bei mir auch so (http://www.mental-asylum.de/files2/new.phps) aussehen - Ist zwar PHP tut aber nichts zur Sache.

Und noch was: Ich gebe zu, dass es wirklich nicht das beste Beispiel war - aus mehreren Gründen. Es sieht wirklich nur Code von mir aus, der auch so aussehen muss.

Nasenbaer

2008-03-04, 23:57:24

Also ich würde den Code so formatieren:

for( unsigned int y=0; y<=chunk_size; ++y )
{
for( unsigned int x=0; x<=chunk_size; ++x )
{
unsigned int heightmap_offset = x+leaf->chunk_pos[0] + (y+leaf->chunk_pos[1])*heightmap_width;

if( (float)heightmap[heightmap_offset] * terrain_scale > max_height )
{
max_height = (float)heightmap[heightmap_offset] * terrain_scale;
}
else if( (float)heightmap[heightmap_offset] * terrain_scale < min_height )
{
min_height = (float)heightmap[heightmap_offset] * terrain_scale;
}
}
}

Und dann warscheinlich die STL auch intensiver benutzen. Z.B. als Ersatz für die Arrays.

RMC

2008-03-04, 23:57:49

Wieviel Erfahrung hast du? (Ich frag zum 3. Mal) Mein erster C++-Code ist von 2000 und ich hatte immer mehrere Projekte am laufen. Das dürften inzw. so >5MB sein die da zusammengekommen sind. Es ist nicht so, dass ich es nicht im Griff hätte was da steht.

Du bist wohl wirklich ein Erbsenzähler. Wen interessiert das hier? Ich hab genug Erfahrung, da brauchst du keine Angst haben. Wenn du mehr wissen willst kannst du mich per PN fragen, aber alles andere ist hier für die Diskussion zwecklos.

Den Terraincode könnte ich wohl schöner machen, wenn ich Performance opfern könnte.

Für den Großteil der Optimierungen brauchst du hauptsächlich die Space- und die Entertaste auch wenn du das ungern hörst ;)

Coda

2008-03-05, 00:04:48

Also ich würde den Code so formatieren:
Und nur noch die Hälfte des Codes auf dem Bildschirm auf einmal sehen und zudem unnötiges Coderauschen generieren. Bravo. Nö. Das habe ich auch mal gemacht. Irgendwann merkt man dass es nichts mehr bringt was die Lesbarkeit angeht.

Für den Großteil der Optimierungen brauchst du hauptsächlich die Space- und die Entertaste auch wenn du das ungern hörst ;)
Andere Philosophie an dieser Stelle. Das hat nichts mit unprofessionalität zu tun, sondern primär mit Gewohnheit.

Und vor allem weigere ich mich wehement dagegen, dass man die { in eine neue Zeile setzen muss und bei jedem if die Klammern überhaupt. Es gibt unmengen von Code die das nicht tun. Das ist völlig subjektiv. Was das trennen von den Parametern usw. mit Leerzeichen betrifft lass ich ja mit mir reden.

Und dann warscheinlich die STL auch intensiver benutzen. Z.B. als Ersatz für die Arrays.
Ich verwende sonst auch überall std::vector. Der Code ist auf Performance und Speicherverbrauch getrimmt. std::vector prealloziert mir in diesem Fall einfach unnötig zuviel, weil ich den genauen Speicherverbrauch kenne.

Ich würde maximal soweit gehen:

for(unsigned int y=0; y<=chunk_size; ++y) {
for(unsigned int x=0; x<=chunk_size; ++x) {
unsigned int heightmap_offset = x+leaf->chunk_pos[0] + (y+leaf->chunk_pos[1])*heightmap_width;

if((float)heightmap[heightmap_offset] * terrain_scale > max_height)
max_height = (float)heightmap[heightmap_offset] * terrain_scale;
else if((float)heightmap[heightmap_offset] * terrain_scale < min_height)
min_height = (float)heightmap[heightmap_offset] * terrain_scale;
}
}

Und nein, das ist nicht unlesbarer. Man sieht eindeutig an der Einrückung wo die Blöcke beginnen und was zusammengehört.

RMC

2008-03-05, 00:15:47

Das hat nichts mit unprofessionalität zu tun, sondern primär mit Gewohnheit.

Schlechte Gewohnheiten wirken auf andere unprofessionell ;)

Und vor allem weigere ich mich wehement dagegen, dass man die { in eine neue Zeile setzen muss

Das ist ja ok, da gibs verschiedene Ansichten. Aber Leerzeichen sollten sein, und vorallem andere Kleinigkeiten:

Es ist ziemlich unvernünftig den Schleifeninhalt neben den Kopf zu schreiben. Zumindest sollte man eindrücken. Noch besser ist es, Klammern zu verwenden, dass Anfang und Ende gekennzeichnet sind.

Denn man weiß auf den ersten Blick nicht, ob die nachfolgende Zeile noch dazugehört oder nicht. Das kann bei anderen Editoren und Formatierungen zu Mißverständnissen führen, was denn der Autor damit gemeint haben könnte.

// Fill index buffer with indices for horizontal grid lines
for(unsigned int y=0;y<=chunk_size;++y) {
for(unsigned int x=0;x<=chunk_size;++x) indices[index_pos++] = x + y*(chunk_size+1);
indices[index_pos++] = 0xFFFF; // strip end

Besser:

// Fill index buffer with indices for horizontal grid lines
for( unsigned int y = 0; y <= chunk_size; ++y )
{
for( unsigned int x = 0; x <= chunk_size; ++x )
{
indices[index_pos++] = x + y * (chunk_size + 1);
}

indices[index_pos++] = 0xFFFF; // strip end
}

In der Praxis wird auch teilweise in den Coding Conventions festgelegt, dass IMMER Klammern gesetzt werden, auch wenn der Schleifen- oder Abfrageinhalt aus nur 1 Zeile besteht, um genau solche Mißverständnisse zu vermeiden. Mit Klammern sind Zweideutigkeiten immer ausgeschlossen.

Coda

2008-03-05, 00:22:19

Schlechte Gewohnheiten wirken auf andere unprofessionell ;)
Ich halte das nicht für schlechte Gewohnheiten. Und viele andere auch nicht. Komischerweise findet man meinen Code-Stil vermehrt bei größeren und komplexerem Code.

Und ich kann's im Gegenzug überhaupt nicht sehen wenn jemand wegen einer Anweisung { } und dann noch jeweils Newlines setzen muss. Aber du weißt ja: Meinung sind wie Arschlöcher. Ich hätte früher auch wehement die "{ in Newline" These vertreten. Inzwischen sehe ich das ganze lockerer, mache aber das für mich angenehmere.

Es ist ziemlich unvernünftig den Schleifeninhalt neben den Kopf zu schreiben.
Wieso? Wenn darunter nichts eingerücktes kommt dann muss es dahinter stehen. Wo ist das Problem?

Denn man weiß auf den ersten Blick nicht, ob die nachfolgende Zeile noch dazugehört oder nicht. Das kann bei anderen Editoren und Formatierungen zu Mißverständnissen führen, was denn der Autor damit gemeint haben könnte.
Wo ist das Problem? Ich verwende Tabs mit 4 Spaces. Das kann jeder so einstellen.

Als ich das Beispiel von dir gesehen hab hat bei mir auch sofort was geklickt, dass da was komisch ist. Ich habe instinktiv sofort nach der unteren Klammer gesucht die scheinbar fehlt. Ich sag doch, das ist reine Gewohnheit.

In der Praxis wird auch teilweise in den Coding Conventions festgelegt, dass IMMER Klammern gesetzt werden, auch wenn der Schleifen- oder Abfrageinhalt aus nur 1 Zeile besteht, um genau solche Mißverständnisse zu vermeiden. Mit Klammern sind Zweideutigkeiten immer ausgeschlossen.
Ich halte mich an Coding-Conventions wenn sie mir gegeben werden, aber ich halte es persönlich für mich - und ausschließlich für mich ist der Code - nicht mehr für nötig sowas zu schreiben. Ich versichere dir, ich habe seit mindestens 2 Jahren keinen Bug mehr produziert der etwas damit zu tun hatte dass ich soviel weglasse. Und ich finde mich auch nicht weniger zurecht, sonst würd ich's nicht so machen. Glaub's oder nicht.

Und ja, dieser Coding-Stil ist primär auf Faulheit begründet. Aber Faulheit die ich mir leisten kann. Wenn andere an einem Projekt mitarbeiten und nicht damit zurechtkommen kann ich auch ohne Probleme gnädiger damit sein :biggrin:

Wenn du mir Unprofessionalität vorwirst dann fühl ich mich persönlich ziemlich angegriffen. Es ging hier doch darum wie man persönlich codet und nicht wie man es im Team macht. Oder hab ich das jetzt falsch verstanden?

Falls der Code jemals Verwendung finden sollte außerhalb meines Rechners dann kann ich immer noch ne Woche drübergehen und es an eine Coding-Convention anpassen und ausführlich dokumentieren.

RMC

2008-03-05, 00:39:55

Ich versichere dir, ich habe seit mindestens 2 Jahren keinen Bug mehr produziert der etwas damit zu tun hatte dass ich soviel weglasse. Glaub's oder nicht.

Du kannst mir versichern was du willst. Ich glaub dir, dass du mit deinem Stil für dich gut fährst, aber wirkungsvoll in der Praxis ist er nicht besonders.

Fakt ist, dass meine vorher beschriebene Coding Convention (dass man bei jeder Abfrage/Schleife Klammern setzt) nicht aus Lust und Laune, sondern aus Erfahrung entstanden ist. Ich kenne Firmen, die das ausschließlich so handhaben, und die machen das nicht weils ihnen grad passt, sondern um potentielle Fehlerquellen zu vermeiden.

Wenn solche Fehler, wie in meinem letzten Post beschrieben, passieren (und sie passieren unfreiwillig JEDEM), dann ist das eindeutig vermeidbar.

Komischerweise findet man meinen Code-Stil vermehrt bei größeren und komplexerem Code.

Wenn du mir Unprofessionalität vorwirst dann fühl ich mich persönlich ziemlich angegriffen.

Guter Stil zeichnet sich dadurch aus, dass er zukünftige Fehlerquellen schon im vorhinein vermeidet, und die Weiterentwicklung durch Lesbarkeit und Eindeutigkeit auch für andere (!) Programmierer vereinfacht.

Das tut dein Stil nicht, im Gegenteil, und du beharrst auch noch drauf. Wenn du glaubst dein Stil sei ok, weil du dich damit rühmst, dass irgendwelche anderen Projekte genauso aussehen, dann bleibt mir leider nichts anderes übrig als das als unprofessionell zu bezeichnen.

Coda

2008-03-05, 00:46:07

Hast du gelesen was ich geschrieben hab? Ich sagte, dass ich ohne Probleme bereit bin mich an jede Coding-Convention zu halten. Das ist privater Code.

Und ich verstehe auch warum Firmen das so machen. Man muss schließlich die ganze Belegschaft mitschleifen und es hat nicht jeder die ultimative Erfahrung. Ich habe C++ praktisch mit der Muttermilch aufgesogen - und wenn sich das arrogant anhört so soll es so sein.

Ich glaube wir reden grundsätzlich aneinander vorbei. Ich will mich hier mit überhaupt nichts rühmen, es ging nur darum wie man seinen Code schreibt.

Und nein, ich mache das im Firmenumfeld auch nicht so! Wahrscheinlich hätte ich das als Disclaimer ganz groß drunterschreiben sollen. Da ist Doxygen angesagt, Coding-Convention und jede Menge Kommentare. Ich bin nicht dein Kollege den du deswegen hassen musst o.ä.

Wenn solche Fehler, wie in meinem letzten Post beschrieben, passieren (und sie passieren unfreiwillig JEDEM), dann ist das eindeutig vermeidbar.
Und da muss ich dir dennoch wiedersprechen. Nein. Mir passiert es nicht mehr. Früher ja, aber jetzt nicht mehr. Das würde mir auffallen. Man kann alles perfektionieren und ich bin sehr pedantisch.

Ich kann deshalb auch ohne Probleme nachvollziehen warum man das nicht machen sollte. Ich hatte die Probleme auch alle mal.

RMC

2008-03-05, 00:58:45

Hast du gelesen was ich geschrieben hab? Ich sagte, dass ich ohne Probleme bereit bin mich an jede Coding-Convention zu halten. Das ist privater Code.

Privater Code oder nicht, das soll kein Unterschied sein. Stil ist Stil. Es geht darum, den Code für außenstehende so leserlich und eindeutig wie möglich zu machen, sowohl optisch als auch inhaltlich.

Ist klar, dass man privat dann eher in einen schlechten Stil abweicht, weil das Zeug sonst keiner liest. Das tu ich leider auch manchmal.
Du musst nur verstehen, dass du privat mit gutem Stil auch besser dran bist. Spästens dann wenn du 5 Jahre alte Files durchschaust oder zB ein Forum deinen Code durchlesen lässt ;)

Es gibt auch Firmen mit schlechten Coding Conventions (wie du an Valve gesehen hast). Dann verwendet intern jeder denselben Mist.

Und ich verstehe auch warum Firmen das so machen. Man muss schließlich die ganze Belegschaft mitschleifen und es hat nicht jeder die ultimative Erfahrung. Ich habe C++ praktisch mit der Muttermilch aufgesogen - und wenn sich das arrogant anhört so soll es so sein.

Wenn jeder sein eigenes Süppchen kocht, ist die Firma nach einer Woche pleite, weil der Großteil der Zeit in das Verstehen von fremden Code gesteckt wird. Und wenn du das schon mal probiert hast wirst du merken, dass das echt ein Haufen Arbeit ist. Ohne Convetions geht gar nichts.

Coda

2008-03-05, 00:59:48

Wenn jeder sein eigenes Süppchen kocht, ist die Firma nach einer Woche pleite, weil der Großteil der Zeit in das Verstehen von fremden Code gesteckt wird. Und wenn du das schon mal probiert hast wirst du merken, dass das echt ein Haufen Arbeit ist. Ohne Convetions geht gar nichts.
Sagmal. Kannst du lesen?

Ich sagte doch bereits zum 10. Mal, dass ich mich an Conventions halte wenn es sie gibt und sie auch gut finde. Wo ist dein Problem?

RMC

2008-03-05, 01:08:00

Sagmal. Kannst du lesen?

Tja wenns spät ist liest man irgendwo ein "nicht" zu viel ;)

Trap

2008-03-05, 01:25:39

Und wieder bewahrheitet sich die alte Regel, je unwichtiger das Thema, desto lebhafter die Diskussion darüber.

Einrückungen, Leerzeichen und Newlines kann man in einer Sekunde auf die persönlich favorisierte Fassung bringen (und auch wieder zurück auf eine Firmenkonvention).

Die Wahl der Bezeichner-Schreibkonvention hat deutlich mehr Auswirkungen, dafür gibt es nämlich meines Wissens keine automatischen Werkzeuge zur Konvertierung. Noch wichtiger ist die Wahl der Bezeicher, kurze haben die Gefahr, die Bedeutung nicht richtig zu transportieren, lange verbrauchen wertvollen Platz auf dem Bildschirm und sind nicht so schnell unterscheidbar beim Lesen.

Ich halte beim Beispielcode von Coda alle Variablennamen die "terrain" oder "heightmap" enthalten für unnötig lang, schließlich implementiert die Klasse ein heightmap-basierendes Terrain, da ist es nicht nötig, dass in jeder Variable immer wieder zu erwähnen.

Coda

2008-03-05, 01:29:17

Und wieder bewahrheitet sich die alte Regel, je unwichtiger das Thema, desto lebhafter die Diskussion darüber.
Eben. Ich finde es eben auch eher unwichtig und deshalb finde ich es unangebracht mir so unglaublich an den Karren fahren zu müssen.

Ich halte beim Beispielcode von Coda alle Variablennamen die "terrain" oder "heightmap" enthalten für unnötig lang, schließlich implementiert die Klasse ein heightmap-basierendes Terrain, da ist es nicht nötig, dass in jeder Variable immer wieder zu erwähnen.
Siehst du RMC. Es geht noch starsinniger als ich ;)

Aber Trap, da gibt's das Problem, dass viele Funktionen auch "width" usw. als Parameter verwenden, dann müsste ich wieder this->width schreiben und das mag ich gar nicht. Und nur "w" als Parameter finde ich dann auch nicht gut.

Trap

2008-03-05, 01:48:15

Die in der Mathematik übliche Konvention ist, für die im Anwendungsbereich oft verwendete Konzepte eindeutige einzelne Symbole zu benutzen. Wobei wir wieder bei den griechischen Buchstaben sind ;)

Ich fände es zweckmäßig, "T" anstatt von "terrain" und "H" anstatt von "heightmap" zu schreiben, natürlich nur in der Implementierung der Klasse, nicht im Interface. Ich hab es nicht ausprobiert und kann natürlich auch damit völlig daneben liegen, auch ist das eher etwas für wichtigeren Code, der oft gelesen wird, so dass man die Abkürzungen auch kennt.

Neomi

2008-03-05, 03:05:51

unsigned int heightmap_offset = x+leaf->chunk_pos[0] + (y+leaf->chunk_pos[1])*heightmap_width;
if((float)heightmap[heightmap_offset] * terrain_scale > max_height) max_height = (float)heightmap[heightmap_offset] * terrain_scale;
else if((float)heightmap[heightmap_offset] * terrain_scale < min_height) min_height = (float)heightmap[heightmap_offset] * terrain_scale;

Wenn es dir schon so auf Kompaktheit ankommt, was soll daran eigentlich kompakt sein? Sowenig Zeilen wie möglich, egal wie lang?

unsigned int heightmap_offset = x+leaf->chunk_pos[0] + (y+leaf->chunk_pos[1])*heightmap_width;
float height = (float)heightmap[heightmap_offset] * terrain_scale;
if(max_height < height) max_height = height;
else if(min_height > height) min_height = height;

Dabei würde sowas doch auch noch deinem privaten Stil entsprechen. Nur eine Zeile mehr, dafür (als ob das wichtig wäre) weniger Bytes auf der Platte, schneller compiliert und bei einem schlechten Compiler potentiell schneller in der Ausführung. Wobei ich für wirklich performanten Code die Skalierung aus den Schleifen herausziehen würde, was in dem Fall problemlos möglich ist. Minimum und Maximum also erstmal unskaliert berechnen und dann bei der Zuweisung zum AABB erst skalieren. Kostet in dem Fall nichtmal zusätzliche Zeilen, spart aber einen ordentlichen Haufen Multiplikationen.

Und ich verstehe auch warum Firmen das so machen. Man muss schließlich die ganze Belegschaft mitschleifen und es hat nicht jeder die ultimative Erfahrung. Ich habe C++ praktisch mit der Muttermilch aufgesogen - und wenn sich das arrogant anhört so soll es so sein.

Oh ja, das klingt tatsächlich sehr arrogant. Als ob Code-Konventionen nur dazu da wären, auch die normalsterblichen Programmierer nicht verzweifeln zu lassen...

Du sagst ja selbst, daß du schon seit 2000 in C++ programmierst und schon ca. 5 MB Code geschrieben hast. Das kann man locker so interpretieren, daß du erst seit 2000 in C++ programmierst und gerade mal 5 MB Code zusammen hast. Wenn ich mir deine Terrain.cpp so anschaue, dann ist alles ziemlich schnell klar, obwohl ich selber einen anderen Stil bevorzuge, eben weil es doch eher Blumenwiesencode ist. Und dafür, daß du den Stil mit Performance begründest, hast du ganz schön Potential verschenkt. In der SampleHeightmapBilinear z.B. sehe ich vier Multiplikationen mit terrain_scale, obwohl eine unskalierte Interpolation gefolgt von einer einzigen Skalierung das gleiche Ergebnis schneller liefert.

Und da muss ich dir dennoch wiedersprechen. Nein. Mir passiert es nicht mehr. Früher ja, aber jetzt nicht mehr. Das würde mir auffallen. Man kann alles perfektionieren und ich bin sehr pedantisch.

Fehler passieren jedem Programmierer, auch denen mit deinem durchaus großen Talent und dem dreifachen deiner Erfahrung. Mit zunehmender Erfahrung verschwinden zwar die schwer nachträglich zu korrigierenden Fehler im Softwaredesign, aber die teilweise schwer zu findenden und dann allerdings leicht behebbaren banalen Fehler passieren auch den besten Programmierern. Davon kann sich keiner lossprechen.

Coda

2008-03-05, 04:20:47

Wenn es dir schon so auf Kompaktheit ankommt, was soll daran eigentlich kompakt sein? Sowenig Zeilen wie möglich, egal wie lang?
Die Variablen sollten lesbar bleiben.

Dabei würde sowas doch auch noch deinem privaten Stil entsprechen. Nur eine Zeile mehr, dafür (als ob das wichtig wäre) weniger Bytes auf der Platte, schneller compiliert und bei einem schlechten Compiler potentiell schneller in der Ausführung. Wobei ich für wirklich performanten Code die Skalierung aus den Schleifen herausziehen würde, was in dem Fall problemlos möglich ist. Minimum und Maximum also erstmal unskaliert berechnen und dann bei der Zuweisung zum AABB erst skalieren. Kostet in dem Fall nichtmal zusätzliche Zeilen, spart aber einen ordentlichen Haufen Multiplikationen.
Das ist kein Teil des performancekritischen Codes. Das ist Editorzeug...

Oh ja, das klingt tatsächlich sehr arrogant. Als ob Code-Konventionen nur dazu da wären, auch die normalsterblichen Programmierer nicht verzweifeln zu lassen...
Bitte nimm das nich so ganz ernst. Aber RMC pinkelt mir hier gewaltig ans Bein, das mir sowas schonmal rausrutscht. Ich hätte es einfach bleiben lassen sollen gerade den üblsten Hack-Code als Beispiel zu posten... Aber erzähl mir bitte nicht dass sowas nicht gang und gebe wäre.

Du sagst ja selbst, daß du schon seit 2000 in C++ programmierst und schon ca. 5 MB Code geschrieben hast. Das kann man locker so interpretieren, daß du erst seit 2000 in C++ programmierst und gerade mal 5 MB Code zusammen hast.
Nana. Am Anfang ging's auch mit kleineren Projekten los ohne viel Ahnung und ich hatte auch noch Schule usw.

Wenn ich mir deine Terrain.cpp so anschaue, dann ist alles ziemlich schnell klar, obwohl ich selber einen anderen Stil bevorzuge, eben weil es doch eher Blumenwiesencode ist.
Vieles davon ging recht flott von der Hand ja, manches imho auch nicht ("SaveTerrainLeaf" war durchaus etwas problematischer). Aber das meinte ich nicht mit Blumenwiesencode.

Und dafür, daß du den Stil mit Performance begründest, hast du ganz schön Potential verschenkt. In der SampleHeightmapBilinear z.B. sehe ich vier Multiplikationen mit terrain_scale, obwohl eine unskalierte Interpolation gefolgt von einer einzigen Skalierung das gleiche Ergebnis schneller liefert.
Auch Editorcode.

Fehler passieren jedem Programmierer, auch denen mit deinem durchaus großen Talent und dem dreifachen deiner Erfahrung. Mit zunehmender Erfahrung verschwinden zwar die schwer nachträglich zu korrigierenden Fehler im Softwaredesign, aber die teilweise schwer zu findenden und dann allerdings leicht behebbaren banalen Fehler passieren auch den besten Programmierern. Davon kann sich keiner lossprechen.
Du hast sicher recht damit, aber diese Fehler die aufgrund der Klammerung passiert würden mir schon auffallen, weil sie äußerst eklig zu finden sind. Vielleicht ist aber auch nur mein Gedächtnis zu löchrig.

Können wir uns jetzt bitte wieder beruhigen. Ja ich hab mich mal wieder zu weit aus dem Fenster gelehnt, aber nur weil ich mich angegriffen gefühlt hatte. Srykthx.

Grestorn

2008-03-05, 07:30:02

Oh Mann, da hab ich was losgetreten...

Mir ist aber klar, dass das Glaubenskämpfe sind. Jeder hat seine eigenen Präferenzen und das ist auch ok, so lange er alleine arbeitet.

Im Team wird man sich einigen müssen, und da fände ich es nicht so toll, wenn jemand mit Vorstellungen, dass man den Code möglichst platzsparend formatieren müsste, versuchen würde, seinen Stil im Team durchzudrücken.

Die Erfahrung ins Spiel zu bringen hilft da m.E. nur wenig. Ich programmiere seit 1988 in C und Pascal, seit 1996 in C++ und seit 2000 in Java. Ich konnte K/R nie leiden, weil diese Formatierung einfach unlogisch ist und meiner optischen Vorstellung widerspricht. Außerdem wird jeder der mal in einer Wirth'schen Sprache (Pascal, Modula-II, Oberon) programmiert hat ganz von selbst den Block-Beginn in eine eigene Zeile setzen, weil es in diesen Sprachen nur natürlich ist.

Mich nervt es gewaltig, dass K/R immer noch so oft in der Literatur verwendet wird und auch im Java-Standard tatsächlich so vorgesehen wurde. Viele alte Coder wollen nicht davon ablassen und "verderben" den Nachwuchs.

Es geht beim Programmieren nicht darum möglichst viel Code in möglichst wenig Platz unterzubringen. Wie Coda schon richtig schrieb, setzen wir moderne IDEs ein, die so etwas wie Folding und schnelle Navigation zu Methoden aus dem effeff beherrschen.

Es geht darum, den Code auf Anhieb nachvollziehen zu können. Und da ist es einfach nur anstrengend, wenn der Code zu sehr komprimiert ist. Der Mensch tut sich einfach viel leichter, wenn der Code klar strukturiert ist.

Aber trotz allem: Das ist nur eine MEINUNG. Wenn jemand anders glücklich wird, so soll er. Nur bitte nicht die eine oder andere Lösung als das einzig wahre verkaufen und im Team auch an die anderen denken.

Expandable

2008-03-05, 07:34:14

Wieso lasst ihr Tabs durch Spaces ersetzten? Finde ich sehr unangenehm.

Ectoplasma

2008-03-05, 07:59:06

Wieso lasst ihr Tabs durch Spaces ersetzten? Finde ich sehr unangenehm.

Weil es die einzige sinnvolle Form ist, den Code in jedem Editor lesen zu können. Ich will doch nicht ständig an der Tabweite rumfummeln. Tabs sind für mich eine echte Seuche. Aber egal, wenn es im Team als Coding-Style vorgeschrieben ist, dann muss man halt in den sauren Apfel beissen.

Gast

2008-03-05, 08:08:39

Finde den Code von Coda jetzt nicht so negativ, daß es sich lohnen würde darüber gefühlte Ewigkeiten Haare zu spalten. Ich bin zwar lieber etwas verschwenderischer mit dem Platz, lesen und überblicken kann man das aber IMHO schon. Da gibt es viel einfacheren Code, der viel schlechter zu lesen ist. Wenn man mit fremden Code solche Probleme hat, sollte man sich vielleicht ein anderes Hobby zulegen... ;)

Grestorn

2008-03-05, 08:27:46

Wieso lasst ihr Tabs durch Spaces ersetzten? Finde ich sehr unangenehm.

Weil der Code dann in jedem Editor, egal wie er eingestellt ist, immer gleich aussieht und auch immer gleich gedruckt wird.

Vom Handling her haben Spaces heute keinen Nachteil mehr. Nicht mit dem Autoindent und Outdent moderner Editoren.

Nasenbaer

2008-03-05, 08:54:53

Und nur noch die Hälfte des Codes auf dem Bildschirm auf einmal sehen und zudem unnötiges Coderauschen generieren. Bravo. Nö. Das habe ich auch mal gemacht. Irgendwann merkt man dass es nichts mehr bringt was die Lesbarkeit angeht.

Dafür gibt es ja große Displays, Schriftgrößenanpassungen und Rotationsfunktionen beim TFT um den sichtbaren Ausschnitt zu vergrößern. Für Übersicht sorgt dann die Outlinefunktion der IDE sowie Codeausblendungen.

Das Problem, dass einen zum zusätzlichen Umbruch nötigt ist IMO der normale Zeilenabstand. In jedem Officetool und LaTeX erst recht kann man die Zeilenabstände anpassen. Die meisten IDEs dürften das nicht packen. Also ein 1,5 facher Zeilenabstand für neue Blöcke wie For-Schleifen etc. wäre wohl schon völlig ausreichend um für mehr Übersicht zu sorgen und gleichzeitig nicht zu viel Platz zu "verschwenden". Aber wendern können das warscheinlich eh nur KDE basierte Programme, die einem dja große Spielräume bei der Codeformatierung erlauben.

Ich verwende sonst auch überall std::vector. Der Code ist auf Performance und Speicherverbrauch getrimmt. std::vector prealloziert mir in diesem Fall einfach unnötig zuviel, weil ich den genauen Speicherverbrauch kenne.

Das war auch nur ne Anmerkung am Rande - dass du STL kennst und nutzt kann ich mir bei dir schon vorstellen - so neu ist C++ für dich glaub ich nicht. :)

Weil der Code dann in jedem Editor, egal wie er eingestellt ist, immer gleich aussieht und auch immer gleich gedruckt wird.

Vom Handling her haben Spaces heute keinen Nachteil mehr. Nicht mit dem Autoindent und Outdent moderner Editoren.
Das ist IMO aber eher ein Nachteil. Der eine will vielleicht nur 2 Spaces Einrückung, der andere sogar 8. Mit Tabs kann ich das in jedem Editor einstellen wie ich das will ohne den Code umformatieren zu müssen. Es geht ja nicht darum, dass er überall gleich aussieht sondern, dass der Arbeitsplatznutzer immer das hat wie er optimal mit arbeiten kann.

Grestorn

2008-03-05, 09:07:05

Das ist IMO aber eher ein Nachteil. Der eine will vielleicht nur 2 Spaces Einrückung, der andere sogar 8. Mit Tabs kann ich das in jedem Editor einstellen wie ich das will ohne den Code umformatieren zu müssen. Es geht ja nicht darum, dass er überall gleich aussieht sondern, dass der Arbeitsplatznutzer immer das hat wie er optimal mit arbeiten kann.

Das funktioniert aber erfahrungsgemäß in den seltensten Fällen. Denn oft sieht der Code mit einer anderen Tab-Einstellung einfach nur furchtbar aus. Weil an einigen Stellen doch Spaces verwendet wurden oder einfach weil die Gesamtformatierung aus dem Ruder läuft.

Ich kenne außerdem eigentlich niemanden, der in C-ähnlichen Sprachen eine andere Einrückungstiefe als 4 verwendet.

noid

2008-03-05, 09:27:09

Das funktioniert aber erfahrungsgemäß in den seltensten Fällen. Denn oft sieht der Code mit einer anderen Tab-Einstellung einfach nur furchtbar aus. Weil an einigen Stellen doch Spaces verwendet wurden oder einfach weil die Gesamtformatierung aus dem Ruder läuft.

Ich kenne außerdem eigentlich niemanden, der in C-ähnlichen Sprachen eine andere Einrückungstiefe als 4 verwendet.

Jap, 4 ist eigentlich Standard.

So schlimm fand ich den Code von Coda jetzt nicht - lediglich die Operatoren mag ich nicht so dicht gepackt. Das liest sich meistens nicht so dolle.

Für den Fall von #ifdefs - rückt ihr den Code ein?

Grestorn

2008-03-05, 09:35:55

Für den Fall von #ifdefs - rückt ihr den Code ein?

Kommt auf die Precompiler Anweisung an.

Ifdefs rücke ich normalerweise nicht ein. Pragmas meist schon.

Expandable

2008-03-05, 09:38:31

Ich finde den Code von Coda btw auch nicht schlimm. Ich hätte zwar ein paar Sachen anders formatiert, aber dank Visual Assist kennt man sich doch wunderbar aus.

Einzeilige if's und else's sind bei mir übrigens immer ohne geschweifte Klammern, ebenso for-Schleifen. Also:

if (bedingung)
bla();

for (...)
do();

Weil der Code dann in jedem Editor, egal wie er eingestellt ist, immer gleich aussieht und auch immer gleich gedruckt wird.

Vom Handling her haben Spaces heute keinen Nachteil mehr. Nicht mit dem Autoindent und Outdent moderner Editoren.

Ach so. Da ich nur Visual Studio verwende ist mir das dann relativ egal. Der Vorteil von Tabs ist einfach, dass man nicht hundert mal Backspace drücken muss, um eine Zeile zu löschen. Soll heißen: Ich habe 5 Einrückungen per Tab. Dann muss ich 5x Backspace drücken, um die Zeile zu löschen und nicht 5 x 4 = 20 Mal wie bei den Spaces statt Tabs. Oder geht das in VS irgendwie automatisch?

(Nachtrag: Mir ist schon klar, dass es Tastenkombinationen gibt, um eine Zeile schneller zu löschen. Allerdings geht 5x Backspace drücken immer noch schneller, als irgendwelche anderen Verrenkungen auf der Tastatur durchzuführen).

Grestorn

2008-03-05, 09:45:19

(Nachtrag: Mir ist schon klar, dass es Tastenkombinationen gibt, um eine Zeile schneller zu löschen. Allerdings geht 5x Backspace drücken immer noch schneller, als irgendwelche anderen Verrenkungen auf der Tastatur durchzuführen).

Reine Gewohnheit. Ich würde niemals eine Zeile mit zeichenweisem Backspace oder Delete löschen. Sondern mit Pos1, Shift-CrsDown, Delete. Aber jedem wie er es gewohnt ist.

noid

2008-03-05, 09:56:53

Ich finde den Code von Coda btw auch nicht schlimm. Ich hätte zwar ein paar Sachen anders formatiert, aber dank Visual Assist kennt man sich doch wunderbar aus.

Einzeilige if's und else's sind bei mir übrigens immer ohne geschweifte Klammern, ebenso for-Schleifen. Also:

if (bedingung)
bla();

for (...)
do();

Ach so. Da ich nur Visual Studio verwende ist mir das dann relativ egal. Der Vorteil von Tabs ist einfach, dass man nicht hundert mal Backspace drücken muss, um eine Zeile zu löschen. Soll heißen: Ich habe 5 Einrückungen per Tab. Dann muss ich 5x Backspace drücken, um die Zeile zu löschen und nicht 5 x 4 = 20 Mal wie bei den Spaces statt Tabs. Oder geht das in VS irgendwie automatisch?

(Nachtrag: Mir ist schon klar, dass es Tastenkombinationen gibt, um eine Zeile schneller zu löschen. Allerdings geht 5x Backspace drücken immer noch schneller, als irgendwelche anderen Verrenkungen auf der Tastatur durchzuführen).

Das Löschen/Einrücken sind bei mir 5 mal eine Taste, dank IDE ;)

Chris Lux

2008-03-05, 12:41:33

(Nachtrag: Mir ist schon klar, dass es Tastenkombinationen gibt, um eine Zeile schneller zu löschen. Allerdings geht 5x Backspace drücken immer noch schneller, als irgendwelche anderen Verrenkungen auf der Tastatur durchzuführen).
ich find ctrl+backspace nicht zu umständlich ;)

ich nutze auch visual studio mit visual assist, aber ich habe das kribbelbunte highlighting abgeschaletet. dafür steinigt ihr mich sicher für meinen black background stil ;)

http://img167.imageshack.us/img167/2687/codestyleqz6.png

astro

2008-03-05, 13:44:00

Nasenbaer

2008-03-05, 14:02:53

ich find ctrl+backspace nicht zu umständlich ;)

ich nutze auch visual studio mit visual assist, aber ich habe das kribbelbunte highlighting abgeschaletet. dafür steinigt ihr mich sicher für meinen black background stil ;)

http://img167.imageshack.us/img167/2687/codestyleqz6.png
Keinesfalls. Hatte mir früher auch immer die Mühe gemacht und die gesamten Farbeinstellungen umgestellt damit sie mit schwarzem Hintergrund harmonieren. Ich finde das Arbeiten damit angenehmer, weil es weniger "blendet" aber die Arbeit ist enorm, da ich auch viele unterschiedliche Farben für die unterschiedlichen "Code-Arten" nutze. Welche zu finden, die gut mit schwarz harmonieren ist mühsam. :/

noid

2008-03-05, 15:28:44

Coda

2008-03-05, 20:45:53

PH4Real

2008-03-05, 21:51:42

Lustige Diskussion :tongue: ... mein Senf dazu:
Schreibe so, dass Andere ohne Probleme deinen Kram verstehen (zumindest nicht an den Variablennamen und den Einrückungen verzweifeln).

Das kann man auch rein egoistisch verteidigen, da man so Handyanrufe in seiner Urlaubszeit vermeidet, weil der Arbeitskollege sich "totgelesen" hat :wink:.

Der "JavaStyle" ist auch mein Favorit, wobei je nach Art der Verwendung auch andere durchaus Sinn haben besonders, da es nicht überall eine IDE gibt (obwohl ich eigentlich Ungarische Notation hasse, die auch eigentlich eher aus einem "Betriebsunfall" bei Microsoft entstanden ist).

Chris Lux

2008-03-05, 23:32:44

Ist das C++/CLI oder warum hast du foreach?
boost::foreach (http://www.boost.org/doc/html/foreach.html) ;)

Coda

2008-03-05, 23:34:26

Iiih Makros ;)

Nasenbaer

2008-03-06, 08:51:52

boost::foreach (http://www.boost.org/doc/html/foreach.html) ;)
Kommt die STL nicht auch schon mit nem foreach?!

http://www.sgi.com/tech/stl/for_each.html

Gast

2008-03-06, 11:02:07

Witzige Diskussion, kommt mir irgendwie bekannt vor. Ich selbst halte es mehr wie Coda und tendiere auch zu kompakteren Code, weil ich so mehr auf einen Blick habe. Allerdings betrifft das letztlich nur die Klammern, bei allem anderen schreib ich auch aus ( "int a,b,c" gibts nicht, zumal schon gar nicht bei voll ausgeschriebenen Variablenbezeichnern).
"Klammer-Zeilen" haben bei mir den gegenteiligen Effekt, zu viele Leerzeilen reißen den Code für mich zu weit auseinander. Ich kann mir nicht helfen, ich gerate da tlw. beim Lesen ins Stocken.

Andererseits hab ich mich früher, bevor ich mich für eine Klammervariante fest entschied (entscheiden musste), selbst die Klammern hin und wieder in eine eigene Zeile gesetzt - nämlich dann, wenn es kompliziert wurde. Die "Entzerrung" half hier wiederum doch. Heute "entzerre" ich anders, ein sehr gutes Beispiel hierfür kommt von RMC. Imo ist das viel wichtiger als die Frage, ob man nun Klammern in Extrazeilen stellt oder nicht.

if( x > 0 && (y == 4 || z < 10) )
{
...
}

wird bei mir zu

bool isVisible = x > 0;
bool isInReach = y == 4 || z < 10;

if ( isVisible && isInReach )
{
...
}

Wo immer möglich, versuche ich solche Lösungen zu finden. Es ist erstaunlich, was dabei alles passiert. Es wird nicht nur viel besser lesbar und nachvollziehbarer, sondern sorgt auch automatisch dafür, dass ich dabei manches auch vereinfachen, sprich optimieren kann. Beim "Aufdröseln des Knotens" merkt man auch sehr schnell, dass manche "Schlaufe" unnötig ist, bzw. anderswo vereinfacht eingesetzt werden kann. Man (bzw. ich) fabriziert hin und wieder doch regelrechte "Hirnknoten" und schießt sich selbst von hinten durch die Brust ins Auge. Wenn ich so einen aufdröseln kann, muss ich schmunzeln oder manchmal über mich selbst auch lachen.