Codeorganisation (c/c++)
- 
					
					
					
					
einschlafen ? kein kaffee da ? #gg
 - 
					
					
					
					
Mr Evil schrieb:
"scriptkiddys bevorzugen variante 1 weil man so profesionalitaet und komplexitaet vortaeuschen kann - schaut halt professioneller aus...
kann sein. sie glauben wohl, dass nur sehr erfahrene coder k&r benutzen. so'n archischen stil können nur leute, die seit den 70'er jahren in C programmieren. und wer das nachmacht, gehört zu den wahren cracks.
btw, da geschweifte klammern von k&r-fans so stiefmütterlich behandelt werden und ihnen offenbar ein dorn im auge sind, hab' ich hier die ultimative lösung für alle k&r-fans. lasst doch die klammern einfach weg:if (a > b) mach_dies(), mach_das(), mach_jenes();^^ vorschläge für eine namen? 'k&r reloaded' vielleicht?

 - 
					
					
					
					
~fricky schrieb:
kann sein. sie glauben wohl, dass nur sehr erfahrene coder k&r benutzen.
In Java verwendet man standardmäßig K&R... und Java Programmierer sind ja die craßßeßten cod3r cr4cks 3v3r!
 - 
					
					
					
					
Shade Of Mine schrieb:
~fricky schrieb:
kann sein. sie glauben wohl, dass nur sehr erfahrene coder k&r benutzen.
In Java verwendet man standardmäßig K&R...
gosling und co. sind ja auch nicht mehr die jüngsten.

 - 
					
					
					
					
1TBS ftw ^^ punkt

obwohl ich auch schonmal ne zeitlang sachen wie if und schleifen allgemein mit
if(){ doSomething(); }formatiert hatte und klassen und funktionen mit
class { function() { if(){ doSomething(); } } }
 - 
					
					
					
					
macht ihr eigentlich unterschiede je nach sprache ?
zb csharp so, java so und cpp wieder anders ?
 - 
					
					
					
					
also ich nicht

auser ich muss VB zwangsweise was Programmieren da gibts ja keine klammern und es ist eig. vorgeschrieben wo man was hinsetzen muss

 - 
					
					
					
					
Ich auch nicht.
 - 
					
					
					
					
Ich bevorzuge Variante 2 - netterweise ists bei uns auch Firmenstandard. Dazu kommen noch andere Klammersetzungsrichtlinien:
//Funktionsaufrufe und Deklarationen ohne blank: foo(); //conditionals immer mit blank: if (not false) { /*...*/ } while (1) { //Auch bei Einzeilern gleich Blockklammern einzeiler(); }
 - 
					
					
					
					
pumuckl schrieb:
Ich bevorzuge Variante 2 - netterweise ists bei uns auch Firmenstandard. Dazu kommen noch andere Klammersetzungsrichtlinien:
//Funktionsaufrufe und Deklarationen ohne blank: foo(); //conditionals immer mit blank: if (not false) { /*...*/ } while (1) { //Auch bei Einzeilern gleich Blockklammern einzeiler(); }^^finde ich gut. ich mach's nämlich genau so. nur bei den kommentaren hab' ich zwischen '//' und dem eigentlichen text auch ein leerzeichen.

 - 
					
					
					
					
pumuckl schrieb:
while (1) { //Auch bei Einzeilern gleich Blockklammern einzeiler(); }Das ist bei uns zwar kein Standard, ich finde es aber (für mich selbst) für die Übersicht unbedingt nötig. Denn so eine Ein-Zeilen-Verzweigung/-Schleife übersehe ich dann beim überfliegen doch eher, als einen schönen Block.
 - 
					
					
					
					
pumuckl schrieb:
while (1) { //Auch bei Einzeilern gleich Blockklammern einzeiler(); }
 - 
					
					
					
					
_matze schrieb:
Denn so eine Ein-Zeilen-Verzweigung/-Schleife übersehe ich dann beim überfliegen doch eher, als einen schönen Block.
Ich finde solche Konstrukte die Hölle...
if(a == b) return;Die Klammersezung lasse ich in der Regel auch nur noch weg wenn alle Zweige Einzeiler sind...
if(/*Bedingung1*/) /*Einzeiler*/; else if(/*Bedingung1*/) /*Einzeiler*/; else /*Einzeiler*/;Ich gebe dir aber Grundsätzlich recht: Im Zweifel das eine Klammernpaar "zuviel" als zuwenig

 - 
					
					
					
					
und wie sehr ihr das mit diesem hier?
public Prop { get { return _prop; } set { _prop = value; } }bevorzugt ihr dort auch die laengere variante?
 - 
					
					
					
					
Mr Evil schrieb:
bevorzugt ihr dort auch die laengere variante?
Nein (wenn gleich C#). Bei trivialen Properties verwende ich auch den Einzeiler. Ich sehe hier aber ein Unterschied zum Programmablauf und einer einzelnen trivialen Getter/Setter. Wobei ich in einen solch trivialen Fall eh...
public Prop{get; set;}...schreiben würde.
cu André
 - 
					
					
					
					
asc schrieb:
Mr Evil schrieb:
bevorzugt ihr dort auch die laengere variante?
Nein (wenn gleich C#). Bei trivialen Properties verwende ich auch den Einzeiler. Ich sehe hier aber ein Unterschied zum Programmablauf und einer einzelnen trivialen Getter/Setter. Wobei ich in einen solch trivialen Fall eh...
public Prop{get; set;}...schreiben würde.
cu André
geht nur nicht immer
public Len { get { return _prop.len; } private set { _prop.len; } }aber sonst - wenns nur n billiger holder is nehm ich auch die kurze get; set; schreibweise