PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Glaubensfrage: { hoch oder runter?


darph
2005-09-17, 02:03:01
Auswahl eins:

function blah() {
// ...
}

oder Auswahl zwei:

function blah()
{
// ...
}

und warum?

Silpion
2005-09-17, 02:12:39
Auswahl eins, weil Eclipse es so vorschlägt und ich zu faul bin, die Entertaste zu drücken.

Oliver_G
2005-09-17, 02:17:15
#2 :)
Weil der Aufbau mir dann besser erscheint...

"Überschrift"
Anfang
...
Ende

Pinoccio
2005-09-17, 02:18:02
Die JAVA Code Convention (http://java.sun.com/docs/codeconv/html/CodeConventions.doc5.html) sagt 1 ... und daran glaube ich!

mfg Sebastian

M@tes
2005-09-17, 02:18:33
1. Hat sich so eingebürgert.
Spart man sich unnötig viele neue Zeilen ein.

darph
2005-09-17, 02:24:37
Es stimmt, daß die Java Code Conventions das vorschlagen. Aber ich persönlich halte das für eine krasse Fehlentscheidung.

Meiner Ansicht nach sollten die Klammern in den gleichen Spalten stehen, um so eine direkt ersichtliche Navigation zu ermöglichen. Nicht jeder Code Editor zieht Linien am Rand wie wie Eclipse.

(In Java schreib ich aber auch nach den JCC :usad: - in PHP aber nicht! http://forum.darph.net/images/smiles/icon_evillaugh.gif)

Pinoccio
2005-09-17, 02:30:31
Meiner Ansicht nach sollten die Klammern in den gleichen Spalten stehen, um so eine direkt ersichtliche Navigation zu ermöglichen. Nicht jeder Code Editor zieht Linien am Rand wie wie Eclipse.Versteh ich nicht, dafür rückt man doch ein, oder? Sample(int i, int j) {
ivar1 = i;
ivar2 = j;
}/edit: OT: Die Gewohnheit ist auch bei mir relativ stark, in manchen Sachen stärker als die JCC, ich mache immer eine Leerzeile nach der Funktionsdeklaration (oder wie immer declaration statement auch sonst genannt werden mag).

mfg Sebastian

Sephiroth
2005-09-17, 02:33:56
Variante 1

Warum? hm, es gefällt mir einfach besser und es ist 'ne Zeile weniger ;D

das gilt freilich auf für if then else konstrukte
if () {
foo
} else {
bar
}

und einrücken mit je einem tab sowieso

darph
2005-09-17, 02:34:23
Versteh ich nicht, dafür rückt man doch ein, oder?
mfg Sebastian
Ich find das:
Sample(int i, int j)
{
ivar1 = i;
ivar2 = j;
}
Dennoch übersichtlicher. Insbesondere, weil der automatische Stylechecker vom Programmierpraktikum zwingend eine Leerzeile nach der Funktionendeklaration verlangte.

Pinoccio
2005-09-17, 02:40:54
Ich find das:
Beispiel 2Dennoch übersichtlicher. Insbesondere, weil der automatische Stylechecker vom Programmierpraktikum zwingend eine Leerzeile nach der Funktionendeklaration verlangte.Siehe mein edit oben, mag ich auch.
Bei einem Programmierpraktikum allerdings Vertsöße gegen die JCC zu verlangen, hui ...
(nochmehr ot: siehste, deinen Code muß ich mir endlich mal angucken!)

mfg Sebastian

Coda
2005-09-17, 03:10:23
Ich hab früher 2 gemacht, inzwischen aber 1 weil es den Code verkürzt. Ist aber Geschmackssache. Weniger lesbar ist es auf jedenfall nicht.

Gnafoo
2005-09-17, 05:16:38
Variante 2

Habe früher Variante 1 benutzt, aber inzwischen finde ich 2 übersichtlicher und auch irgendwie gleichmäßiger. Bei der direkt anschließenden geschweiften Klammer ergeben sich manchmal mehrere lange Zeilen direkt hintereinander und dann durch die abschließenden Klammern am Ende natürlich ein Leerraum, der vorne nicht da ist. Das sieht so unausgeglichen aus :D. Also z.B.:


blubb();

if(blah(blubb(bla()))) {
if(foo() + bar() >= 5 && x<12) {
call_blah(blubb->miregal(uswduweißtwasichmeine));
}
}
else
if(foo()) {
// ...
}

blah();


Mit der geschweiften Klammer in einer einzelnen Zeile find ichs besser (und auch irgendwie konsequenter) ;).

Was die eine Zeile mehr Platz angeht .. die opfere ich gerne der Übersicht. Außerdem ist es sowieso völlig egal, ob das jetzt 15 oder 10 Zeilen sind imho. Aber naja ist eben letztlich Geschmackssache.

Coda
2005-09-17, 06:01:38
Wenn nur eine Anweisung hinter dem if steht lass ich die Klammer ganz weg

zeckensack
2005-09-17, 06:25:47
2

Wenn ich für die schließende Klammer eine eigene Zeile reserviere, dann sollte ich das IMO konsequenterweise auch für die öffnende Klammer tun.

Ich weiß auch nicht was die JCC-Erfinder sich dabei gedacht haben.
Wenn nur eine Anweisung hinter dem if steht lass ich die Klammer ganz wegIch auch. Oder gar so:if (key>mid_key) left=mid+1;
else right=mid;

ScottManDeath
2005-09-17, 07:06:21
2.

Obwohl Steve McDonnel in Code Complete 1 und 2 argumentiert dass 1 übersichtlicher sei und durch die Formatierung den Codefluss besser verständlich machen kann.

Ich persönlich finde dass man bei 2. besser sieht, dass die Zeilen alle in einem Block sind und gemeinsam nacheinander ausgeführt werden.

mithrandir
2005-09-17, 08:05:18
Dere!

Ich finde ebenfalls, dass man mit Variante 2 die Klammern in fast jedem Editor besser zuordnen kann, man muss sich ja "nur" eine gedachte Linie ziehen (z.B. wenn man in sehr vielen verschachtelten Ebenen ist, dann finde ich Variante 1 extrem unübersichtlich).

bye, Peter

Chris Lux
2005-09-17, 09:20:21
variante 2, will das mal mit dem vorangegangenen beispiel verdeutlichen.

if () {
foo
} else {
bar
}

und einrücken mit je einem tab sowieso

stellt euch hier mal mehr code bei den if und else verzwigungen vor. beim lesen des codes ist dann nicht mehr ganz so klar wo hier was anfängt, denn die zweite } verwirrt, weil wenn mal nach oben schaut gleich wieder eine weitere } sieht.

zum tab ;) ist vielleicht auch glaubensfrage, ich setze lass immer einen tab durch 4 space ersetzen.

Binaermensch
2005-09-17, 09:28:56
Ich nutze Variante 1.

Grund: Der Quellkode benötigt weniger Platz.
Weniger Platz --> ich muss nicht so viel Scrollen --> hab mehr Kode im Sichtfeld --> übersichtlicher.

clm[k1]
2005-09-17, 10:46:18
variante 2, will das mal mit dem vorangegangenen beispiel verdeutlichen.


stellt euch hier mal mehr code bei den if und else verzwigungen vor. beim lesen des codes ist dann nicht mehr ganz so klar wo hier was anfängt, denn die zweite } verwirrt, weil wenn mal nach oben schaut gleich wieder eine weitere } sieht.


Das Beispiel ist IMO blöd - ich finde, das else gehört in eine eigene Zeile und nicht direkt hinter die schließende geschweifte Klammer!
Denn dann ist auch eindeutig zu erkennen, das die andere zu dem else gehört!

Ich nutze übrigens auch Variante 1. Abgesehen davon das die JCC es vorschreibt, finde ich es auch besser lesbar.


clm[k1]

Senior Sanchez
2005-09-17, 11:03:42
Ich nutze auch Variante 1 :) geht einfach schneller von der Hand nen Leerzeichen zu drücken und dann die Klammertaste anstatt erst enter (dummerweise vllt noch einrücken *lol*) und dann die Klammer.
Nen Leerzeichen mache ich wie man sieht auch nem dem Methodenkopf ;)


Wenn nur eine Anweisung hinter dem if steht lass ich die Klammer ganz weg

ui, da habe ich mir angewöhnt gerade so etwas nicht zu machen. Klar es spart platz, aber wenn man später mal die if-Anweisung erweitert und nicht darauf achtet kann man sich später tot suchen um den Fehler zu finden, dass die hinzugefügten Anweisungen nicht mehr zum if-Construct gehören.

The_Invisible
2005-09-17, 11:25:42
Beispiel 2, ist einfach übersichtlicher bei vielen else/if/while/for anweisungen, außerdem hat sich das bei uns (firma) so eingebürgert... hatte anfangs aber auch Variante 1 benutzt, wurde mir aber mit der zeit zu unübersichtlich

mfg

M@tes
2005-09-17, 11:29:50
Ich fasse zusammen:
Versteh ich nicht, dafür rückt man doch ein, oder?
Denke ich auch,...

Außerdem ist es sowieso völlig egal, ob das jetzt 15 oder 10 Zeilen sind
Bei paar Hundert oder paar Tausend, wirst du das aber nicht mehr sagen :wink:

Ich finde ebenfalls, dass man mit Variante 2 die Klammern in fast jedem Editor besser zuordnen kann, man muss sich ja "nur" eine gedachte Linie ziehen (z.B. wenn man in sehr vielen verschachtelten Ebenen ist, dann finde ich Variante 1 extrem unübersichtlich).
Stimmt, aber dank Tabs kein Problem :smile:

if () {
foo
} else {
bar
}
Sieht shcick aus, aber übersichtlich is es für mich nicht wirklich.

Weniger Platz --> ich muss nicht so viel Scrollen --> hab mehr Kode im Sichtfeld --> übersichtlicher.
Du bringst es auf den Punkt. In etwa das meinte ich gestern mit mieinem Post.

Also ich bleib dabei =)
Bisher gings so wunderbar,...

ScottManDeath
2005-09-17, 12:10:47
Ich nutze auch Variante 1 :) geht einfach schneller von der Hand nen Leerzeichen zu drücken und dann die Klammertaste anstatt erst enter (dummerweise vllt noch einrücken *lol*) und dann die Klammer.
Nen Leerzeichen mache ich wie man sieht auch nem dem Methodenkopf ;)


Die IDE meines Vertrauens erstellt automatisch bei if, switch ... den Rumpf mit den eine Zeile tiefer liegenden, eingerückten Klammern. =)

Marscel
2005-09-17, 13:16:48
Methode 2.

In meinem Notepad++ sieht das einfach übersichtlicher aus, wenn die Klammern untereinander stehen und wenn ich mich um eine Klammer vertue, seh ich schneller, wo.

Senior Sanchez
2005-09-17, 14:00:21
Die IDE meines Vertrauens erstellt automatisch bei if, switch ... den Rumpf mit den eine Zeile tiefer liegenden, eingerückten Klammern. =)

Isch weiß, meine (JBuilder) machts ja auch und ich nutze auch eclipse, das es eigentlich auch macht, nur manchmal funzt es da nicht so wirklich.

TheFallenAngel
2005-09-17, 14:12:21
Variante 1

braucht weniger platz und ich finde es übersichtlicher...

5tyle
2005-09-17, 15:02:54
tendenziell Variante 1 weil mir das von eclipse so eingeimpft wurde.

allerdings lohnt sich bei extrem verschachtelten Blocks Variante 2.

MadMan2k
2005-09-17, 17:07:01
[x] was anderes


def blah():
# ...


:D

ansonsten variante 1, da eclipse

GloomY
2005-09-17, 17:58:08
Ich benutze durchgängig Version 1.

Die Linux Kernel Coding Conventions schreiben eigentlich bis auf Funktionen Version1 vor. Gerade bei diesen soll aber Version 2 verwendet werden.

edit: Vielleicht ganz interessant: http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#Variation:_Original_K.26R_.2F_Linux

The_Invisible
2005-09-17, 18:58:56
[x] was anderes


def blah():
# ...


:D

ansonsten variante 1, da eclipse

naja, in Python gibts in dem sinne gar keine klammern

geht in php auch mit:


if(bla=blabla):
# ...
endif;


mfg

Metzler
2005-09-17, 20:06:37
Variante 2. Finde ich schlichtweg übersichtlicher und logischer.

Wenn ich Code kriege, der mit Variante 1 geschrieben wurde, formatiere ich erstmal rigoros um :upara:

Coda
2005-09-17, 20:16:17
ui, da habe ich mir angewöhnt gerade so etwas nicht zu machen. Klar es spart platz, aber wenn man später mal die if-Anweisung erweitert und nicht darauf achtet kann man sich später tot suchen um den Fehler zu finden, dass die hinzugefügten Anweisungen nicht mehr zum if-Construct gehören.Ich kann mich nicht daran erinnern, dass mir das mal passiert ist. Gewohnheitssache...

Senior Sanchez
2005-09-17, 20:29:19
Ich kann mich nicht daran erinnern, dass mir das mal passiert ist. Gewohnheitssache...

Das ist mir schon passiert, was aber auch eclipse zuzuordnen ist, dass den Code schlichtweg so schlecht eingerückt hat, sodass es aussah, als gehöre diese Anweisung noch zum if. Syntaktisch gesehen tats das aber nicht.

ethrandil
2005-09-17, 20:56:02
Ganz füher mal #2, weil das in meinem ersten c++-Buch so war.
Inzwischen aber #1, weil das in der JavaCodeConvention so ist und das hat sich eingebürgert...

- Eth

Matrix316
2005-09-17, 21:00:05
2 weil übersichtlicher

ScottManDeath
2005-09-17, 23:39:56
In einer idealen Welt gibts IDEs die den Code entsprechend den Wünschen des Nutzers darstellen.

IMHO sollte man vielleicht mal drüber nachdenken den Code nicht als plain text sondern als Dokument zu speichern und dem Nutzer die Möglichkeit geben den Code darzustellen wie er es gerne hätte.

RMC
2005-09-18, 00:21:20
Das mit der Platzverschwendung ist purer Bullshit ;) Im Prinzip könnte man alles auch einfach in einer Zeile schreiben und fertig.
Jedenfalls find ich Übersichtlichkeit wesentlich sinnvoller und effektiver als die paar Zeilen mehr Text.


Ich weiß, dass die Coding Conventions die erste Methode vorschlagen. Doch ich hab mir seit Anfang an zweiteres angewöhnt, weil ich es hasse wenn die Klammern nicht untereinander stehen. Ich für meinen Teil muss immer suchen und find es wesentlich übersichtlicher, wenn ich auf den ersten Blick feststellen kann, wo ein Block auf und zu geht...dadurch dass sie untereinanderstehen ensteht für mein optisches Feingefühl erst tatsächlich ein "Block", weil alles am linken Rand ausgerichtet ist.


EDIT

bei SOLCHEN und ähnlichen Konstrukten kommt mir einfach das pure Grausen:


if () {
foo
} else {
bar
}


1. Klammer in derselben Zeile wie die Bedingung
2. Nicht eingerückt (1x Tab = 2 Space im Normalfall)
3. Else nicht unter der Klammer, sondern in derselben Zeile

Lesbarkeit = null;


if()
{
foo
}
else
{
bar
}



Lesbarkeit = "perfekt";

HellHorse
2005-09-18, 00:53:50
In einer idealen Welt gibts IDEs die den Code entsprechend den Wünschen des Nutzers darstellen.
google fand auf Anhieb das:
http://jalopy.sourceforge.net/
Keine Ahnung ob das was taugt.

Bei der bösen, gehypten IDE kann man ja sehr genau einstellen, wie sie den Code formattieren soll, aber sie macht das afaik nicht automatisch wenn man z.B. Code aus CVS auscheckt.

IMHO sollte man vielleicht mal drüber nachdenken den Code nicht als plain text sondern als Dokument zu speichern
Ja, das ist wirklich alles andere als ideal. Auch so Sachen wie Versionskontrolle profitieren ja schon extrem davon wenn die versionierte Einheit nicht ein Textfile, sondern eine Methode ist. Da gibt's noch sehr viel Raum für Verbesserungen.

und dem Nutzer die Möglichkeit geben den Code darzustellen wie er es gerne hätte.
Ja, eigentlich könnte man den Sourcecode als Syntaxtree speichern und dann bloss pretty-printen. Man müsste den pretty printer ensprechend gut anpassen können, aber ansonsten sollte das kein Problem sein.
Ich habe auch mal einen Artikel gelsen von Typen, die Code als XML (:ugly:) speichern wollen und dann theoretisch allen möglichen Code daraus generieren können (Java, C++, LISP, Python, ...). Finde aber gerade den Link nicht mehr und das war alles bloss ein Gedankenexperiment.

DR.DEATH
2005-09-18, 01:01:07
Also ich bevorzuge auch Variante 1.

Es ist auch nur subjektives Empfinden aber ich finde es uebersichtlicher. Wenn ich z.B. von Kollegen Code in Variante 2 bekomme, dann verwirrt mich das nur.

Kinman
2005-09-18, 01:01:16
Variante 2. Finde ich schlichtweg übersichtlicher und logischer.

Wenn ich Code kriege, der mit Variante 1 geschrieben wurde, formatiere ich erstmal rigoros um :upara:

Ich machs genauso...
Ich kanns net ausstehn wenn die { oben steht...

mfg Kinman

Neomi
2005-09-18, 02:03:08
Ich machs genauso...
Ich kanns net ausstehn wenn die { oben steht...

Dito! Und ich bin wirklich froh, daß die anderen beiden Programmierer in der Firma auch auf Variante 2 setzen.

Crushinator
2005-09-18, 04:18:45
Dito! Und ich bin wirklich froh, daß die anderen beiden Programmierer in der Firma auch auf Variante 2 setzen.
Mir ist es egal, wer bei uns in der Firma welche Variante bevorzugt. Ich ersetze, wenn ich auf Variante 1 stoße und in dem Codeabschnitt was ändern muß, alles in Variante 2. :D

Coda
2005-09-18, 09:48:30
http://home.arcor.de/aexorzist/popcorn.gif

ScottManDeath
2005-09-18, 10:02:41
google fand auf Anhieb das:
Ja, eigentlich könnte man den Sourcecode als Syntaxtree speichern und dann bloss pretty-printen. Man müsste den pretty printer ensprechend gut anpassen können, aber ansonsten sollte das kein Problem sein.
Ich habe auch mal einen Artikel gelsen von Typen, die Code als XML (:ugly:) speichern wollen und dann theoretisch allen möglichen Code daraus generieren können (Java, C++, LISP, Python, ...). Finde aber gerade den Link nicht mehr und das war alles bloss ein Gedankenexperiment.

Das Code Document Model von .NET bietet sowas in Ansätzen. Man kann einen Syntaxtree bauen (oder parsen lassen) und dann von verschiedenen Sourcegeneratoren übersetzen lassen. AFAIK wird das von den ganzen VS GUI Editoren verwendet, wie generell das ist weiß ich nicht. Wenn das VS 2k5 da ist (mit .NET 2.0) werde ich vielleicht mal damit vertieft rumspielen.

Es könnte bei sowas auch zum Problem werden dass man ein Subset für alle Sprachen finden muss, welches im Syntaxtree gespeichert werden aokann/muss.

HellHorse
2005-09-18, 11:25:22
Es könnte bei sowas auch zum Problem werden dass man ein Subset für alle Sprachen finden muss, welches im Syntaxtree gespeichert werden aokann/muss.
Sicher ist das ein Problem. Man muss ja einen Subset Tree in einen Superset Tree transformieren und zurück. Dabei müssen sowhol Transformation wie Rücktranformation eindeutig sein, obwohl ein Superset Element eventuell auf mehrere Subset Elemente abgebildet wird.
Je mehr Features eine Sprache hat und je komplizierter sie, desto schwieriger wird das. Das ist aber eigentlich bei allen Code Tools so.
Schon bei so banalen Sachen wie unterschiedlichen Keywords kanns schon nicht mehr gehen.
Mir ist unklar wie man eine Sprache mit Mehrfachvererbung und eine ohne unter einen Hut bringen will. Vor allem mit einem Subset der Sprache mit Einfachvererbung. Darum halte ich von Sprachunabhängigkeit in der Praxis nichts.

Kinman
2005-09-18, 13:11:23
Ich glaube auch nicht, das es jemals eine vollkommende Sprachunabhängigkeit gibt. Aber es würde mehrere "Schreibstile" ermöglichen. z.B: if then else endif oder if() {} else {}

Und das wäre an und für sich ja net schlecht. Vor allem wenn man den Source eben in seinem Stil Pretty Printen könnte...

mfg Kinman

Xmas
2005-09-18, 20:24:52
Eigentlich alle drei:
- Variante 1 in Java für alles, in C/C++/C# für Arraydefinitionen, in Python für Dictionary-Definitionen
- Variante 2 in C/C++/C# für Struktur
- und für Python Codestruktur nur Einrückung ohne Klammern, und immer mit 4er-Tabs.

SgtTynis
2005-09-19, 08:36:15
Variante 2, sowohl in C/C++ als auch C#. Variante 1 nur in den seltenen Faellen in denen ich was in Java verfasse.

Ganon
2005-09-19, 10:20:12
Ich halte mich eigentlich an diese hier:

http://webkit.opendarwin.org/blog/?page_id=25

;) In der Firma haben wir

if then
else
endif

Da gibt's kein "Klammergemecker". ;)

noid
2005-09-19, 10:41:05
früher 2
heute 1

-> beim ausdrucken nervig, die ides die ich habe hebens mir hervor.

Hucke
2005-09-19, 11:56:32
Variante 2.

Bei mir aus Tradition, da damals Source im guten Borland Turbo C IDE nicht sonderlich gut lesbar war, dank meiner Herkules Karte. Mit modernen IDEs ist es eigentlich wurscht.

Fruli-Tier
2005-09-24, 12:42:10
if()
{
foo
}
else
{
bar
}



Lesbarkeit = "perfekt";

:massa:


Planlos wie ich bin habe ich zwar [1] gewählt, meine aber [2] :ulol3:

Gast
2005-09-24, 13:00:15
2
Imho übersichtlicher

Gast
2005-09-24, 14:40:29
Ich mache es meistens sogar noch anders:


function schroecklichfein() {
int einrueck;
String donaudampfschiffbeschreibungstextgroesseohnestilangabe; }


-> Gliederung alleine durch Einrücken und Klammerung Marke Zeilen-Spar(tm).

Ansonsten aber Variante 1 und Variante 2 eigentlich niemals (mehr).

HajottV
2005-09-24, 14:54:25
Beides. Methode 2 für Klasse, Methoden...


//////////////////////////////////////////////////
int
function blah()
//////////////////////////////////////////////////
{
// ...
}


Methode 1 für alles andere:


if (blah) blah;
else blah;

if (blah) {
blah;
blah;
} // if (blah) { ... }



Die Art der Formatierung ist aber nicht soooo wichtig, solange sie konsequent ist. Guten Code kann man auch dann lesen, wenn die Formatierung nicht den eigenen Vorlieben entspricht.

Ich habe immer wieder die Erfahrung gemacht, daß schlampig formatierter Code (= mal hü mal hott formatiert) in der Regel auch inhaltlich schlampig ist. Wer auf seinen Code Wert legt, legt auch Wert darauf, daß er gut aussieht.

Gruß

Jörg

SgtTynis
2005-09-24, 16:18:20
Auch wenn ich wie oben schon geschrieben die Variante 2 bevorzuge, gibt es gerade in C# oftmals Einzeiler, die schreib ich dann so:

get { return blabla; }

Alles andere wuerde zu sehr in Prosa ausarten.

zeckensack
2005-09-25, 15:55:11
Auch wenn ich wie oben schon geschrieben die Variante 2 bevorzuge, gibt es gerade in C# oftmals Einzeiler, die schreib ich dann so:

get { return blabla; }

Alles andere wuerde zu sehr in Prosa ausarten.Bei Inline-Definitionen direkt in der Klassendeklaration mache ich auch manchmal solche Sachen.
Allerdings halte ich übermäßigen Einsatz von Inline-Member-Funktionen für schlechten Stil :|
Dh es muss einen wirklich guten Grund dafür geben, sonst verkneife ich mir das nach Möglichkeit.

FireFrog
2005-09-25, 16:28:52
#2 :)
Weil der Aufbau mir dann besser erscheint...

"Überschrift"
Anfang
...
Ende
find ich auch

Xmas
2005-09-26, 00:02:41
Bei Inline-Definitionen direkt in der Klassendeklaration mache ich auch manchmal solche Sachen.
Allerdings halte ich übermäßigen Einsatz von Inline-Member-Funktionen für schlechten Stil :|
Dh es muss einen wirklich guten Grund dafür geben, sonst verkneife ich mir das nach Möglichkeit.
Wäre die Einschränkung, dass viele Programmiersprachen wie z.B. C# und Java Methodendefinitionen außerhalb der Klassendeklaration überhaupt nicht zulassen, ein guter Grund für dich? ;)
Braucht man auch nicht, weil man keinen Header-Mist zum Interface-Deklarieren mehr braucht.

ScottManDeath
2005-09-26, 00:16:38
Wäre die Einschränkung, dass viele Programmiersprachen wie z.B. C# und Java Methodendefinitionen außerhalb der Klassendeklaration überhaupt nicht zulassen, ein guter Grund für dich? ;)
Braucht man auch nicht, weil man keinen Header-Mist zum Interface-Deklarieren mehr braucht.


Jo, das macht das Entwickeln etwas fixer, da man nicht dauern .h und .cpp synchron halten muss. Mal schnell eine Methode eingefügt, oder die Signatur geändert ist einfacher wenn man nur eine Stelle hat.

Ich ertappe mich dabei, auch in C++ alles in den Header zu stecken (bei Templates gehts ja nicht anders). Allerdings wirks sich das irgendwann negativ auf die Compilierzeiten aus. Gibts da ein Tool welches automatisch die Implementation aus der .h Datei in die .cpp verschiebt?

ravage
2005-09-26, 10:39:31
Damals zu C++ Zeiten in der Schule Variante 2

Nachdem ich mir dann PHP und (vor kurzem ) etwas Java beigebracht habe, bin ich zu Variante 1 gewechselt. Ich finde diese Variante sehr übersichtlich, und ich achte eigentlich sehr darauf, dass mein Code auch gut "aussieht".

Ist halt Gewöhnungssache.

Gast
2005-10-11, 11:22:20
Ich hab auch einen:
Egal ob Variante 1 oder 2 beim Eintippen(oder überhaupt keine), aber danach:

astyle --style=ansi --indent=tabs=2 quellcode.c

Drexel
2005-10-11, 14:10:53
2. Find ich einfach überischtlicher, so kann ich schneller überblicken, wo ich eine Klammer vergessen habe :)

The Tank
2005-10-11, 17:33:28
definitiv no 2!

Früher oder später wird man bei 1 'Probleme' haben.
Wer so ein guter Programmierer ist und beim ersten anhieb alles richtig macht, der kann ohne Bedenken 1 nehmen. Nur für die restlichen 99.99% von uns empfehle ich 2.
Zuoft habe ich, auch bei guten Programmierern, fehler gesehen die dadurch entstanden.

Leserlichkeit ist das A und O eines Programmierers.
Nicht faulheit.

Baalzamon
2005-10-11, 18:16:37
[x] Variante 2.

Früher Variante 1, aber das hat sich dann ganz schnell geändert, als ich einen Editor ohne Syntax-Highlightng benutzen musste. Dazu kamen noch viele Bedingungen und aus wars mit der Lesbarkeit.

Seitdem immer Klammern in einer eigenen Zeile und untereinander. Selbst bei einzeiligen Ausdrücken wird so geklammert, da ich schon viel zu oft so Fehler suchen musste.

MaRs
2005-10-12, 01:03:03
1, 2 ist platzverschwendung und für die übersicht nicht nötig.

Korrom
2005-10-12, 17:56:40
Variante 2, weil es übersichtlicher ist und weil die Variante 1 meinem ästhetischen Anspruch zuwider geht. Der erhöhte Platzbedarf von (2) ist mir schnurz.

Michbert
2005-10-12, 19:41:43
Mhm, das is so ne Sache, denke ich mir - Eine Zeile Anfang, Eine Zeile Ende - dann is es Variante 1, denk ich mir - Eine Zeile für jede Klammer und dann auch genau untereinander, dann eher Variante 2.
Da ich aber finde das 1 besser aussieht und auch weniger platz brauch verwende ich das eigentlich öfters.
Da man in der Firma bei der ich gelegentlich arbeite variante 2 vorzieht, is es mir eigentlich völlig egal wie Hauptsache innerhalb eines Projekts wird eine Variante eingehalten...

Ajax
2008-12-08, 13:44:32
Variante 2, da ich leichter die dazugehörigen Klammern finde. :usad:

daflow
2008-12-08, 14:00:26
Natürlich 2 :| Zusammengehörige Klammern immer auf selbe Höhe (y)

Monger
2008-12-08, 14:04:22
Ajax, du Leichenschänder! ;)

Ich finde die Diskussion ehrlich gesagt lächerlich. Das ist so, als würden zwei Poeten sich darüber unterhalten ob man nach fünf oder nach sieben Wörtern einen Zeilenwechsel machen sollte.

Wann ich welche Notation benutze, hängt doch ganz wesentlich davon ab welches Layout der Inhalt diktiert.
Ein

public String get(){ return MySpecialValue };

liest sich als Einzeiler super. Das Ding über vier Zeilen zu schmieren, stört unnötig den Lesefluss.
Hier dagegen:

public String getSpecialValue(String key, String value, String specialFormatter){ return MySpecialValue(key, value, specialFormatter); }

liest sich nicht nur scheußlich, sondern widerspricht auch allen Lesegewohnheiten. In solchen Fällen will man dann auf jeden Fall Signatur und Methodeninhalt optisch voneinander abtrennen.

Dazu kommt natürlich noch, was der aktuelle Editor einem nahelegt.
Aber letztendlich: viel wichtiger als dass es einheitlich ist, ist doch dass es LESERLICH ist!
Und nein, das ist nicht in allen Fällen das selbe! ;)

Unfug
2008-12-08, 14:04:52
1. Bei Java
2. Bei .NET

Crazy_Chris
2008-12-08, 14:15:39
2 !!!!!!!!11111111 natürlich :smile:

_Gast
2008-12-08, 14:28:35
Ich verwende eine Mischung aus dem BSD-Stil (http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#Allman_.2F_BSD_.2F_.E2.80.9EEast_Coast.E2.80.9C_.2F_Horstma nn) und dem GNU-Stil (http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#GNU-Stil). Übersichtlicher für mich ist es, wenn zugehörige Klammern untereinander stehen.int f(int x, int y, int z)
{
if (x < foo(y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo(z, z);
z--;
}
return ++x + bar();
}
}

noid
2008-12-08, 15:03:19
Ich verwende eine Mischung aus dem BSD-Stil (http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#Allman_.2F_BSD_.2F_.E2.80.9EEast_Coast.E2.80.9C_.2F_Horstma nn) und dem GNU-Stil (http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#GNU-Stil). Übersichtlicher für mich ist es, wenn zugehörige Klammern untereinander stehen.int f(int x, int y, int z)
{
if (x < foo(y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo(z, z);
z--;
}
return ++x + bar();
}
}

Das nach dem if ist ziemlich böse. Und wenn da nichts stehen würde -> Klammern.

_Gast
2008-12-08, 15:13:52
Das nach dem if ist ziemlich böse. Und wenn da nichts stehen würde -> Klammern.Es gehört nicht zu meinem Programmierstil, einer if-Anweisung nichts folgen zu lassen. Welchen Sinn hätte das? Außerdem würde ich das dann so lösen:if (x < foo(y, z));
else
{Oder meintest du was anderes?

noid
2008-12-08, 18:49:28
Es gehört nicht zu meinem Programmierstil, einer if-Anweisung nichts folgen zu lassen. Welchen Sinn hätte das? Außerdem würde ich das dann so lösen:if (x < foo(y, z));
else
{Oder meintest du was anderes?

der if-block gehört geklammert, einfach weil bei einem 2tem Statement das Ding Fehler wirft. Liest sich auch schlechter.

SavageX
2008-12-08, 20:37:01
Für mich und meine Augen ganz eindeutig Variante 1. Weniger Zeilenrauschen und das erste, worauf ich stoße, wenn ich von der schließenden Klammer nach oben wandere, ist praktischerweise der erste Buchstabe des blockaufspannenden Befehls.

Geschmackssache.

DanMan
2008-12-08, 20:53:07
Bei wenig Code meistens Variante 1, bei größeren Programmen auch oft Variante 2. Nr1 wird schneller unübersichtlich, spart dafür Platz. Nr2 macht die Verschachtelung deutlicher auf den ersten Blick.

Coda
2008-12-09, 01:21:05
Die Verschachtelung ist ohne weiteres auch sofort an der Einrückung erkennbar.

Metzler
2008-12-09, 09:27:58
@Coda: Ist wohl Geschmackssache, ich zumindest erkenne es nur ordentlich mit Variante 2.

noid
2008-12-09, 10:35:53
Es gehört nicht zu meinem Programmierstil, einer if-Anweisung nichts folgen zu lassen. Welchen Sinn hätte das? Außerdem würde ich das dann so lösen:if (x < foo(y, z));
else
{Oder meintest du was anderes?

Für mich, und auch Andere, sind Blöcke egal wie groß immer mit {} zu versehen. So hat mir das mein alter Infolehrer eingetrichtert, und so macht das Sinn. Zumal ich die Arbeit ja von jeder FeldWaldWiesenIDE gemacht bekomme.

Kleines Beispiel:

if (x < foo(y, z))
do_something_useful();
else
{
do_stupid_stuff();
}


Nun ist aber die Funktion im If-Zweig aber nicht ausreichend bzw wird erweitert wegen irgendwas.

if (x < foo(y, z))
do_something_useful();
do_additional_stuff_here();
else
{
do_stupid_stuff();
}


BÄM!
Hättest du deinen Editor jetzt wie jeder Andere/die Meisten eingestellt, dann wäre _sofort_ sowas dagestanden:

if (x < foo(y, z))
{
do_something_useful();
do_additional_stuff_here();
}
else
{
do_stupid_stuff();
}


Ich nutze die geschweiften Klammern auch als zusätzliche Optische Hilfe. Hab auch schon Stellen im Code wo diese Klammern verwendet werden ohne Bedingung, Schleife etc.

astro
2008-12-09, 10:37:33
[x] eins, weil JCC.

Crow1985
2008-12-09, 10:45:28
[x] Beispiel zwei

weil imo übersichtlicher

Kinman
2008-12-09, 10:46:15
Ich mache das bei Ein-Befehl Blöcken so:


if (x < foo(y, z)) do_something_useful();
else
{
do_stupid_stuff();
}


Somit passiert mir auch kein Unglück.

mfg Kinman

_Gast
2008-12-09, 10:54:11
Für mich, und auch Andere, sind Blöcke egal wie groß immer mit {} zu versehen. So hat mir das mein alter Infolehrer eingetrichtert, und so macht das Sinn. Zumal ich die Arbeit ja von jeder FeldWaldWiesenIDE gemacht bekomme.
...
Ich nutze die geschweiften Klammern auch als zusätzliche Optische Hilfe. Hab auch schon Stellen im Code wo diese Klammern verwendet werden ohne Bedingung, Schleife etc.Deine ganzen Beispiele würden nicht funktionieren, da hinter der if-Anweisung kein Semikolon folgt. Aber ich denke, das ist wohl ein Schreibfehler.

Nichtsdestotrotz ist der Einrückungsstil ohne Klammern bei einzeiligen Anweisungen die empfohlene Schreibart der Free Software Foundation (http://de.wikipedia.org/wiki/Free_Software_Foundation).if (x < foo(y, z))
haha = bar[4] + 5;ist mir halt lieber alsif (x < foo(y, z))
{
haha = bar[4] + 5;
}

Crow1985
2008-12-09, 11:20:42
Oh, nein das kann ich gar nicht ab, wenn man die Klammern nicht setzt.
Auch wenn nur eine einzeilige Anweisung drin steht.

astro
2008-12-09, 11:57:11
Oh, nein das kann ich gar nicht ab, wenn man die Klammern nicht setzt.
Auch wenn nur eine einzeilige Anweisung drin steht.
Genau so mach ich es auch :) Immer Klammern!

noid
2008-12-09, 12:15:31
Deine ganzen Beispiele würden nicht funktionieren, da hinter der if-Anweisung kein Semikolon folgt. Aber ich denke, das ist wohl ein Schreibfehler.

Nichtsdestotrotz ist der Einrückungsstil ohne Klammern bei einzeiligen Anweisungen die empfohlene Schreibart der Free Software Foundation (http://de.wikipedia.org/wiki/Free_Software_Foundation).if (x < foo(y, z))
haha = bar[4] + 5;ist mir halt lieber alsif (x < foo(y, z))
{
haha = bar[4] + 5;
}

ups, c&p... gefixt.

FSF - mir ist egal für was die stehen, und warum. Aber ich hab hier mit Code zu tun, der genau der empfohlenen Schreibart geschrieben ist. Der blanke Horror.
Mit was für einem Editor muss man den Arbeiten, wenn man die Klammern nicht setzt? :rolleyes: ed?

_Gast
2008-12-09, 16:15:20
Mit was für einem Editor muss man den Arbeiten, wenn man die Klammern nicht setzt? :rolleyes: ed?Visual C++ 2008, Visual C++ 6.0, PsPad und Vim (unter Linux).

Crazy_Chris
2008-12-09, 16:20:37
Ich mach es so:

if (a > b)
a = b;
else
a++;

bzw.

if (a > b)
{
a = b;
b++;
}
else
a++;


Ist auch eine Konvention hier in der Firma. (Es wird nur C/C++ verwendet)


Ich mache das bei Ein-Befehl Blöcken so:


if (x < foo(y, z)) do_something_useful();
else
{
do_stupid_stuff();
}


Somit passiert mir auch kein Unglück.

mfg Kinman

Sowas finde ich sehr ungewohnt und auf dem ersten Blick schlecht lesbar.

DanMan
2008-12-09, 18:42:20
Nichtsdestotrotz ist der Einrückungsstil ohne Klammern bei einzeiligen Anweisungen die empfohlene Schreibart der Free Software Foundation (http://de.wikipedia.org/wiki/Free_Software_Foundation).if (x < foo(y, z))
haha = bar[4] + 5;ist mir halt lieber...
Naja, wenns so kurz ist, dann mach ich meist einen kompletten Einzeiler draus:if (x < foo(y, z)) { haha = bar[4] + 5; } Auf geschweifte Klammern verzichte ich grundsätzlich nicht.

noid
2008-12-09, 18:43:18
Naja, wenns so kurz ist, dann mach ich meist einen kompletten Einzeiler draus:if (x < foo(y, z)) { haha = bar[4] + 5; }

wird ja immer besser :|

Mal ernsthaft? Warum fehlt hier die _durchgängig_ ist das nicht was ihr da macht. Insofern erschwert es das Lesen.

DanMan
2008-12-09, 19:21:05
wird ja immer besser :|

Mal ernsthaft? Warum fehlt hier die _durchgängig_ ist das nicht was ihr da macht. Insofern erschwert es das Lesen.
Ich empfinde es eben als übersichtlicher, wenn alles etwas näher beisammen steht, als wenn zig Leerzeichen, -zeilen dazwischen stehen. Wenns mehr als 60 Zeichen werden, dann schreib ich es aber auch untereinander.

Allerdings kann ich es mir auch nicht vorstellen ohne Syntax-Hervorhebung zu programmieren.

Sephiroth
2008-12-09, 23:32:04
Variante 1

Warum? hm, es gefällt mir einfach besser und es ist 'ne Zeile weniger ;D

das gilt freilich auf für if then else konstrukte
if () {
foo
} else {
bar
}

und einrücken mit je einem tab sowieso
bin inzwischen zu Variante 2 (Allman) konvertiert *g*

Kinman
2008-12-09, 23:48:23
Sowas finde ich sehr ungewohnt und auf dem ersten Blick schlecht lesbar.

Kommt auch eher selten vor.
Meist hab ich mehrere Anweisungen im Block oder bei if und else jeweils nur eine Anweisung


if (a == b) foo();
else bar();


mfg Kinman

Oid
2008-12-10, 18:15:42
Bei if, for, etc. Variante 1!

Bei Funktionsdefinitionen Variante 2. Warum? Keine Ahnung xD.

Tesseract
2008-12-10, 20:30:07
früher variante 2 weil ich die eigentlich eleganter finde. inzwischen allerdings 1 weil der code durch die kompaktheit imho besser lesbar bleibt.

zum vergleich:
blah()
{
if (a == b)
{
if(1==2)
{
zomg;
}
}
else
{
for (i=0; i<lol; i++)
{
hallo;
}
}
if (blub)
{
haha;
}
}

blah() {
if (a == b) {
if(1==2) {
zomg;
}
}
else {
for (i=0; i<lol; i++) {
hallo;
}
}
if (blub) {
haha;
}
}

Crazy_Chris
2008-12-10, 20:38:27
früher variante 2 weil ich die eigentlich eleganter finde. inzwischen allerdings 1 weil der code durch die kompaktheit imho besser lesbar bleibt.

zum vergleich:
blah()
{
if (a == b)
{
if(1==2)
{
zomg;
}
}
else
{
for (i=0; i<lol; i++)
{
hallo;
}
}
if (blub)
{
haha;
}
}

blah() {
if (a == b) {
if(1==2) {
zomg;
}
}
else {
for (i=0; i<lol; i++) {
hallo;
}
}
if (blub) {
haha;
}
}

guckst du: :wink:

blah()
{
if (a == b)
{
if(1==2)
zomg;
}
else
{
for (i=0; i<lol; i++)
hallo;
}

if (blub)
haha;
}

Man könnte zwar noch mehr Klammern weglassen aber dann wirds wieder unleserlich finde ich.

noid
2008-12-10, 22:41:52
guckst du: :wink:

blah()
{
if (a == b)
{
if(1==2)
zomg;
}
else
{
for (i=0; i<lol; i++)
hallo;
}

if (blub)
haha;
}

Man könnte zwar noch mehr Klammern weglassen aber dann wirds wieder unleserlich finde ich.

noch mehr? ;(
Brint den Leuten doch nicht so inkonsistente Schreibweisen bei, graysam.

Pinoccio
2008-12-10, 23:12:07
Beim Programmieren geht das ja noch, aber wenn man in Latex größere Gleichungssysteme voll mit Matritzen, Klammern, Brüchen, Sonderzeichen und Wurzeln hat, kommt man imho gaaanz schnell in viel blödere Probleme.
Die Drehmatrix A_lambda mit lambda=30° angewandt auf den normierten Vektor 1/sqrt(6)(1,2,1) ... :-/
Oder schön Gram-Schmidt in vier Dimensionen ...
b_4' &=(~1,~0,~0,~0)^t -\left( 1 \cdot \frac{1}{3}\sqrt{6} + 0 \cdot \frac{1}{6}\sqrt{6} + 0 \cdot 0 + 0 \cdot \frac{-1}{6}\sqrt{6} \right) \cdot \left( \frac{1}{3}\sqrt{6},~\frac{1}{6}\sqrt{6},~ 0 , -\frac{1}{6}\sqrt{6} \right)^t\\\quad & -\left( 1\cdot \frac{1}{6}\sqrt{3} - 0 \cdot \frac{1}{6}\sqrt{3} + 0 \cdot \frac{1}{2}\sqrt{3} + 0 \cdot \frac{1}{6}\sqrt{3} \right) \cdot \left( \frac{1}{6}\sqrt{3}, -\frac{1}{6}\sqrt{3},~\frac{1}{2}\sqrt{3},~\frac{1}{6}\sqrt{3} \right) ^t \\
Und sowas über Zeilen ...

mfg
(sry, sowas stresst mich grade ...)

Gast
2008-12-11, 07:50:12
Beim Programmieren geht das ja noch, aber wenn man in Latex größere Gleichungssysteme voll mit Matritzen, Klammern, Brüchen, Sonderzeichen und Wurzeln hat, kommt man imho gaaanz schnell in viel blödere Probleme.
Die Drehmatrix A_lambda mit lambda=30° angewandt auf den normierten Vektor 1/sqrt(6)(1,2,1) ... :-/
Oder schön Gram-Schmidt in vier Dimensionen ...
b_4' &=(~1,~0,~0,~0)^t -\left( 1 \cdot \frac{1}{3}\sqrt{6} + 0 \cdot \frac{1}{6}\sqrt{6} + 0 \cdot 0 + 0 \cdot \frac{-1}{6}\sqrt{6} \right) \cdot \left( \frac{1}{3}\sqrt{6},~\frac{1}{6}\sqrt{6},~ 0 , -\frac{1}{6}\sqrt{6} \right)^t\\\quad & -\left( 1\cdot \frac{1}{6}\sqrt{3} - 0 \cdot \frac{1}{6}\sqrt{3} + 0 \cdot \frac{1}{2}\sqrt{3} + 0 \cdot \frac{1}{6}\sqrt{3} \right) \cdot \left( \frac{1}{6}\sqrt{3}, -\frac{1}{6}\sqrt{3},~\frac{1}{2}\sqrt{3},~\frac{1}{6}\sqrt{3} \right) ^t \\
Und sowas über Zeilen ...

mfg
(sry, sowas stresst mich grade ...)
Ja gute Frage, wie macht ihr das in LaTeX?
Ich versuch das immer über mehrere Zeilen möglichst logisch aufzuteilen und verwende auch viele Leerzeichen zwischendrin, aber trotzdem kann ich die Formel meistens am nächsten Tag schon nicht mehr lesen. :(

Pinoccio
2008-12-11, 08:28:30
Ja gute Frage, wie macht ihr das in LaTeX?
Ich versuch das immer über mehrere Zeilen möglichst logisch aufzuteilen und verwende auch viele Leerzeichen zwischendrin, aber trotzdem kann ich die Formel meistens am nächsten Tag schon nicht mehr lesen. :(Ich hab mir noch keine gutes System angeeignet. Ich nutze TeXnicCenter (http://www.toolscenter.org/) (allerdings noch die 1 Beta 7.50), was schon sehr komfortabel ist. Größtes Manko für mich ist derzeit, daß ein markierter Absatz durch ein [Tab] überschrieben wird und nicht geschlossen eingerückt wird (wie s z.B. MatLab macht. Da ich im normalen Workflow mehr oder weniger beides parallel benutze, ist das echt nervig.). Auch das Syntax-Highlighting gefällt mir nicht 100%ig. Wenn ich könnte, würde ich alle Klammern, die etwa 70% meiner Fehlersuchzeit ausmachen, knallrot färben. :biggrin:
Ansonstens wirklich viele Leerzeichen und Einrückungen verwenden.

mfg

Kinman
2008-12-11, 08:37:10
blah()
{
if (a == b)
{
if(1==2) zomg;
}
else
{
for (i=0; i<lol; i++) hallo;
}

if (blub) haha;
}


So gefällts mir ^^

mfg Kinman

Crazy_Chris
2008-12-11, 08:50:49
noch mehr? ;(
Brint den Leuten doch nicht so inkonsistente Schreibweisen bei, graysam.

Es ist aber bestens lesbar. :wink:

noid
2008-12-11, 09:20:42
Es ist aber bestens lesbar. :wink:

Für mich nicht. Außerdem ist das in unseren CodingRules auf der Arbeit (weltweit) ein no-go.

Der_Donnervogel
2008-12-18, 00:14:43
Ich verwende die erste Variante, da ich sie übersichtlicher finde. Das ganze ist aber wohl mehr eine Geschmacksfrage. Wenn man sich nicht entscheiden kann man ja immer noch etwas in der Art machen um das Problem zu umgehen: ;D

#define DIM int
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }

void omg() { printf("omg\n"); };
void ups() { printf("ups\n"); };

int main(int argc, char *argv[]) {
DIM a = 2;
DIM b = 3;
DIM c = 4;

IF a == b THEN
IF c > a THEN
omg();
ENDIF
ELSE
ups();
ENDIF

return 0;
}

noid
2008-12-18, 09:30:58
Ich verwende die erste Variante, da ich sie übersichtlicher finde. Das ganze ist aber wohl mehr eine Geschmacksfrage. Wenn man sich nicht entscheiden kann man ja immer noch etwas in der Art machen um das Problem zu umgehen: ;D

#define DIM int
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }

void omg() { printf("omg\n"); };
void ups() { printf("ups\n"); };

int main(int argc, char *argv[]) {
DIM a = 2;
DIM b = 3;
DIM c = 4;

IF a == b THEN
IF c > a THEN
omg();
ENDIF
ELSE
ups();
ENDIF

return 0;
}

Jetzt ist mir schlecht. ;(

Crazy_Chris
2008-12-18, 12:37:41
Jetzt ist mir schlecht. ;(

mir auch. :redface:

Da hat wohl jemand den Absprung von Basic nicht geschafft. :wink:

transstilben
2008-12-18, 14:38:15
Also für mich sieht das aus, als hätte da jemand in seiner Jugend auf einem gängigen Heimcomputer ein wenig programmiert, ist dann unglücklich von einem Lastwagen erfaßt worden und dabei für 20 Jahre ins Coma gefallen und soeben wieder aufgewacht. Das ist nicht böse gemeint, aber ich habe bestimmt seit 20 Jahre kein "DIM" mehr gesehen, deshalb dieser konstruierte Erklärungsversuch.

Gnafoo
2008-12-18, 15:05:41
Nanana... es gibt ja noch Visual Basic .NET. Das hat zwar eine hässliche Syntax, bietet aber im Wesentlichen auch alles, was C# kann (von C# >=3.0 vielleicht mal abgesehen). Insofern würde ich nicht sagen, dass Basic vollständig der Vergangenheit angehört. Mit etwas Umgewöhnung ist es auch nicht viel schlechter oder besser als die anderen .NET-Sprachen. Die Syntax ist eben Geschmackssache, aber letztlich nicht allzu wichtig. Visual Basic .NET (das .NET ist allerdings wichtig :D) ist imho besser als sein Ruf.

Trotzdem wird mir bei dem Codefragment oben schlecht. Immer dieser böse Präprozessor. ;D

Coda
2008-12-18, 16:09:20
Das ist nicht böse gemeint, aber ich habe bestimmt seit 20 Jahre kein "DIM" mehr gesehen, deshalb dieser konstruierte Erklärungsversuch.
In Visual Basic .NET muss man glaube ich alles mit DIM deklarieren ;)

transstilben
2008-12-18, 16:41:38
In Visual Basic .NET muss man glaube ich alles mit DIM deklarieren ;)

Vor 20 Jahren gab es aber noch gar kein Visual Basic ;)

_Gast
2008-12-18, 16:43:34
Vor 20 Jahren gab es aber noch gar kein Visual Basic ;)Stimmt, ist erst gut 17 Jahre her. ;)

Der_Donnervogel
2008-12-19, 04:31:27
Also für mich sieht das aus, als hätte da jemand in seiner Jugend auf einem gängigen Heimcomputer ein wenig programmiert, ist dann unglücklich von einem Lastwagen erfaßt worden und dabei für 20 Jahre ins Coma gefallen und soeben wieder aufgewacht. Das ist nicht böse gemeint, aber ich habe bestimmt seit 20 Jahre kein "DIM" mehr gesehen, deshalb dieser konstruierte Erklärungsversuch.
Das mit dem Heimcomputer stimmt, das mit dem LKW nicht. ;) Ich hab früher wirklich einige Sachen in Basic programmiert. Damals noch in AmigaBASIC am Amiga oder Omicron Basic am Atari, später dann mit VB am PC. Ein Dim hat es aber eigentich immer in einem Basic und es ist auch guter Stil wenn man es verwendet. Bei VB.Net ist es inzwischen per default verplichtend, auch wenn man die Pflicht theoretisch noch ausschalten könnte.
Edit: Was ich wirklich schon ewig nicht mehr gesehen habe, ist etwas in der Art:
DEFINT A-Z

Die Sache mit dem auf Basic-Syntax getrimmten C war aber eine Juxidee die ich mal im Studium hatte. Da hab ich das mal zum Spaß ausgearbeitet, habe es aber natürlich nie wirklich benutzt. Trotzdem muss ich sagen, dass ich die Klammererei mit {} auch nicht übersichtlicher oder angenehmer finde als die Statements bei Basic, eher im Gegenteil. Es ist zwar etwas mehr tipparbeit, aber dafür sieht man besser was los ist. Es gibt ja genug Leute die auch in C oder Java am Ende der Klammern noch hinschreiben was sie schließen, womit man nicht mehr so weit weg von Basic ist. Also Sachen wie

if (a > b) {
for (int i = 0; i < a; i++) {
foo();
} // for
} // if

The_Invisible
2008-12-19, 08:00:58
also ich finds immer geil "VB (.net) vs den rest"

nen größeren glaubenskrieg gibts fast nicht... :D

mfg

Mosher
2008-12-28, 17:23:06
2.
übersicht

THUNDERDOMER
2008-12-28, 20:37:47
Mir ist das egal was ich Programmiere, hauptsache es funktioniert richtig, das ist mir wichtiger als ein Enter weniger oder mehr. :biggrin:

Hm, jeder darf das so entscheiden was übersichtlicher ist oder so. :)

Coda
2008-12-28, 23:15:30
Vor 20 Jahren gab es aber noch gar kein Visual Basic ;)
Er hat auch "seit" geschrieben. In den letzten 20 Jahren hätte ihm durchaus auch mal VB .NET über den Weg laufen können.

Sven77
2008-12-28, 23:53:57
Manchmal bin ich echt froh, nur noch Python benutzen zu müssen X-D

Coda
2008-12-29, 03:53:50
Da streitet man sich dann dafür ob Tabs oder Spaces beim Einrücken ;)

noid
2008-12-29, 11:22:36
Da streitet man sich dann dafür ob Tabs oder Spaces beim Einrücken ;)

Spaces, oder eine Ide, die ein Tab in x Spaces umwandelt - und warum? ;)
Die Frage braucht man nicht wirklich zu benantworten! Achtung ;(

redfox
2008-12-29, 17:20:11
2.

find ich einfach übersichtlicher....

Redfox

Sven77
2008-12-29, 17:36:55
Spaces, oder eine Ide, die ein Tab in x Spaces umwandelt - und warum? ;)
Die Frage braucht man nicht wirklich zu benantworten! Achtung ;(

Weil Python kein Tab erkennt X-D Sorry, musste raus :frown: