Tipps für den Programmieralltag

Peter, ich stimme Dir sowohl bei der Klammerung -- ich denke zwar, die Prioritäten der Bindungen so halbwegs im Kopf zu haben, aber auch bei mir: Lesbarkeit -- zu als auch daß ich die Kiste mit dem Zeile-pro-Parameter fürchterlich finde.

Oh, und in die Falle mit dem vergessenen = bin ich auch das letzte Mal vor Jahren getreten, aber wenn ich wo was vermeiden kann...

Zumal ich mich teilweise auch in anderen Sprachen bewege, in denen nicht kompiliert wird bzw der Compiler nicht so nett ist/sein kann, zu warnen. Also einmal angewöhnt und gut ist.

Na, in deinem Text ist ja nach keiner (mir erkennbaren) Regel umgebrochen worden. Xcode setzt halt die Parameter untereinander. Ich finde das gut nachvollziehbar. Aber vergleiche selbst:

Unendliche Fensterbreite


Umbruch auf linken Rand bei etwa 80 Zeichen:


Parameterumbruch:

BTW: Vorhin überlesen. Nein, bei if( !pointer ) benötigst du keine doppelten Klammern, weil du keine Zuweisung hast. Der Compiler warnt, wenn das Ergebnis einer Zuweisung eine cond-expr ist. Das ist hier nicht der Fall. Der Trick mit den Klammern führt ja einfach dazu, dass nunmehr für den Compiler ein Ausdruck (wegen der Klammern!) zur cond-exrp wird.

Mir fällt da nur noch PHP ein!?
Gibt es noch eine Sprache, die keinen anständigen Zuweisungsoperator hat wie *C*? (Na ja, mancher Basic-Dialekt macht da ganz besondere Sachen …)

Nein, andersrum, sie hat einen vernünftigen Zuweisungsoperator und deshalb ist es blöd, den durch Auslassen eines Zeichens zu verhunzen aber eben nicht gewarnt zu werden.

Javascript beispielsweise. Irgendwie liebe ich Widgets ja. (Auch wenn mich da einiges zur Weißglut bringt.)

Ich meinte Pascal mit :=. Aber du hast Recht, da kann man durch Weglassung des Doppelpunktes auch Schmökes haben. Eigentlich wäre es in dieser Beziehung am praktischsten, wenn alle Zuwesiungs und Vergleichsoperatoren aus mindestens zwei Zeichen bestünden:

:=
==
<=
>=

Dürfte das Problem deutlich verringern. Andererseits: -Wall hilft auch. Seitdem habe ich jedenfalls das Problem nicht mehr.

Original von Tom9811
Unendliche Fensterbreite

Quellcode

1. if( somethingToDo ) {
2. [myTextView insertCompletion:Tom9811 forPartialWordRange:NSMakeRange( 14, 7 ) movement:NSRightTextMovement isFinal:YES];
3. }

Umbruch auf linken Rand bei etwa 80 Zeichen:

Quellcode

1. if( somethingToDo ) {
2. [myTextView insertCompletion:Tom9811 forPartialWordRange:
3. NSMakeRange( 14, 7 ) movement:NSRightTextMovement isFinal:YES];
4. }

Parameterumbruch:

Quellcode

1. if( somethingToDo ) {
2. [myTextView insertCompletion:Tom9811
3. forPartialWordRange:NSMakeRange( 14, 7 )
4. movement:NSRightTextMovement
5. isFinal:YES];
6. }

ich stimme für lösung nr 1. (jaja, erschlagt mich, ich bleib aber dabei)

Kein Grund für einen Mord. Ist ja sicher auch viel Gewöhnung. Ich habe früher übrigens auch #1 verwendet, bin dann irgendwann umgesteigen.

Original von Tom9811
Kein Grund für einen Mord. Ist ja sicher auch viel Gewöhnung. Ich habe früher übrigens auch #1 verwendet, bin dann irgendwann umgesteigen.

ist nummer 3 nicht extrem aufwendig?
Wie macht man das? Mit Tabs, Spaces oder kombination aus beidem?

Original von gritsch

Original von Tom9811
Kein Grund für einen Mord. Ist ja sicher auch viel Gewöhnung. Ich habe früher übrigens auch #1 verwendet, bin dann irgendwann umgesteigen.

ist nummer 3 nicht extrem aufwendig?
Wie macht man das? Mit Tabs, Spaces oder kombination aus beidem?

Das macht Xcode automatisch bei Eingabe des Doppelpunktes. So ganz ungeplant kann es also nicht sein.

Doof sieht es nur aus, wenn der zweite Parameter extrem lang ist und der erste kurz. Dann lege ich manchmal doch Hand an und schiebe den ersten Parameter etwas nach rechts. Ist aber so gut wie nie der Fall

Original von Tom9811

Original von gritsch

Original von Tom9811
Kein Grund für einen Mord. Ist ja sicher auch viel Gewöhnung. Ich habe früher übrigens auch #1 verwendet, bin dann irgendwann umgesteigen.

ist nummer 3 nicht extrem aufwendig?
Wie macht man das? Mit Tabs, Spaces oder kombination aus beidem?

Das macht Xcode automatisch bei Eingabe des Doppelpunktes. So ganz ungeplant kann es also nicht sein.

Doof sieht es nur aus, wenn der zweite Parameter extrem lang ist und der erste kurz. Dann lege ich manchmal doch Hand an und schiebe den ersten Parameter etwas nach rechts. Ist aber so gut wie nie der Fall

ja aber wie macht es Xcode?

Gib mal eine Nachricht mit zwei Parametern ein. Nach dem ersten tippst du die Entertaste und tippst normal weiter. Dann werden die Doppelpunkte automatisch untereinander gesetzt. Jedenfalls bei mir.

Wie macht Xcode das? Mit Tabs, Spaces oder kombination aus beidem?

hab grad kein xCoDe zur hand *duck*

mir gehts nämlich darum dass man den code ja manchmal irgendwo reinpastet ode rmit nem anderen editor öffnet etc und es dann grausam sit wenn die formatierung übern haufen geschmissen wird. Kann bei nem einzeiler nicht passieren

Du kannst ja in Xcode einstellen, ob Tabs oder Spaces verwendet werden sollen. Daran hält er sich, IIRC. Und das wäre mir sicherlich aufgefallen, da ich das im Buch ja auch unbedingt mit Spaces machen muss.


Aber wenn du fremden Code in deinen pastest, kannst du ohnehin ein Reindent machen, der das heilen sollte.

Original von Tom9811
Aber vergleiche selbst: [...]

Mein Editor ist typischerweise breiter als 80 Zeichen, so dass die meisten versandten Nachrichten (ich hab' wirklich Schwierigkeiten, das Wort "Aufruf" zu vermeiden, seit ich weiss, dass die sprachliche Verwechslung von Methode und Befehl hier nicht gerne gesehen wird) in eine Zeile passen.

Die endlose Fensterbreite scheidet fuer mich ohnehin aus, denn dann seh' ich den Code nicht auf einen Blick. Ein aehnliches Problem gibt es auch bei der Aufteilung in mehrere Zeilen: Ich seh' deutlich weniger Code auf einmal; und dieser mangelnde Ueberblick (Wo faengt der Block an? Schreibe ich hinter der richtigen }-Klammer weiter?) stoert mich -- zusaetzlich zum bereits ausfuehlich erwaehnten Argument, dass Zeilenwechsel fuer mich schlicht eine andere, feste Bedeutung haben.

Insofern waehle ich tatsaechlich Variante 2 und freue mich, dass ich keine Buecher schreibe, die mich auf 80 Zeichen oder aehnliche Schmalheiten beschraenken.

Ach, da faellt mir noch eine Frage ein: Machst Du das eigentlich konsequent? Wie schreibst Du ganz kurze Botschaften?



oder



Da lauert naemlich schon die direkte Marotte von mir: Ich kann's nicht leiden, wenn gleiche Faelle unterschiedlich gehandhabt werden. Das geht sogar so weit, dass ich -- entgegen der Apple-Linie, wie sie z.B. auf der WebKit-Website vertreten wird -- dieses ...



... statt jenem ...



... schreibe. So vermeide ich Uneindeutigkeiten (Wem gehoert bei Verschachtelung der else-Teil?) und kann spaeter sorgloser etwas dazuschreiben. Aber zugegeben: Das ist schon wieder ein neues Fass.

Ich glaube, wir streiten uns gleich, ob rot schöner ist als blau.

Ich beispielsweise kann es überhaupt nicht leiden, wenn "{" hinter irgendwas steht, bei mir steht immer


Oder wir sieht es aus mit Leerzeilen im Code? Manche Leute streuen die -- meines Empfindens nach -- wahllos, ich versuche immer, damit kleine logische Blöcke (vor die theoretisch auch manchmal ein Kommentar gehören würde) voneinander abzugrenzen.

Mein Fenster ist in der Nicht-Autorenzeit ja auch breiter. Nur so lange ich an dem Buch sitze, haben die Seiten auf einmal nur noch 65 Zeichen breite. Allerdings ist das auch gar nicht schlecht, weil man so schön mehrere Fenster nebeneinander haben kann. Ich gewöhne mich immer mehr daran.

Ja, ich mache es nur, wenn es nicht reicht. Inkonsequent finde ich das nicht. Du lässt ja auch umbrechen, so dass sich der Unterschied nicht im Umbruch ergibt, sondern in der Ausrichtung bei einem Umbruch. Und ich finde den "automatischen" Zeilenumbruch, der auch noch den linken Rand missachtet fürchterlich. Da geht ja jede Blockstruktur verloren. Früher habe ich daher #1 genommen. Dass ich nicht alles sah, war auch bei mir der ausschlaggebende Grund es zu ändern.

Übrigens setze ich in der Tat auch immer geschweifte Klammern. Das Weglassen gehört für mich zu einem "Besonders tricky, weil es geht"-Gefrickel. Ich finde es übrigens gar nicht schlecht, wenn Programmiersprachen das an der Einrückung selbst erkennen. Dies garantiert, dass Gesehenes und Tatsächliches übereinstimmen.

@seb2: Rot oder blau -- Du sprichst mir aus der Seele!

Und ich kann natuerlich die freistehende {-Klammer nicht sehen. Ich gestehe Dir aber zu, dass das neue Xcode-Code-Folding Dir recht gibt. Speziell diese Zeile ...



... macht da Schwierigkeiten. (Next stop: Die Leerstelle nach dem Doppelpunkt, die ich entsprechend zumindest der deutschen Schrift-Gepflogenheiten gerne setze und die mich zu einer bedrohten Minderheit macht.)

@Tom9811: Wir haben wahrscheinlich den Punkt, wo wir die anderen zu langweilen angefangen haben, schon lange ueberschritten; aber einen hab' ich noch: Ich sehe diese Zeilenumbrueche nicht als gleichwertig, denn gerade die Tatsache, dass der Inhalt nach ganz links schnappt, hilft mir bei der Unterscheidung zwischen logischer und Zeilenbegrenzungs-Ursache. Und ganz links faengt bei mir innerhalb eines Klasseninterfaces oder der Implementierung sonst sowieso gar nichts an, es ist also huebsch eindeutig.

Davon abgesehen kann ich gut verstehen, dass Du Dich auf die Dauer ganz auf den Buch-Stil verlegst. Ich haette auch keine Lust, gleichen Code bei verschiedenen Gelegenheiten verschieden zu schreiben. Und deshalb hab' ich eben meiner Freude Ausdruck verliehen, nicht den gleichen Zwaengen ausgeliefert zu sein.

Original von Tom9811

Original von below
Was hast Du gegen #defines ?

Alex

Ich weiß nicht, was der junge Herr gegen Defines hat. Ich weiß aber was ich gegen Defines habe:

1. Keine Typisierung.
2. Seiteneffekte.
…

Deshalb nehme ich für Dictionary keys NSString konstanten, die ich einfach oben hinschreibe.

Ich muss zugeben, dass ich die Tips von oben zu 90% für großen Schwachsinn oder sehr sehr hässlich umgesetzt halte, ohne da jetzt auf jedes Detail eingehen zu wollen.

Original von Tom9811
BTW: boolsche Verknüpfungen klammere ich immer und wen sie nicht gerade superkurz sind, dann setze ich sie in mehrere Zeilen:

Quellcode

1. if( (other.age > 18)
2. && (other.gender == FemaleGender)
3. && (self.freetime > 1 ) )

So mache ich das auch meistens. Hilft auch gegen:

Chris

Original von Chris

Original von Tom9811
BTW: boolsche Verknüpfungen klammere ich immer und wen sie nicht gerade superkurz sind, dann setze ich sie in mehrere Zeilen:

Quellcode

1. if( (other.age > 18)
2. && (other.gender == FemaleGender)
3. && (self.freetime > 1 ) )

So mache ich das auch meistens. Hilft auch gegen:

Quellcode

1. if ((other.age > 18) & (other.gender == FemaleGender))

Ich muss jedes Mal neu darüber nachdenken. Muss wohl daran liegen, dass ich jahrelang in eine Firma gearbeitet habe, in denen es AND- und BAND-Makros gab.