Guter Stil in Hochsprachen

[Tom]

Hello,

ich stolpere immer wieder über den mMn mangelhaften bis ungenügenden Stil im Code mancher Scripte, die ich so in die Finger bekomme.

Bsp:

for($i=$a,$i<=$b,$i++)

versa:

for ( $index = $min, $index <= $max, $index++)  ## kommentar

Ist formal ja wahrscheinlichn dasselbe. Aber ich benutze doch nicht eine Hochsprache, um die dann wieder auf weniger als Mnemonic-Code zu reduzieren?

Für PHP gibt es z.B. die PEAR-Coding-Standards, die ich bis auf (meine Macke:) den hochgezogenen Blockbeginn für sehr gut halte.

Gibt es andere Coding-Standards (für PERL, C, C++, etc.), die Euch als teoamorientiert und empfehlenswert bekannt sind?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello,

bevor wieder die lakonischen Bemerkungen kommen ;-))

tausche ',' gegen ';'

Aber das war ja nicht die Frage...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Eternius]

Hallo,

ich bevorzuge die erste Variante, da bei Skriptsprachen wie PHP oder Perl kein
Kompilat existiert, sondern die Datei immer neu gelesen werden muss bei ausführung. Und da zählt für mich jedes byte.
Für relevanten code pflege ich aber noch zusätzlich eine "ausführliche" Version der 2.ten art, diese Version dient aber nur der Dokumentation.

gruss

[Frank Schönmann]

hi!

ich bevorzuge die erste Variante, da bei Skriptsprachen wie PHP oder Perl kein
Kompilat existiert, sondern die Datei immer neu gelesen werden muss bei
ausführung. Und da zählt für mich jedes byte.

Du weißt aber, dass die Festplatte Daten sowieso nur blockweise liest und das Parsen
von längeren Variablen- und Funktionsnamen vernachlässigbar ist im Vergleich zum
restlichen Kompiliervorgang und sogar der Ausführung des Programms?

bye, Frank!

[Eternius]

Hallo,

Du weißt aber, dass die Festplatte Daten sowieso nur blockweise liest und das Parsen
von längeren Variablen- und Funktionsnamen vernachlässigbar ist im Vergleich zum
restlichen Kompiliervorgang und sogar der Ausführung des Programms?

der subjektive Eindruck machts ;)

gruss

[Tom]

Hello,

Du weißt aber, dass die Festplatte Daten sowieso nur blockweise liest und das Parsen
von längeren Variablen- und Funktionsnamen vernachlässigbar ist im Vergleich zum
restlichen Kompiliervorgang und sogar der Ausführung des Programms?

Danke für die realistische Bewertung

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Henryk Plötz]

Moin,

ich stolpere immer wieder über den mMn mangelhaften bis ungenügenden Stil im Code mancher Scripte, die ich so in die Finger bekomme.

Bsp:

for($i=$a,$i<=$b,$i++)

versa:

for ( $index = $min, $index <= $max, $index++)  ## kommentar

Ist formal ja wahrscheinlichn dasselbe. Aber ich benutze doch nicht eine Hochsprache, um die dann wieder auf weniger als Mnemonic-Code zu reduzieren?

Die Laufvariable in kurzen Schleifen nicht $i sondern $irgendwas_langes zu nennen ist nicht besser lesbar, sondern Schwachsinn.[1] Deine Verwendung von $a und $b deutet ausserdem daraufhin, dass weiter oben schon ein Unglück passiert ist, als die Variablen eingeführt wurden, das sollte man im Allgemein tatsächlich vermeiden. Und was willst du da kommentieren? "Schleife von $min bis $max, die Schleifenvariable ist $index"? Das ist auch Unfug.

[1] Das gilt wie gesagt für kurze Schleifen wo es offensichtlich ist. Bei längeren Schleifen hat die Variable üblicherweise eine Funktion (wie "paketnummer") was man dann auch bei der Namenswahl ausdrückt.

[Ludger]

Hi,

for($i=$a,$i<=$b,$i++)

versa:

for ( $index = $min, $index <= $max, $index++)  ## kommentar

Die Laufvariable in kurzen Schleifen nicht $i sondern $irgendwas_langes zu nennen ist nicht besser lesbar, sondern Schwachsinn.[1]

ich finde den von Tom kritisierten Schleifenausdruck einfach OK. Man hat eine Zahl $a und ueber die iteriert man bis (einschliesslich) Zahl $b erreicht ist. Dass man da mit einer "Laufvariablen" $i kommt, ist "supernatuerlich".

Deine Verwendung von $a und $b deutet ausserdem daraufhin, dass weiter oben schon ein Unglück passiert ist, als die Variablen eingeführt wurden, das sollte man im Allgemein tatsächlich vermeiden.

Die Namen "$a" und "$b" sind das Unglueck oder meinst Du was anderes?

Und was willst du da kommentieren? "Schleife von $min bis $max, die Schleifenvariable ist $index"? Das ist auch Unfug.

"Guter Code kommentiert sich immer selbst."   ;-)

Gruss,
Ludger

[Andreas Lindig]

Hallo Tom,

Bsp:

for($i=$a,$i<=$b,$i++)

versa:

for ( $index = $min, $index <= $max, $index++)  ## kommentar

finde ich kein Stück besser lesbar. Ich schreibe, wie's auch in guter Typografie üblich ist nach Tschichold: "guter Satz ist enger Satz".

also: for($i=$a, $i<=$b, $i++)
Nach einem Satzzeichen kommt ein Leerzeichen, fertig.

Gruß, Andreas

[Andreas Lindig]

also: for($i=$a, $i<=$b, $i++)

nein, ich schreibe natürlich: for($i=$a; $i<=$b; $i++)
mit Deiner Syntax darfst Du Dich nicht wundern, wenn's nicht funktioniert :-)

Gruß, Andreas

[Tom]

Hello,

nein, ich schreibe natürlich: for($i=$a; $i<=$b; $i++)
mit Deiner Syntax darfst Du Dich nicht wundern, wenn's nicht funktioniert :-)

Ey Man!

aas hatte ich aber rechtzeitig richtig gestellt!{200}

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Hallo,

... "guter Satz ist enger Satz".

also: for($i=$a, $i<=$b, $i++)
Nach einem Satzzeichen kommt ein Leerzeichen, fertig.

So mach ich es auch - beinahe. Nach einem Keyword wie z.B. for, while, if, ... kommt bei mir allerdings immer ein Leerzeichen.
Und den Zuweisungsoperator stelle ich auch zwischen Blanks, wenn die Zuweisung als selbständige Anweisung steht. Ist die Zuweisung nur ein Teil eines Statements (wie im obigen Beispiel), dann lass ich diese Blanks weg.
Beispiel aus C:

|  mem_needed = 0x2000;
|  if (ptr=malloc(mem_needed))
|   { /* weitere Anweisungen */
|   }
|  else
|   { /* Fehlerbehandlung */
|   }

(Balken am linken Rand nötig wegen Forumsbug "Leerzeichen am Zeilenanfang")
Schönes Wochenende,

Martin

[Henryk Plötz]

Moin,

Beispiel aus C:

|  mem_needed = 0x2000;
|  if (ptr=malloc(mem_needed))
|   { /* weitere Anweisungen */
|   }
|  else
|   { /* Fehlerbehandlung */
|   }

Deine Einrückung ist echt das Krankeste was ich in letzter Zeit gesehen habe.

So gehört das:
  if (ptr=malloc(mem_needed)) {
      /* weitere Anweisungen */
  } else {
      /* Fehlerbehandlung */
  }

[Der Martin]

Hallo,

Deine Einrückung ist echt das Krankeste was ich in letzter Zeit gesehen habe.

Tja, Geschmackssache. Ich find's übersichtlich.

So gehört das:
  if (ptr=malloc(mem_needed)) {
      /* weitere Anweisungen */
  } else {
      /* Fehlerbehandlung */
  }

Aber nicht bei mir. Das da oben finde ICH wiederum furchtbar.
Die öffnende Klammer am Zeilenende ist so ziemlich das übelste, was mir einfällt. Da erkenne ich auf Anhieb nämlich nicht, ob das nach dem if eine einzelne Anweisung oder ein Block ist. Und das ist eine gemeine Fehlerquelle.
Ciao,

Martin

[Martin Speiser]

Hi Martin,

Aber nicht bei mir. Das da oben finde ICH wiederum furchtbar.
Die öffnende Klammer am Zeilenende ist so ziemlich das übelste, was mir einfällt. Da erkenne ich auf Anhieb nämlich nicht, ob das nach dem if eine einzelne Anweisung oder ein Block ist. Und das ist eine gemeine Fehlerquelle.

geht mir genauso. Ich kann auch nicht verstehen, wieso manche die öffnende Klammer am Zeilenende so vehement verteidigen. Wie schon von Anderen gesagt, es ist unübersichtlicher, schlechter zu debuggen, das Folding mancher Editoren wird ziemlich übel. Welche Punkte gibt es für dieses alte Format denn? Ausser dass der Code kompakter wird, was bei heutigen Auflösungen aber auch nebensächlich ist.

Gruß,
Martin

[Daniel Thoma]

Hallo Martin,

Der Gewinn an Übersichtlichkeit durch eine extra Zeile für Klammern ist gering.
Die Verschachtelungsstruktur erkennt man ja Anhand der Einrückung.

Der Code wird dadurch aber erheblich länger.
Damit kann man weniger Code auf einmal auf dem Bildschirm sehen. Das macht es wieder deutlich schwieriger, nachzuvollziehen, was da gemacht wird.
Ein zusammenhängender Codeabschnitt sollte daher auch nicht länger als ca 40 Zeilen sein, damit man den noch komplett überblicken kann.
Das ist natürlich keine harte Grenze, aber ein Grund dafür, dass man mit Zeilen nicht zu verschwenderisch umgehen sollte.

Außerdem ist es natürlich sinnvoll, seinen Code weitesgehendst so zu formatieren, wie es bei der eingesetzten Sprache üblich ist.
Die Formatierung ist einfach jeder gewohnt, der damit Arbeitet.

Grüße

Daniel

[Dennis]

Hi Daniel,

Der Code wird dadurch aber erheblich länger.
Damit kann man weniger Code auf einmal auf dem Bildschirm sehen. Das macht es wieder deutlich schwieriger, nachzuvollziehen, was da gemacht wird.
Ein zusammenhängender Codeabschnitt sollte daher auch nicht länger als ca 40 Zeilen sein, damit man den noch komplett überblicken kann.
Das ist natürlich keine harte Grenze, aber ein Grund dafür, dass man mit Zeilen nicht zu verschwenderisch umgehen sollte.

In Anbetracht der heutigen hohen Bildschirmaufläsungen und der Möglichkeit mit zwei Monitoren neben- oder übereinander zu arbeiten zählt dieses Argument in meinen Augen kaum noch.

Außerdem ist es natürlich sinnvoll, seinen Code weitesgehendst so zu formatieren, wie es bei der eingesetzten Sprache üblich ist.
Die Formatierung ist einfach jeder gewohnt, der damit Arbeitet.

Es ist ein großer Fehler etwas zu machen, nur weil andere es so machen, ohne dieses etwas voher auf Sinn und Vernunft geprüft zu haben.

MfG, Dennis.

[Daniel Thoma]

Hallo Dennis,

In Anbetracht der heutigen hohen Bildschirmaufläsungen und der Möglichkeit mit zwei Monitoren neben- oder übereinander zu arbeiten zählt dieses Argument in meinen Augen kaum noch.

Zwei Monitor nebeneinander bringt nichts in diesem Fall und zwei Monitore übereinander, naja etwas ungewöhnlich.
Größer sind die Monitore geworden und wenn alle Entwickler mit 21 Zoll Flachbildschirmen arbeiten, passen dann vielleicht 60 Zeilen in den Texteditor.
Man hat ja üblicherweise noch nen haufen anderer Sachen drumherum. Der Quelltext ist nicht das einzige, für das man manchmal mehr Platz brauchen könnte.
Außerdem ist die größe der Fläche, die man bewusst sieht auch begrennzt und Du kannst das dann auch nicht mehr mit einem Blick erfassen, wenn es ganz auf den Monitor passt.

Es ist ein großer Fehler etwas zu machen, nur weil andere es so machen, ohne dieses etwas voher auf Sinn und Vernunft geprüft zu haben.

Hinter all diesen Richtlinen steckt Überlegung und die "beste" gibt es sowieso nicht. Das ist hauptsächlich Gewohnheitssache.
Da liegt es nahe, sich an das zu gewöhnen, was schon "die Anderen" benutzen, statt sich selbst etwas auszudenken.
Es macht die Zusammenarbeit schlicht einfacher.
Die Standard-Java-Klassen sind z.B. alle in diesem
if(...) {

} else {

}
Stil.
Dementsprechend auch sehr viel andere Software, die in Java geschrieben ist.

Natürlich hast Du die Freiheit, was anderes besser zu finden. Nur wirst Du mit dem Code der Anderen klar kommen müssen und wenn jemand mit Deinem Code klar kommen muss, wird er mit sehr hoher Wahrscheinlichkeit motzen.
(Bei Einrückungen vielleicht noch nicht, weil man das Automatisch machen kann, wenn es um Bezeichnernamen geht o.ä. geht das aber nicht mehr)

Grüße

Daniel

[Dennis]

Hi Daniel,

Größer sind die Monitore geworden und wenn alle Entwickler mit 21 Zoll Flachbildschirmen arbeiten, passen dann vielleicht 60 Zeilen in den Texteditor.

Und wem das zu wenig ist, der soll halt seine Bildschirmauflösung hoch setzen ;-)

Man hat ja üblicherweise noch nen haufen anderer Sachen drumherum. Der Quelltext ist nicht das einzige, für das man manchmal mehr Platz brauchen könnte.

Dafür gibts dann ja einen zweiten Monitor daneben...

Außerdem ist die größe der Fläche, die man bewusst sieht auch begrennzt und Du kannst das dann auch nicht mehr mit einem Blick erfassen, wenn es ganz auf den Monitor passt.

Da muss ich dir natürlich zustimmen - aber meines Erachtens wird dieser "Nachteil" dadurch wieder wett gemacht, dass man beim Überfliegen direkt die Blöcke (besser) erkennen kann.

Da liegt es nahe, sich an das zu gewöhnen, was schon "die Anderen" benutzen, statt sich selbst etwas auszudenken.
Es macht die Zusammenarbeit schlicht einfacher.

Da kommt es dann eben auf eine gute Kommunikation im vorheraus an - und natürlich auch auf die Sprache in der programmiert wird, ist ja eigentlich klar ;-)

Natürlich hast Du die Freiheit, was anderes besser zu finden. Nur wirst Du mit dem Code der Anderen klar kommen müssen und wenn jemand mit Deinem Code klar kommen muss, wird er mit sehr hoher Wahrscheinlichkeit motzen.

Wenn die "Anderen" aber so schreiben wie ich? :-P

Nein, du hast natürlich Recht - es schadet nichts, wenn man mit mehreren Notationsweisen zurechtkommt und sicht nicht ganz auf eine fixiert.

MfG, Dennis.

[Martin Speiser]

Hallo Daniel

Der Gewinn an Übersichtlichkeit durch eine extra Zeile für Klammern ist gering.
Die Verschachtelungsstruktur erkennt man ja Anhand der Einrückung.

mit der extra Zeile für die Klammer erkennt man die Struktur noch besser, weil die Klammern untereinander stehen.

Der Code wird dadurch aber erheblich länger.

Ich würde eher sagen, unerheblich länger.

Ein zusammenhängender Codeabschnitt sollte daher auch nicht länger als ca 40 Zeilen sein, damit man den noch komplett überblicken kann.
Das ist natürlich keine harte Grenze, aber ein Grund dafür, dass man mit Zeilen nicht zu verschwenderisch umgehen sollte.

Das kann aber nich als Ausrede dazu dienen, jetzt zwanghaft Zeilen zu sparen. Dann kann man gleich mehrere Anweisungen in eine Zeile quetschen, das ist in meinen Augen das Gleiche.

Außerdem ist es natürlich sinnvoll, seinen Code weitesgehendst so zu formatieren, wie es bei der eingesetzten Sprache üblich ist.

*g* Zum Glück findest man immer mehr Code, bei dem die Klammern in extra Zeilen stehen.

Gruß,
Martin

[Lemmy Danger]

Hallo!

Die öffnende Klammer am Zeilenende ist so ziemlich das übelste, was mir einfällt. Da erkenne ich auf Anhieb nämlich nicht, ob das nach dem if eine einzelne Anweisung oder ein Block ist. Und das ist eine gemeine Fehlerquelle.

Anweisungsblöcke gehören in geschweifte Klammern. Punkt. Auch bzw. gerade wenn der Block nur aus einer Zeile Code besteht. Was ist denn, wenn ich die Klammern weglasse und bei Wartungsarbeiten dann doch noch eine weitere Zeile im Block benötige? Weiss man das immer so genau im vorhinein? Das Weglassen von geschweiften Klammern bei (einzeiligen) Anweisungsblöcken ist "so ziemlich das Übelste, was mir einfällt".

Oliver

[Ludger]

Hi,

Anweisungsblöcke gehören in geschweifte Klammern. Punkt. Auch bzw. gerade wenn der Block nur aus einer Zeile Code besteht. Was ist denn, wenn ich die Klammern weglasse und bei Wartungsarbeiten dann doch noch eine weitere Zeile im Block benötige? Weiss man das immer so genau im vorhinein? Das Weglassen von geschweiften Klammern bei (einzeiligen) Anweisungsblöcken ist "so ziemlich das Übelste, was mir einfällt".

richtig ausgefuehrt! Aber das hat auch niemand vorgeschlagen.

Gruss,
Ludger

[Lemmy Danger]

Hallo!

Und wie interpretierst Du folgende Aussage von Martin?

Die öffnende Klammer am Zeilenende ist so ziemlich das übelste, was mir einfällt. Da erkenne ich auf Anhieb nämlich nicht, ob das nach dem if eine einzelne Anweisung oder ein Block ist.

Der Punkt ist: es ist immer ein Block, auch wenn dieser einzeilig ist.

Aber noch mal zu Martin: Das Ende des Blocks erkennst Du immer an der geschlossenen geschweiften Klammer UND der aufgehobenen Einrückung.

if ...
    ...
}

Also, ich persönlich bevorzuge die öffnende Klammer in einer Zeile mit der Bedingung, da für mich die Bedingung mit dem Beginn eines Anweisungsblocks logisch verknüpft sind. Falls ich einmal von einem Projekt andere Coding-Standards vorgesetzt bekomme, dann ändere ich das natürlich notgedrungen. Aber man sieht das auch in Sprachen, die eine etwas andere Syntax kennen:

if ... then
    ...
end if

Zugegeben, ich denke hier an VB, was ich vom Sprachdesign für eine der schlechteren Sprachen halte. Aber hier würde auch niemand auf die Idee kommen, das "then" in eine neue Zeile zu schreiben und mit dem "if" auf eine Stufe zu setzen.

Eine Zeile Programmcode sollte für den Leser m.E. immer eine neue Information enthalten. Wenn ich nun eine Zeile sehe, die mit "if", "for", "while" etc. beginnt, dann _weiß_ ich, dass ein Anweisungsblock folgt (und ich sehe es anhand der Einrückung). Welche neue Information liefert eine Zeile mit einer geöffneten Klammer? - Richtig, jetzt beginnt ein Anweisungsblock! Also _ich_ wußte das schon eine Zeile eher... ;-)

Just my two cents.

Gruß,
Oliver

[Dennis]

Hi Lemmy,

if ... then
    ...
end if

Zugegeben, ich denke hier an VB, was ich vom Sprachdesign für eine der schlechteren Sprachen halte. Aber hier würde auch niemand auf die Idee kommen, das "then" in eine neue Zeile zu schreiben und mit dem "if" auf eine Stufe zu setzen.

afaik (dass muss man ab jetzt ja klein schreiben, sonst kriegt man ne Meldung "unsauberes Posting" *gg*) kann man das then sowieso nicht in die nächste Zeile setzen, zumindest das Microsoft Visual Basic Studio beschwert sich dann. Ich wollte nämlich mal sowas machen:

If (bedingung) OR
   (bedingung) OR
   (bedingung)    then

' Weitere Anweisungen

End If

Einfach um den Code übersichtlicher zu halten, da die Bedinugen ziemlich lang waren - wurde mir aber gnadenlos als Fehler anerkannt - "expecting then or goto" ...

MfG, Dennis.

[Jörg Lorenz]

Hi Dennis,

afaik (dass muss man ab jetzt ja klein schreiben, sonst kriegt man ne Meldung "unsauberes Posting" *gg*) kann man das then sowieso nicht in die nächste Zeile setzen, zumindest das Microsoft Visual Basic Studio beschwert sich dann. Ich wollte nämlich mal sowas machen:

If (bedingung) OR
   (bedingung) OR
   (bedingung)    then

' Weitere Anweisungen

End If

versuch's mal so:

If (bedingung) OR _
   (bedingung) OR _
   (bedingung)    then

' Weitere Anweisungen

End If

Viele Grüße

Jörg

[Dennis]

Hi Jörg,

versuch's mal so:

If (bedingung) OR _
   (bedingung) OR _
   (bedingung)    then
...

Ok, danke, werd ich bei Gelegenheit mal ausprobieren.

MfG, Dennis.

[Jörg Lorenz]

Hi Dennis,

die Möglichkeit, Codezeilen mit dem Unterstrich zu trennen, bietet noch mehr Möglichkeiten. Ich nutze das zum Beispiel gern zum Debuggen, indem ich mir per MsgBox Variableninhalte zeigen lasse, z. B. so:

n = 10
For i = 1 To 5
    n = n + 1
    MsgBox "Das ist die Anzeige der Variablen." & vbNewLine & _
                "Variable i: " & i & vbNewLine & _
                "Variable n: " & n
Next

Hinsichtlich der hier geführten Diskussion gibt es übrigens in VB auch verschiedene Möglichkeiten, Code zu schreiben. So ist z. B.

For i = 1 To 5
    MsgBox "Hallo Welt!"
Next

das Gleiche, wie

For i = 1 To 5: MsgBox "Hallo Welt!": Next

Noch ein Beispiel, das

For i = 1 To 5
    If i Mod 2 = 0 Then
        MsgBox i
    Else
        MsgBox "Ungerade"
    End If
Next

ist das Gleiche wie

For i = 1 To 5
    If i Mod 2 = 0 Then
        MsgBox i
    Else: MsgBox "Ungerade"
    End If
Next

oder wie

For i = 1 To 5
    If i Mod 2 = 0 Then MsgBox i Else MsgBox "Ungerade"
Next

;-)

Viele Grüße

Jörg

Viele Grüße

Jörg

[Dennis]

Hi Jörg,

die Möglichkeit, Codezeilen mit dem Unterstrich zu trennen, bietet noch mehr Möglichkeiten. Ich nutze das zum Beispiel gern zum Debuggen, indem ich mir per MsgBox Variableninhalte zeigen lasse.

Stimmt, hält den Code übersichtlicher und erleichtert das Debuggen ;-)

Aber wo ich hier mit dir gerade an einen VB Profi geraten zu sein schein (*g*): Gibt es eigentlich für VB auch so ne Art Online Funktionsreferenz wie für PHP? Ich hab zwar schon oft danach gesucht, aber nichts in der Art gefunden. Gibts da echt nur Bücher zu?

Noch was: Hast du irgendwie Erfahrungen mit VB und MySQL?

MsgBox "Hallo Welt!"

Apropos MsgBox: Ich wollte mal eine ans Sytem gebundene Message Box machen, habe dazu vbSystemModal mitübergeben, hat aber nichts gebracht - ich konnte ganz normal unter Windows weiterarbeiten, ohne auf das Ding klicken zu müssen :-/

MfG, Dennis.

[Vinzenz Mai]

Hallo Dennis

Aber wo ich hier mit dir gerade an einen VB Profi geraten zu sein schein (*g*): Gibt es eigentlich für VB auch so ne Art Online Funktionsreferenz wie für PHP? Ich hab zwar schon oft danach gesucht, aber nichts in der Art gefunden. Gibts da echt nur Bücher zu?

Setze den Cursor hinter den Funktionsnamen. Drücke F1. *fg*
Die Online-Hilfe heisst MSDN, geht auch übers Internet.

Noch was: Hast du irgendwie Erfahrungen mit VB und MySQL?

Das geht mit dem ODBC-Treiber für MySQL ganz gut.

Freundliche Grüße

Vinzenz

[Dennis]

Hi Vinzenz,

Setze den Cursor hinter den Funktionsnamen. Drücke F1. *fg*

Hab MSDN (noch) nicht installiert - außer einer Fehlermeldung gibts da nichts ... und davon hab ich selber genug ;-)

Die Online-Hilfe heisst MSDN, geht auch übers Internet.

Etliche Funktionen davon scheinen aber nur in VisualBasic.net enthalten zu sein... So sagt mir mein VisualBasic 6.0 bei FileOpen "Fuction undefined".

Noch was: Hast du irgendwie Erfahrungen mit VB und MySQL?

Das geht mit dem ODBC-Treiber für MySQL ganz gut.

Hm, hättest du dazu irgendwie noch weitere Informationsquellen zu? Insbesondere wie ich dass dann in VisualBasic "einbinde"?

MfG, Dennis.

[Jörg Lorenz]

Hi Dennis,

Aber wo ich hier mit dir gerade an einen VB Profi geraten zu sein schein (*g*):

Nee, nicht wirklich. ;-)

Gibt es eigentlich für VB auch so ne Art Online Funktionsreferenz wie für PHP? Ich hab zwar schon oft danach gesucht, aber nichts in der Art gefunden. Gibts da echt nur Bücher zu?

Hm, keine Ahnung. Ich nutze auch nur die Seiten im Internet, deren Links ich auf meinen Seiten habe.

Noch was: Hast du irgendwie Erfahrungen mit VB und MySQL?

Mit VB etwas, mit MySQL kaum. ;-)

Apropos MsgBox: Ich wollte mal eine ans Sytem gebundene Message Box machen, habe dazu vbSystemModal mitübergeben, hat aber nichts gebracht - ich konnte ganz normal unter Windows weiterarbeiten, ohne auf das Ding klicken zu müssen :-/

Mit SystemModal oder der ShowModal-Eigenschaft arbeite ich überhaupt nicht. Wenn ich es mal brauche, nutze ich die API:

Private Declare Function SetWindowPos Lib _
   "User32" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, _
   ByVal X As Long, ByVal Y As Long, ByVal cx As Long, _
   ByVal cy As Long, ByVal wFlags As Long) As Long

und

Call SetWindowPos(Me.hwnd, -1, 0, 0, 0, 0, 3)

Viele Grüße

Jörg

[Dennis]

Hi Jörg,

Mit SystemModal oder der ShowModal-Eigenschaft arbeite ich überhaupt nicht. Wenn ich es mal brauche, nutze ich die API:

Private Declare Function SetWindowPos Lib _
   "User32" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, _
   ByVal X As Long, ByVal Y As Long, ByVal cx As Long, _
   ByVal cy As Long, ByVal wFlags As Long) As Long

und

Call SetWindowPos(Me.hwnd, -1, 0, 0, 0, 0, 3)

Thanks, werde ich mal ausprobieren.

MfG, Dennis.

[Der Martin]

Hallo Oliver,

Und wie interpretierst Du folgende Aussage von Martin?

Die öffnende Klammer am Zeilenende ist so ziemlich das übelste, was mir einfällt. Da erkenne ich auf Anhieb nämlich nicht, ob das nach dem if eine einzelne Anweisung oder ein Block ist.

Ganz einfach: Ich halte es mit der Blockbildung nicht so konsequent. Wenn die Anweisung nach dem if oder nach dem else z.B. nur aus einer einzigen Zuweisung besteht, verzichte ich auf die Klammern. Man mag das von mir aus kritisieren, aber bei kurzen, leicht zu erfassenden Anweisungen finde ich es übersichtlicher als sie nochmal zu klammern.

Aber noch mal zu Martin: Das Ende des Blocks erkennst Du immer an der geschlossenen geschweiften Klammer UND der aufgehobenen Einrückung.

Ja. Aber leider habe ich schon oft Quellcodes in die Finger gekriegt, in denen die Anweisungsblöcke und die Einrückung schon von vornherein nicht mehr gepasst haben oder -noch schlimmer- wo scheinbar willkürlich eingrückt wurde. Meistens dann mit der Bemerkung "Kuck dir das doch bitte mal an, ich hab den Eindruck, da stimmt irgendwas nicht".

Deswegen ziehe ICH die Symbole, die den Block als solchen markieren, nach vorn an den Zeilenanfang. Und zwar öffnende und schließende Klammer genau auf die gleiche Einrückungsebene.

Zugegeben, ich denke hier an VB, was ich vom Sprachdesign für eine der schlechteren Sprachen halte. Aber hier würde auch niemand auf die Idee kommen, das "then" in eine neue Zeile zu schreiben und mit dem "if" auf eine Stufe zu setzen.

Doch. Als ich vor Jahren noch Pascal programmiert habe, hab ich das so gemacht. Pascal-Code ist schön, weil man sehr vieles in Worten (anstatt Symbolen wie in C) lesen kann. Und da habe ich meine Schreibweise an die unterbewusste Strukturierung der Umgangssprache angelehnt, so wie z.B.
   WENN die Ampel auf Grün schaltet,
   DANN fahr los.
Hier ordnet man das "DANN" doch instinktiv auch dem nachfolgenden Hauptsatz zu, auch wenn ich es jetzt ohne Zeilenumbruch geschrieben hätte.
Genauso -um wieder den Sprung zur Programmiersprache zu machen- verfahre ich bei mehreren Teilausdrücken in einer Klammer. Wenn alle Teilausdrücke kurz und übersichtlich sind, schreib ich alles in eine Zeile. Wenn ich die Teilausdrücke aber über mehrere Zeilen splitte, dann etwa so:

if (a>1
    && b>2
    && u<4)
    { n = a*b + u;
      u = 0;
    }

Oft sehe ich, dass eine Zeile dann mit dem Operator (hier &&) endet und die folgende Zeile dadurch wie eine eigenständige (evtl. sinnlose) Anweisung aussieht. Das finde ich dann auch nicht gerade empfehlenswert.

Just my two cents.

They might as well be worth five, who knows? ;)
So long,

Martin

[Daniel Thoma]

Hallo Martin,

Oft sehe ich, dass eine Zeile dann mit dem Operator (hier &&) endet und die folgende Zeile dadurch wie eine eigenständige (evtl. sinnlose) Anweisung aussieht. Das finde ich dann auch nicht gerade empfehlenswert.

Umgebrochene Anweisungen oder Bedingungen genau so einzurücken, wie Blöcke ist natürlich gefährlich.
Nach den Sun-Richtlinien würde das so formatiert werden:

if(bedingung
        && bedingung
        && bedingung) {
    Anweisung;
    Anweisung;
}

Grüße

Daniel

[Vinzenz Mai]

Hallo Martin

Genauso -um wieder den Sprung zur Programmiersprache zu machen- verfahre ich bei mehreren Teilausdrücken in einer Klammer. Wenn alle Teilausdrücke kurz und übersichtlich sind, schreib ich alles in eine Zeile. Wenn ich die Teilausdrücke aber über mehrere Zeilen splitte, dann etwa so:

if (a>1
    && b>2
    && u<4)
    { n = a*b + u;
      u = 0;
    }

Ich kann das schon nicht mehr lesen, das ist mein Problem bei kleinen Einrückungen.

if ( a > 1
         && b > 2
         && u < 4 ) {
        n = a * b + u;  // in solchen Zeilen bin ich konsequent
        u = 0;
    }

ist in einem solchen Fall sicher problematischer als

if ( a > 1
         && b > 2
         && u < 4 )
    {
        n = a * b + u;  // in solchen Zeilen bin ich konsequent
        u = 0;
    }

wobei diese Teilausdrücke natürlich unter der Kategorie "übersichtlich" einzuordnen sind ;-)

Oft sehe ich, dass eine Zeile dann mit dem Operator (hier &&) endet und die folgende Zeile dadurch wie eine eigenständige (evtl. sinnlose) Anweisung aussieht. Das finde ich dann auch nicht gerade empfehlenswert.

Das sehe ich genauso.

Freundliche Grüße

Vinzenz

[Ludger]

Hi,

Und wie interpretierst Du folgende Aussage von Martin?

Die öffnende Klammer am Zeilenende ist so ziemlich das übelste, was mir einfällt. Da erkenne ich auf Anhieb nämlich nicht, ob das nach dem if eine einzelne Anweisung oder ein Block ist.

Ganz einfach: Ich halte es mit der Blockbildung nicht so konsequent. Wenn die Anweisung nach dem if oder nach dem else z.B. nur aus einer einzigen Zuweisung besteht, verzichte ich auf die Klammern. Man mag das von mir aus kritisieren, aber bei kurzen, leicht zu erfassenden Anweisungen finde ich es übersichtlicher als sie nochmal zu klammern.

das waere dann aber wieder nicht so gut.   :-)

Man sollte tatsaechlich immer alles auf ein und dieselbe Art und Weise machen. Ich komme natuerlich auch bei Einzelanweisungen in "IF-Bloecken" immer mit Blockbegrenzern. (In T-SQL z.B. immer mit "BEGIN" und in der naechsten Zeile mit einem "-- <ggf. Kommentar>", am Ende des Blocks wieder ein "-- <ggf. Kommentar>" und in der naechsten Zeile ein "END". Da haben schon Kollegen blass geguckt, ich suelzte dann davon, dass man Blockbegrenzer immer "weich einpacken" muss, da sich sonst der Code weh tut. ;-)

Gruss,
Ludger

[Dennis]

Hi Henryk,

|  mem_needed = 0x2000;
|  if (ptr=malloc(mem_needed))
|   { /* weitere Anweisungen */
|   }
|  else
|   { /* Fehlerbehandlung */
|   }

Deine Einrückung ist echt das Krankeste was ich in letzter Zeit gesehen habe.

Dem kann ich nicht zustimmen, ich finde diese Einrückung gut und verwende sie fast genauso, nur rücke ich die { und } nicht ein und ein Kommentar würde ich vermutlich entweder hinter if/else oder in eine neue Zeile nach { schreiben.

Ach ja, für Wertzuweisungen und Abfragen mach ich dann noch ein Leerzeich von und nach dem Zuweisungs- bzw. Vergleichsoperator.

So gehört das:
  if (ptr=malloc(mem_needed)) {
      /* weitere Anweisungen */
  } else {
      /* Fehlerbehandlung */
  }

Was heißt schon "so gehört das"? Mir kann keiner vorschreiben, wie ich meinen Code zu schreiben habe ;-)

Was du da schreibst würde ich als "logische" Auszeichnung bezeichnen (*g*) - man sieht direkt dass das else zum Block davor gehört - aber war bring mir das beim debuggen?

Im Gegensatz sehe ich beim ersten Code Beispiel genau, welche Blöche zusammengehören und kann indem ich in meinem Editor ganze Zeilen ausblende problemlos einen ganzen Block ausblenden, ohne das if bzw. else mit ausblenden zu müssen. So kommt man auch schnell einer vergessenen } auf die Spur ;-)

MfG, Dennis.

[Henryk Plötz]

Moin,

Dem kann ich nicht zustimmen, ich finde diese Einrückung gut und verwende sie fast genauso, nur rücke ich die { und } nicht ein und ein Kommentar würde ich vermutlich entweder hinter if/else oder in eine neue Zeile nach { schreiben.

Also stimmst du doch zu ;-) Diese Krankheit die Klammern auf eine eigene Zeile zu ziehen, und 'ein bisschen' einzurücken ist allgemein bekannt (als GNU-Stil). Dann aber den Code bereits auf der Zeile der öffnenden Klammer zu beginnen um ja doch keine keine Zeile zu verschwenden, das muss dem Martin sein[1] Privatvergnügen sein.

[1] ;-)

[Dennis]

Hi Henryk,

Also stimmst du doch zu ;-) Diese Krankheit die Klammern auf eine eigene Zeile zu ziehen, und 'ein bisschen' einzurücken ist allgemein bekannt (als GNU-Stil). Dann aber den Code bereits auf der Zeile der öffnenden Klammer zu beginnen um ja doch keine keine Zeile zu verschwenden, das muss dem Martin sein Privatvergnügen sein.

Achso, ich dachte jetzt, du wolltest auf die geschwungenen Klammern hinaus ;-)

MfG, Dennis.

[Ludger]

Hi,

Deine Einrückung ist echt das Krankeste was ich in letzter Zeit gesehen habe.

So gehört das:
  if (ptr=malloc(mem_needed)) {
      /* weitere Anweisungen */
  } else {
      /* Fehlerbehandlung */
  }

etwas dogmatisch, was? Aber da bist Du ja im selben Boot wie der Christian. (Uberfluessig zu sagen, dass ich selbst als "Meister des Whitespaces" wie Der Martin codiere.)

Dumpfbacken wissen Sachen, die sie gar nicht wissen koennen.

Gruss,
Ludger

[Tom]

Hello,

Deine Einrückung ist echt das Krankeste was ich in letzter Zeit gesehen habe.

Und so wäre es vernünftig lesbar:

if (ptr=malloc(mem_needed))
      {
        /* weitere Anweisungen */
      }
      else
      {
         /* Fehlerbehandlung */
      }

Pro Ebene mindestens 2 Sellen Einrückung aber maximal 4 Stellen, alle Elemente gleicher Hierarchie in gleicher Spalte.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Vinzenz Mai]

Hallo Tom

Pro Ebene mindestens 2 Sellen Einrückung aber maximal 4 Stellen, alle Elemente gleicher Hierarchie in gleicher Spalte.

mindestens vier, aber ich bin auch halbblind! *g*

Freundliche Grüße

Vinzenz

[Tom]

Hello,

Pro Ebene mindestens 2 Sellen Einrückung aber maximal 4 Stellen, alle Elemente gleicher Hierarchie in gleicher Spalte.

mindestens vier, aber ich bin auch halbblind! *g*

Das wäre dann z.B. PEAR-Coding-Standard
Ist bei ausreichender Struktierung (Funktionen) auch nix dageben einzuwenden. Eher im Gegenteil.

Die Zeiten von

Schleifen in
   Schleifen in
     Bedingungen in
       Schleifen in
         Bedingungen in
           Bedingeungen

sind ja hoffentlich auch bald vorbei. Ein einfacher Function Call kostet heute nicht mal mehr 1/100.000 der Zeit eines Bildneuaufbaus. Das kann man sich leisten.

Es gab aber auch andere Zeiten.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Dennis]

Hi Vinzenz,

Pro Ebene mindestens 2 Sellen Einrückung aber maximal 4 Stellen, alle Elemente gleicher Hierarchie in gleicher Spalte.

mindestens vier, aber ich bin auch halbblind! *g*

Ich arbeite immer mit Tabs, welche in meinem Editor als 4 Leerzeichen angezeigt werden - Ich weiß, dass ist vielleicht nicht gerade Standard, aber rücke ich eine Zeile 10 Leerzeichen ein, schreibe was, drücke Enter, so ist die nächste Zeile 2 Tabs + 2 Leerzeichen eingerückt. Könnte man als "kleine Macke" an HomeSite bezeichnen ;-)

MfG, Dennis.

[Ludger]

Hi,

if (ptr=malloc(mem_needed))
      {
        /* weitere Anweisungen */
      }
      else
      {
         /* Fehlerbehandlung */
      }

verschiedene Einrueckungstiefen dienen dazu verschiedene Logikebenen zu visualisieren. Nun kann man sich die Frage stellen, ob die (hier runden) Klammern bereits zur tieferen Logikebene gehoeren oder nicht. Ich behaupte hiermit, dass die Klammern es als "Blockbegrenzer" tun, naemlich zur naechsten tieferen Logikebene zu gehoeren.

Gruss,
Ludger

[Andreas Lindig]

Und so wäre es vernünftig lesbar:

if (ptr=malloc(mem_needed))
      {
        /* weitere Anweisungen */
      }
      else
      {
         /* Fehlerbehandlung */
      }

jo, vor allem die geschweiften Klammern in die gleiche Spalte. Das ist das Einzige, was den Code übersichtlich hält, egal wie tief er verschachtelt ist. Daß es mehr Zeilen braucht macht nichts, man kann ja scrollen. Ich muß z.Zt. mit jemandem Code austauschen, der immer

if(bla) {
   dann blubb
}

und so weiter schreibt. Und dann z.T. mit nur einem Leerzeichen Einzug. Naja. Er muß den Code schreiben, ich muß nur testen und korrigieren, aber zum lesen ist das wirklich keine Wonne.

Gruß, Andreas

[Tom]

Hello,

Und so wäre es vernünftig lesbar:

if (ptr=malloc(mem_needed))
      {
        /* weitere Anweisungen */
      }
      else
      {
         /* Fehlerbehandlung */
      }

jo, vor allem die geschweiften Klammern in die gleiche Spalte. Das ist das Einzige, was den Code übersichtlich hält, egal wie tief er verschachtelt ist. Daß es mehr Zeilen braucht macht nichts, man kann ja scrollen. Ich muß z.Zt. mit jemandem Code austauschen, der immer

if(bla) {
   dann blubb
}

und so weiter schreibt.

Das sehe ich eben aus eigener Erfahrung auch so.

Die Klammern symbolisieren den Anfang und das Ende eines Blockes. Anfang und Ende sind gleichwertig. Es ist also nicht einzusehen, dass die öffnende Klammer mit der Länge des Namens des Blockbezeichners *ohjeh* in der Spalte wandert.

Die Leite von Textpad hatten z.B. mal in Erwägung gezogen, nicht nur eine waagerechte Aktiv-Markierung einzubauen, sondern auch eine senkrechte. Da hätten man dann leicht und locker Blockanfang und Blockende ausfindig machen können. Leider haben sie die senkrechte aber noch nicht eingebaut, weil "sich kaum jemand an eine spaltenweise Übereinstimmung von Blockanfang und Blockende hält". Soweit jedenfalls das damalige email.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Henryk Plötz]

Moin,

etwas dogmatisch, was?

Ach, gar nicht.

[Daniel Thoma]

Hallo Tom,

for($i=$a,$i<=$b,$i++)

$i, $j, $k für Laufvariablen in for-Schleifen ist einfach üblich. Da verwirrt ein $index1, $index2, $index3 höchstens.

Das $a und $b kommt so sowieso selten vor, oft ist ja der Anfangsindex fest und der letzte wird irgendwie berechnet oder ist die Länge eines Arrays o.ä.

Das Einzige, was man bei der for-Schleife noch "verbessern" könnte, wäre, $i in der Schleife zu deklarieren:

for(my $i=$a, $i < $b, $i++) {...}

Dann ist offensichtlich, dass $i zur Schleife gehört und nicht noch irgend einem anderen Zweck dient.

Grüße

Daniel

[Daniela Koller]

Hi Tom

for($i=$a,$i<=$b,$i++)

versa:

for ( $index = $min, $index <= $max, $index++)  ## kommentar

Taugt imho beides nichts. $i ist klar, das ist eine Laufvariable für eine kleine Schleife, $index ist nicht Aussagekräftiger. Genauso ist es mit $a/$min $b/$max. Beides ist nichtssagend, das es sich um Minima und Maxima handelt, ist bereits aus dem kontext klar. Interessant wäre es, um was es sich handelt. Beispielsweise maximale Annäherungstiefe wenn es sich um einen numerischen Algoritmus handelt. Dementsprechend sollten die Variablen auch benannt sein.

Was die Leerzeichen angeht, halte ich es mit Andreas Lindig. Nach einem Satzzeichen kommt ein Leerzeichen.

Einen Kommentar bei einem solchen Stück Code halte ich für Kontraproduktiv. Allenfalls vorher hin wofür die gesamte Schleife da ist. Aber jede inhaltliche Beschreibung für so ein triviales Stück Code ist überflüssig. Was es tut geht selbst für jeden Anfängerprogrammierer zweifelsfrei aus dem Code hervor.

Ansonsten halte ich mich bei bestehendem Code an den Stil darin und wenn ich die Wahl habe, kommt es auf die Sprache an. Bei Java-ähnlichen Sprachen (auch C...) sind das bei mir z. B. die Formatierungsempfehlungen von Sun. Das wichtigste sind aber imho sprechende Variablen- und Funktionsnamen. Da gehört aber für mich i,j,k... für einfache Laufvariablen dazu.

Gruss Daniela

[Tom]

Hello,

Taugt imho beides nichts. $i ist klar, das ist eine Laufvariable für eine kleine Schleife, $index ist nicht Aussagekräftiger. Genauso ist es mit $a/$min $b/$max. Beides ist nichtssagend,

Die Namen beziehen sich selbstverständlich immer auf den Kontext.

Manchmal läuft da eben der INDEX, aber andere Male der ZAEHLER, und ggf. auch die DATENSATZNUMMER

Das zeichnet eben eine Hochsprache aus.

Und ob das nun $a, $b oder $min, $max, oder $oben, $unten heißt, hängt selbstverstänlich auch vom Kontext ab.

* der nächste Satz ist auf Anraten meines zweiten ichs ersatzlos gestirchen worden *

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Bio]

Sup!

Bevor man den Code aufbläst, sollte man auch daran denken, dass jeder Bildschirm eine endliche Höhe hat und man darum nicht unendlich viel Code auf einmal sehen kann. Darum kann es auch sinnvoll sein, den Code etwas zu quetschen, damit man möglichst viel von einem Funktionsblock auf einmal sehen kann.

Wenn man mit anderen zusammenarbeitet, muss man sich halt auf einen Stil einigen.

Gruesse,

Bio

[Christoph Zurnieden]

Hi,

ich stolpere immer wieder über den mMn mangelhaften bis ungenügenden Stil im Code mancher Scripte, die ich so in die Finger bekomme.

Ja?
Also ich stolpere viel öfter über mangelhaften Code an o.a. Stellen >;->

Der Formatierungsstil ist meistens mehr oder weniger ein "Indian Hill Style", Details sind dabei Geschmackssache bzw werden vom Chef bestimmt. Richtiggehend _falsch_ ist dabei gar nichts, auch nicht das unmöglichste Durcheinander.

Ist formal ja wahrscheinlichn dasselbe. Aber ich benutze doch nicht eine Hochsprache, um die dann wieder auf weniger als Mnemonic-Code zu reduzieren?

Manches hat sich eingebürgert und das auch noch vor so langer Zeite, das Du da schon mehrere Generationen benötigst es wieder rauszubekommen. Manches davon ist auch nicht per se schlecht.
Da aber, wie oben schon erwähnt, Codeformatierung zudem auch noch viel mit persönlichem Geschmack zu tun hat erlebt jegliche Diskussion darüber verhärtete Fronten deren Rezept manch ein Betonhersteller gerne kennen würde.

Für PHP gibt es z.B. die PEAR-Coding-Standards, die ich bis auf (meine Macke:) den hochgezogenen Blockbeginn für sehr gut halte.

Auch das ist eine der besagten leichten Variationen des Indian Hill Styles. Der hochgezogene Blockbeginn (Du meinst die erste Klammer?) hat bei bestimmten Sprachen, darunter eben auch PHP, den Sinn ein versehentliches Semikolon am Zeilenende zu entschärfen.

if(...);
{
...
}

ist nunmal etwas anders als

if(...){;
...
}

Unter der hochgezogenen Klammer leidet jedoch etwas die Lesbarkeit wenn man nicht daran gewöhnt ist.

Gibt es andere Coding-Standards (für PERL, C, C++, etc.), die Euch als teoamorientiert und empfehlenswert bekannt sind?

"Teamorientiert" ist alles, was sich vollständig automatisieren läßt. Schaut also nach, welche Autoformattools es für eure Umgebung gibt, lost einen Stil der davon angebotenen Stile aus und haltet euch dann für alle offiziellen Code-Submits daran.
Am Anfang mag's noch schmerzen, aber man gewöhnt sich an alles ;-)

so short

Christoph Zurnieden

[Andreas Lindig]

Hallo Christoph,

Der hochgezogene Blockbeginn [...] hat [...] den Sinn ein versehentliches Semikolon am Zeilenende zu entschärfen.

if(...){;
...
}

*prust* - das ist ja niedlich. Mit dem gleichen Argument könnte man ja in der Klammer einer while-Schleife immer nur drei Zeichen Platz zulassen:
while(...) - warum? damit keiner aus Versehen eine while(true)-Schleife schreiben kann *g*

und ob > if(...){; wohl wahrscheinlicher passiert als > if(...);{ ? Ich glaub da ja nicht so dran. Zumal die meisten, die diese hochgezogene Schulter haben auch nicht > if(...){, sondern > if(...) { schreiben - passt also gut noch ein Semikolon dazwischen. Das ist wie mit dem Bier: "zwischen Leber und Milz passt immer noch'n Pils..."

Unter der hochgezogenen Klammer leidet jedoch etwas die Lesbarkeit wenn man nicht daran gewöhnt ist.

allerdings.

Gruß, Andreas

[Christoph Zurnieden]

Hi,

Der hochgezogene Blockbeginn [...] hat [...] den Sinn ein versehentliches Semikolon am Zeilenende zu entschärfen.

if(...){;
...
}

*prust* - das ist ja niedlich.

Niedlich ist der Umstand, das man dadurch auch noch bei jedem Codebeispiel eine Zeile Papier spart wenn es in den Druck geht (vid. Kernighan). Ich habe also anderthalb saubere, logische Argumente dafür und außer "schmeckt mir nicht" keines dagegen gefunden und in Diskussionen über Geschmack sollte ein Lebensmittel das Thema sein, jedes andere ist nur müßig.

Mit dem gleichen Argument könnte man ja in der Klammer einer while-Schleife immer nur drei Zeichen Platz zulassen:
while(...) - warum? damit keiner aus Versehen eine while(true)-Schleife schreiben kann *g*

Du kennst die Automatismen nicht, die entstehen, wenn man viel Code in einer Sprache schreibt, bei der am Zeilenende meist ein Semikolon abschließt? Da gehört nach einiger Zeit das Semikolon vor dem Return zusammen. Und Du hast Dich wahrscheinlich auch noch nie totgesucht, weil genau das von mir Beschriebene passiert ist?

Unter der hochgezogenen Klammer leidet jedoch etwas die Lesbarkeit wenn man nicht daran gewöhnt ist.

allerdings.

Warum?

so short

Christoph Zurnieden

[Andreas Lindig]

Du kennst die Automatismen nicht, die entstehen, wenn man viel Code in einer Sprache schreibt, bei der am Zeilenende meist ein Semikolon abschließt?

doch, und mir ist auch schon ein for(blah; blubb; gulp++) ; passiert... Aber Fehler passieren nunmal und auch in anderen Zusammenhängen. Ich glaube nicht daran, daß die hochgezogene Klammer Fehler einspart - dafür übersieht man andere Sachen und zwar wesentlich mehr, weil die Struktur nicht so offensichtlich ist. Z.B. übersieht man, wenn die erste { fehlt.

Unter der hochgezogenen Klammer leidet jedoch etwas die Lesbarkeit wenn man nicht daran gewöhnt ist.

allerdings.

Warum?

weil eben nicht zwei Klammern auf gleicher Spalte stehen :-) - sie bilden optisch nunmal eine Linie, dadurch daß sie kongruent sind.

Gruß, Andreas

[Christoph Zurnieden]

Hi,

Z.B. übersieht man, wenn die erste { fehlt.

Und in welcher Sprache löst das _keinen_ Parsererror aus?

Darum geht es ja: um die _versteckten_ Fehler, die, die keinen Error/Warnung vom Compiler/Interpreter auslösen und eine fehlende Klammer löst auf jeden Fall einen Fehler aus.

weil eben nicht zwei Klammern auf gleicher Spalte stehen :-) - sie bilden optisch nunmal eine Linie, dadurch daß sie kongruent sind.

Viele Worte für eine einfaches "Darum!", findest Du nicht? ;-)

Aber eine kleine Frage hätte ich doch noch: benutzt ihr eigentlich alle einen Editor, der nicht in der Lage ist, das für euch automatisch zu tun? Und vor dem Speichern/Einspielen wieder nach Gruppenrichtlinie formatiert? Wenn der Geschmack komplizierter ist, kann der erste Punkt Schwierigkeiten bereiten, gut, aber wenn's nur die Positionen von Klämmerchen und Leerzeichen sind, sollte das jeder Editor, der 'was auf sich hält problemlos können.

so short

Christoph Zurnieden

[Andreas Lindig]

Z.B. übersieht man, wenn die erste { fehlt.

Und in welcher Sprache löst das _keinen_ Parsererror aus?

PHP, C, C++, JavaScript...

dieses einfache Beispiel wird keinen Fehler auslösen:
if(rechthaben==rechtbekommen)
   blah;
   while(genau==richtig){{
      blubb;
   }
}

es wird auch funktionieren, nur logisch wohl kaum so, wie es gemeint war...

Darum geht es ja: um die _versteckten_ Fehler, die, die keinen Error/Warnung vom Compiler/Interpreter auslösen

schon verstanden, aber die kannst Du überhall bekommen. Du redest ja eigentlich über logische Fehler.

und eine fehlende Klammer löst auf jeden Fall einen Fehler aus.

eine syntatktisch fehlende - ja, aber eben nicht, wenn sie nur an der richtigen Stelle fehlt.

Viele Worte für eine einfaches "Darum!", findest Du nicht? ;-)

wollte ich in der Tat erst schreiben ;-) Warum fragst Du nach dem Warum, wenn Du keine Antwort haben willst? Das was ich dazu geschrieben habe, meine ich ernst - es ist nicht zu viel. Man wird durch solche optischen Merkmale nunmal geleitet.

Aber eine kleine Frage hätte ich doch noch: benutzt ihr eigentlich alle einen Editor, der nicht in der Lage ist, das für euch automatisch zu tun? Und vor dem Speichern/Einspielen wieder nach Gruppenrichtlinie formatiert?

kenn ich nicht. In welchem geht das dann?

Gruß, Andreas

[Christoph Zurnieden]

Hi,

dieses einfache Beispiel wird keinen Fehler auslösen:
if(rechthaben==rechtbekommen)
   blah;
   while(genau==richtig){{
      blubb;
   }
}

es wird auch funktionieren, nur logisch wohl kaum so, wie es gemeint war...

Und ich dachte immer ich wäre gut im Rausreden ;-)

Aber da oben fehlt keine Klammer, da ist eine verrutscht. Das läßt sich auch durch andere Formatierung nicht zu einer Warnung/Fehler ändern. Warum das aber ein Grund sein soll, auch die Möglichkeiten wegzuschmeißen wo das möglich ist bleibt mir verschlossen.

Und um ehrlcih zu sein: ich habe schon viel Mist selber gebaut und den von anderen debugged, so eine verrutschte Klammer ist mir da noch nie untergekommen. So ein Semikolon an der falschen Stelle aber schon öfter und nicht nur bei mir und vor allem, wenn die Klammern auf einer eigene Zeile stehen.

Darum geht es ja: um die _versteckten_ Fehler, die, die keinen Error/Warnung vom Compiler/Interpreter auslösen

schon verstanden, aber die kannst Du überhall bekommen. Du redest ja eigentlich über logische Fehler.

Die Ursache ist aber Flüchtigkeit, dafür habe ich eine Workaround vorgestellt.

und eine fehlende Klammer löst auf jeden Fall einen Fehler aus.

eine syntatktisch fehlende - ja, aber eben nicht, wenn sie nur an der richtigen Stelle fehlt.

Ja, was, entweder fehlt sie oder nicht, nur verrutscht ist nicht weg.

Viele Worte für eine einfaches "Darum!", findest Du nicht? ;-)

wollte ich in der Tat erst schreiben ;-) Warum fragst Du nach dem Warum, wenn Du keine Antwort haben willst?

Ich wollte eine und habe micht "beschwert" das ich keine bekam. So besser?

Das was ich dazu geschrieben habe, meine ich ernst - es ist nicht zu viel. Man wird durch solche optischen Merkmale nunmal geleitet.

Was aber nützt die schönste Lesbarkeit, wenn die Fehler doch beim Schreiben passieren? Besser beim Debuggen? Ja, das ist korrekt, aber ein beim Schreiben vermiedener Fehler spart den Debugger gänzlich ein.

Aber eine kleine Frage hätte ich doch noch: benutzt ihr eigentlich alle einen Editor, der nicht in der Lage ist, das für euch automatisch zu tun? Und vor dem Speichern/Einspielen wieder nach Gruppenrichtlinie formatiert?

kenn ich nicht. In welchem geht das dann?

In allen mit einer Macrosprache o.ä. Beim Emacs angefangen bis hinuter zum e3 (der hat jetzt die Möglichkeit durch die Shell zu pipen). Wenn Du sowas altes wie den Emacs nimmst, hast Du höchstwahrscheinlich schon alles mit dabei und mußt nur noch in den Details anpassen, wenn überhaupt.
Nur wenn Du wirklich eine sehr exquisiten Geschmack hast und je nach Logik andere Formatierungen haben möchtest, dann wird's kompliziert.
Genaue Empfehlungen kann ich nicht geben, da mir die Formatierung recht egal ist, wie bereits klar sein sollte. Nur wenn es ganz schlimm sein sollte, jage ich astyle drüber oder was gerade zur Hand ist.

so short

Christoph Zurnieden

[Ludger]

Hi,

Der hochgezogene Blockbeginn [...] hat [...] den Sinn ein versehentliches Semikolon am Zeilenende zu entschärfen.

if(...){;
...
}

*prust* - das ist ja niedlich.

Niedlich ist der Umstand, das man dadurch auch noch bei jedem Codebeispiel eine Zeile Papier spart wenn es in den Druck geht (vid. Kernighan). Ich habe also anderthalb saubere, logische Argumente dafür und außer "schmeckt mir nicht" keines dagegen gefunden und in Diskussionen über Geschmack sollte ein Lebensmittel das Thema sein, jedes andere ist nur müßig.

ja, das ist eine dulle Argumentation. Vergleiche das mal mit

if (Bedingung)
    {
    MachWas();
    }

In welcher Variante wird der Blockbegrenzer bzw. Anweisungsbeender "Semikolon" wohl haeufiger fehlerhaft angewandt?

Und wenn das "Semikolon" und der Zeilenvorschub/Wagenruecklauf zusammengehoert, dann ist auch was schiefgelaufen.

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

Niedlich ist der Umstand, das man dadurch auch noch bei jedem Codebeispiel eine Zeile Papier spart wenn es in den Druck geht (vid. Kernighan). Ich habe also anderthalb saubere, logische Argumente dafür und außer "schmeckt mir nicht" keines dagegen gefunden und in Diskussionen über Geschmack sollte ein Lebensmittel das Thema sein, jedes andere ist nur müßig.

ja, das ist eine dulle Argumentation.

Hübsch, gelle?
Aber ich hab' wenigstens noch Argumente >;->

Vergleiche das mal mit

if (Bedingung)
    {
    MachWas();
    }

In welcher Variante wird der Blockbegrenzer bzw. Anweisungsbeender "Semikolon" wohl haeufiger fehlerhaft angewandt?

Aha, ich sprach da oben von Geschmack und Papierersparnis und Du von Semikolon und Fehlern; somit tritt der Fall "häufigere Fehlanwendung des Semikolons" bei Deinem Beispiel auf.

Geschmacklich ist das für mich übrigens besonders daneben, da ich bei der Formatierung und verschachtelten Blocks horizontal scrollen müßte, wenn mir mein Editor da nicht behilflich wäre und alles reinkommende nach meinem, zugegebenermaßen recht einfach gestricktem Geschmack ummodelt.

Und wenn das "Semikolon" und der Zeilenvorschub/Wagenruecklauf zusammengehoert, dann ist auch was schiefgelaufen.

Meistens kommt das vor, wenn man besonders fleißig war, die Deadline zwickt oder der Chef schon hinter einem steht und gegen Ende die Konzentration etwas nachläßt. Da das Ende einer Codezeile meistens auch mit dem typographischem Zeilende übereinstimmt, kann sich da mitunter etwas einschleichen. Angenehm ist's dann, wenn der Compiler/Interpreter einen darauf hinweist; unangenehm, wenn sich der Fehler verbirgt und sich erst durch Zufall oder gar stundenlanges Debugging findet.

so short

Christoph Zurnieden

[Ludger]

Hi,

ja, das ist eine dulle Argumentation.

Hübsch, gelle?
Aber ich hab' wenigstens noch Argumente >;->

Du bist ja auch aus dem consulting Bereich.

Aha, ich sprach da oben von Geschmack und Papierersparnis und Du von Semikolon und Fehlern; somit tritt der Fall "häufigere Fehlanwendung des Semikolons" bei Deinem Beispiel auf.

Papierersparnis spielt im Entwicklungsbereich (ohne Bucherschreiber und so) keine Rolle. der zweite Satz des Absatzes scheint mir eine argumentfreie Aussage zu sein, die ich nicht kommentiere.

Geschmacklich ist das für mich übrigens besonders daneben, da ich bei der Formatierung und verschachtelten Blocks horizontal scrollen müßte, wenn mir mein Editor da nicht behilflich wäre und alles reinkommende nach meinem, zugegebenermaßen recht einfach gestricktem Geschmack ummodelt.

Du musst mal darueber nachdenken, was so passiert. Menschen schreiben software, um reale Sachverhalte nachzubauen und Geschaefte zu unterstuetzen. Man programmiert so zu sagen Entitaten. Auf Entitaeten wird (auch kombinierend natuerlich) zugegriffen (CRUDL), Zugriffe erfolgen in verschiedenen Logikebenen, Logikebenen sind idealerweise zu visualisieren, dafuer gibts Einrueckungen.

Und wenn das "Semikolon" und der Zeilenvorschub/Wagenruecklauf zusammengehoert, dann ist auch was schiefgelaufen.

Meistens kommt das vor, wenn man besonders fleißig war, die Deadline zwickt oder der Chef schon hinter einem steht und gegen Ende die Konzentration etwas nachläßt.

Nein. Es sind Fehler die passieren. Entwickler sind oft sehr konzentrationsfaehig, auch abends.   ;-)

Da das Ende einer Codezeile meistens auch mit dem typographischem Zeilende übereinstimmt, kann sich da mitunter etwas einschleichen. Angenehm ist's dann, wenn der Compiler/Interpreter einen darauf hinweist; unangenehm, wenn sich der Fehler verbirgt und sich erst durch Zufall oder gar stundenlanges Debugging findet.

Das kann ich bestaetigen.

Gruss,
Ludger

[Tom]

Hello,

Du bist ja auch aus dem consulting Bereich.

wie getze, consularische Midarbeider haben wiehr hier getze auch schohn?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christoph Zurnieden]

Hi,

Du bist ja auch aus dem consulting Bereich.

Auch wenn Du Dich darauf zu versteifen scheinst: ich bin es immer noch nicht. Ich mach das, was bezahlt wird. Nur Fenster putze ich nicht.

Du musst mal darueber nachdenken, was so passiert.

Das tue ich ungern, da wird mir immer ganz schlecht von, aber um die tägliche Lektüre der aktuellen Zeitung kommt man ja nicht herum.

Zugriffe erfolgen in verschiedenen Logikebenen, Logikebenen sind idealerweise zu visualisieren, dafuer gibts Einrueckungen.

Ja, wenn man das optisch hervorheben möchte, ist eine Einrückung nicht schlecht, wirkt sogar besser als Farbe oder Beleibtheit. Das kann ich nur unterstützen. Noch besser wären natürlich Muster, vielleicht sogar richtige Bilder, aber das wäre relativ kompliziert, den Compiler würde ich nicht schreiben wollen. Oder doch und gerade deswegen? Würde dann aber auch die Sehbehinderten ausgrenzen.

Da das Ende einer Codezeile meistens auch mit dem typographischem Zeilende übereinstimmt, kann sich da mitunter etwas einschleichen. Angenehm ist's dann, wenn der Compiler/Interpreter einen darauf hinweist; unangenehm, wenn sich der Fehler verbirgt und sich erst durch Zufall oder gar stundenlanges Debugging findet.

Das kann ich bestaetigen.

Und warum wehrst Du Dich dann so vehement gegen ein Mittelchen, das nützlich zur Vorbeugung ist? Ich zwinge niemanden dazu (selbst bei Mitarbeit an meiner eigenen Software ist mir das egal), habe nur ein paar Vorteile hervorgehoben und meiner Meinung Ausdruck gegeben, das ich das auch bei den zu erwartenden Nachteilen immer noch als ein gutes Geschäft empfinde.

Hauptaussaage meiner Antwort auf Toms Frage war:"Werdet euch einig, worauf ist egal." und dabei bleibe ich immer noch. Ansonsten wird daraus eine ellenlange, fruchtlose Diskussion über den wirklich unwichtigsten Part vom Code: die typographische Formatierung. Der Rest steht bei Darwin et al.

BTW: wie hälst Du's eigentlich bei Python, Scheme, Lisp, Assembler, Ook ... ?

so short

Christoph Zurnieden

[Ludger]

Hi,

Du bist ja auch aus dem consulting Bereich.

Auch wenn Du Dich darauf zu versteifen scheinst: ich bin es immer noch nicht.

ich hatte Dich so verstanden. Dass Du nur noch gelegentlich "den Blaumann anziehst" und so.

Ich mach das, was bezahlt wird. Nur Fenster putze ich nicht.

Du bist also nicht kaeuflich und hast Rueckgrat, sehr gut.

Du musst mal darueber nachdenken, was so passiert.

Das tue ich ungern, da wird mir immer ganz schlecht von, aber um die tägliche Lektüre der aktuellen Zeitung kommt man ja nicht herum.

Ist aber hilfreich, wenn man ein Modell hat, das beschreibt, was software und Software-Entwickler so machen.

Und warum wehrst Du Dich dann so vehement gegen ein Mittelchen, das nützlich zur Vorbeugung ist?

Weil ich nicht dran glaube,
if (bedingung) {;
     tuWas();
     }
hat mich einfach nicht ueberzeugt. Ist nicht boese gemeint, eine kleine Polemik staerkt ja nur das Immunsystem.   ;-)

Hauptaussaage meiner Antwort auf Toms Frage war:"Werdet euch einig, worauf ist egal." und dabei bleibe ich immer noch.

Du hast noch nicht gesehen, worauf sich Menschen einigen koennen.

BTW: wie hälst Du's eigentlich bei Python, Scheme, Lisp, Assembler, Ook ... ?

Ich habe bisher nur in groesserem Masse Turbo Pascal, "GW/Q BASIC", LaTex (ist das eine Programmiersprache? ;-) COBOL, VB, Perl, PHP, XSL, JavaScript und T-SQL (bzw. ANSI92 SQL) kodiert. Taete mich interessieren, ob in den von Dir erwaehnten Sprachen Specials zu beachten sind, die mein konsistentes und kohaerentes "Whitespace-Modell" in Frage stellen.   ;-)

Gruss,
Ludger

[Tim Tepaße]

Hallo,

LaTex (ist das eine Programmiersprache? ;-)

TeX ist meines Wissens Turing-Vollständig.

Taete mich interessieren, ob in den von Dir erwaehnten Sprachen Specials zu beachten sind, die mein konsistentes und kohaerentes "Whitespace-Modell" in Frage stellen.   ;-)

Äh, hast Du Dir die Aufzählung seiner Sprachen überhaupt mehr als eine Millisekunde angeguckt? Python, wo die Blockstruktur nur durch Whitespace/Einrückung dargestellt wird und das dadurch einen sehr ähnliche Schreibweise erzwingt? Der Klammerwahnsinn in LISP/Scheme? Der Brainfuck-Klon Ook?

Tim

[Christoph Zurniedenc]

Hi,

LaTex (ist das eine Programmiersprache? ;-)

TeX ist meines Wissens Turing-Vollständig.

Ah, doch? Na, so kann man sich irren, danke.

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hi,

Du bist ja auch aus dem consulting Bereich.
Auch wenn Du Dich darauf zu versteifen scheinst: ich bin es immer noch nicht.
ich hatte Dich so verstanden. Dass Du nur noch gelegentlich "den Blaumann anziehst" und so.

Ist ja auch meistens nicht nötig, da die Infrastruktur schon besteht und nicht mehr durhc Kabelkänale gekrochen werden muß. Nur bei manchen Tastaturen möchte man sich gerne zwei Lagen Gummihandschuhe übereinander anziehen.

Ich mach das, was bezahlt wird. Nur Fenster putze ich nicht.
Du bist also nicht kaeuflich und hast Rueckgrat, sehr gut.

Ich bin durchaus käuflich, Preisliste auf Anfrage.

Ist aber hilfreich, wenn man ein Modell hat, das beschreibt, was software und Software-Entwickler so machen.

Software ist reine Mathematik in anderer Sprache und der Softwareentwickler ist der Übersetzer. Wofür da noch ein Modell?

Und warum wehrst Du Dich dann so vehement gegen ein Mittelchen, das nützlich zur Vorbeugung ist?

Weil ich nicht dran glaube,

Ich hoffe nicht, das das eine theologische Diskussion wird?
Obwohl, werden die über Codeformatierung eh immer.

if (bedingung) {;
     tuWas();
     }
hat mich einfach nicht ueberzeugt.

Warum nicht? (was soll die schließende Klammer eigentlich an derart exponierter Stelle? Egal? Gut, da hast Du natürlich auch wieder Recht)

if(bed);
  {
  func();
  }

Es erfolgt keine Abzweigung, keine Fehlermeldung und keine Warnung und mit ein wenig Pech taucht der Fehler erst beim Kunden auf.

if(bed){;
  func();
  }

Erstes Semikolon ist ohne Wirkung und damit ohne Schaden.

if(bed){;
  func();
}

Ist zudem nach meinem Geschmack ganz gut lesbar, aber eben: Geschmacksache.

Hauptaussaage meiner Antwort auf Toms Frage war:"Werdet euch einig, worauf ist egal." und dabei bleibe ich immer noch.

Du hast noch nicht gesehen, worauf sich Menschen einigen koennen.

Ja, da gibt es ganz furchtbare Sachen, aber im Bereich Codeformatierung ist es wirklich völlig egal, hauptsache man ist sich überhaupt einig. Durcheinander ist dagegen meistens tödlich.

BTW: wie hälst Du's eigentlich bei Python, Scheme, Lisp, Assembler, Ook ... ?

Ich habe bisher nur in groesserem Masse Turbo Pascal, "GW/Q BASIC", LaTex (ist das eine Programmiersprache? ;-)

Ist glaube ich nicht ganz Turing-Complete.

COBOL, VB, Perl, PHP, XSL, JavaScript und T-SQL (bzw. ANSI92 SQL) kodiert. Taete mich interessieren, ob in den von Dir erwaehnten Sprachen Specials zu beachten sind, die mein konsistentes und kohaerentes "Whitespace-Modell" in Frage stellen.   ;-)

Alle o.a., deshalb habe ich sie ja gelistet. In Python ist die Formatierung sogar in der Syntax selber. Falsche Formatierung->Parse-Error. Die Klammerzäune bei Lisp sollten Dir aber auch ein Begriff sein, oder? Und Ook hat nur drei Befehle. Bei Assembler ist auch alles recht linear und dabei bunt gemischt.
Es gibt also Sprachen, die keine logischen Blöcke kennen, viel zu viel Klammern haben, fixierte Formatierung oder auch total obskur sind. Da ich auch eine Mathematik entwerfen kann, die nicht auf Logik basiert kann ich auch Sprachen entwerfen, die noch nicht einmal virtuelle logische Blöcke haben. Oder gar nicht einmal derartig abgehobene, sondern ganz einfach probabilistisch arbeitende Sprachen, die nötig werden, wenn man Quantencomputer tatsächlich nutzen möchte. (im Augenblick wird da normale Logik aufgepropft, die alle Möglichkeiten brachliegen läßt). Dafür wären dann z.B. Farben, Muster, ja ganze Bilder zur Code Formatierung ideal.

Der größte Nachteil eines Modells ist der veränderte Maßstab. Was im Kleinen paßt muß nicht auch im Großen passen und umgekehrt.

so short

Christoph Zurnieden

[Ludger]

Hi,

Ist aber hilfreich, wenn man ein Modell hat, das beschreibt, was software und Software-Entwickler so machen.

Software ist reine Mathematik in anderer Sprache und der Softwareentwickler ist der Übersetzer. Wofür da noch ein Modell?

schon ganz gut, aber was uebersetzt der Softwareentwickler denn so? Und wie tut er das?

if (bedingung) {;
     tuWas();
     }
hat mich einfach nicht ueberzeugt.

Warum nicht? (was soll die schließende Klammer eigentlich an derart exponierter Stelle? Egal? Gut, da hast Du natürlich auch wieder Recht)

Ich habe noch mal drueber geschlafen,
if (bedingung) {;
     tuWas();};
waere OK. Wuerde auch der These, dass Zeilenende und Semikolon zusammengehoeren entsprechen. Mich hatte wahnsinnig die Ungleichbehandlung des Blockbeginnanzeigers und des Blockendeanzeigers gestoert.
Nichtsdestotrotz finde ich natuerlich
if (bedingung)
     {
     tuWas();
     }
ergonomischer.

Hauptaussaage meiner Antwort auf Toms Frage war:"Werdet euch einig, worauf ist egal." und dabei bleibe ich immer noch.

Du hast noch nicht gesehen, worauf sich Menschen einigen koennen.

Ja, da gibt es ganz furchtbare Sachen, aber im Bereich Codeformatierung ist es wirklich völlig egal, hauptsache man ist sich überhaupt einig. Durcheinander ist dagegen meistens tödlich.

So, was haeltst Du denn von Einrueckungen variabler Auspraegung a la
function ()
    {
    TuWas();
    if (bedingung)
     {
     TuNochWas();
    }
    else
{
}
}

Wenn dann noch schreckliche Variablennamen (teilweise "ungarische Notation" z.B.) und "Umschichten" von Variablennamen (ich nennen das mal zynischerweise Namensraeume, also eine Informationmseinheit heisst einmal Informationseinheit, dann wieder Ieinheit und in der DB heisst das Ding EINHEIT), dann hat mans geschafft.

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

Software ist reine Mathematik in anderer Sprache und der Softwareentwickler ist der Übersetzer. Wofür da noch ein Modell?

schon ganz gut, aber was uebersetzt der Softwareentwickler denn so?

Darstellungsformen.

Und wie tut er das?

Meistens eher schlecht als recht.

Die einzigen übertragbaren guten Ingenieurseigenschaften wie Sicherheitsmargen und sonstige Angstzuschläge werden im Softwarebereich kaum berührt. Wenn man tatsächlich jeden Return einer Funktion (bzw die jeweilige sprachliche Entsprechung) auf Fehler prüft wird man ja fast schon ausgelacht "Jaja, mit Gürtel und Hosenträger, was?".
Warum? Nun, eines ist ja klar: der grundsätzliche Unterschied zwischen Soft- und Hardware ist der, das Software rein deterministisch ist und Hardware rein probabilistisch funktioniert. Die Komplexität von Software kann jedoch so weit steigen, das z.B. die Ausgabe mit deterministischen Mitteln nicht mehr von echtem Zufall zu unterscheiden ist. Oder anders ausgedrückt: dei Komplexität von Software kann derart steigen, das sie nicht mehr vollständig auf Fehler getestet werden kann sondern nur noch stichprobenartig, also statistisch, also probabilistisch. Dem kann man z.B. durch Einschränkungen der Eingangsdaten vorbeugen.

Wie man da jetzt die Klämmerchen setzt ist wirklich schnurzpiepenegal.

Ich habe noch mal drueber geschlafen,
if (bedingung) {;
     tuWas();};
waere OK. Wuerde auch der These, dass Zeilenende und Semikolon zusammengehoeren entsprechen.

Das mit Zeilenende+Semikolon ist keine These sondern eine Beobachtung mit rein phsychologischer Begründung. Wenn Du etwas nur oft genug machst entwickelt sich ein Automatismus, der dann auch bei Ausnahmen greifen kann. Auch wenn die Software deterministisch ist, der Mensch bleibt probabilistisch.

Mich hatte wahnsinnig die Ungleichbehandlung des Blockbeginnanzeigers und des Blockendeanzeigers gestoert.

Nunja, was soll man machen, sind nunmal zwei verschieden Dinger, da kannst Du nicht auch noch das gleiche Zeichen für nehmen. Zumindest nicht, wenn die Sprache Verschachtelungen zuläßt.

Ja, da gibt es ganz furchtbare Sachen, aber im Bereich Codeformatierung ist es wirklich völlig egal, hauptsache man ist sich überhaupt einig. Durcheinander ist dagegen meistens tödlich.

So, was haeltst Du denn von Einrueckungen variabler Auspraegung a la
function ()
    {
    TuWas();
    if (bedingung)
     {
     TuNochWas();
    }
    else
{
}
}

Nix natürlich, da würde ich vorher eine Formatierer drüberjagen. Aber was habe ich damit zu tun? Wenn diese Art der Formatierung den Leuten gefällt und die damit klarkommen, dann sollen die das auch benutzen.

Wenn dann noch schreckliche Variablennamen (teilweise "ungarische Notation" z.B.)

Ja, die sind furchtbar, aber auch aus der Not geboren. Auch daran gewöhnt man sich jedoch. Oder möchtest Du hier die Produktqualität von Microsoft mit deren Vorliebe für ungarische Notation verbinden? Nein, das wäre sogar mir zu wild ;-)

und "Umschichten" von Variablennamen (ich nennen das mal zynischerweise Namensraeume, also eine Informationmseinheit heisst einmal Informationseinheit, dann wieder Ieinheit und in der DB heisst das Ding EINHEIT), dann hat mans geschafft.

Darum sagte ich ja auch ausdrücklich, das jegliche Art von Durcheinander zu vermeiden sei. Damit das auch über Laborgrenzen passiert sollte am besten jemand drüber wachen, auch wenn das teuer ist.

so short

Christoph Zurnieden

[Ludger]

Hi,

Software ist reine Mathematik in anderer Sprache und der Softwareentwickler ist der Übersetzer. Wofür da noch ein Modell?

schon ganz gut, aber was uebersetzt der Softwareentwickler denn so?

Darstellungsformen.

ah, da kriegt man Dich zu packen. Du weisst nicht, was ein Softwareentwickler macht. So so.

Warum? Nun, eines ist ja klar: der grundsätzliche Unterschied zwischen Soft- und Hardware ist der, das Software rein deterministisch ist und Hardware rein probabilistisch funktioniert.

habe ich schon gehoert, das mit der Software. Glauben tue ich immer noch nicht dran. Mag sein, dass es so ist, aber es ist praktischer (und defensiver) davon auszugehen, dass dem nicht so ist.

Die Komplexität von Software kann jedoch so weit steigen, das z.B. die Ausgabe mit deterministischen Mitteln nicht mehr von echtem Zufall zu unterscheiden ist. Oder anders ausgedrückt: dei Komplexität von Software kann derart steigen, das sie nicht mehr vollständig auf Fehler getestet werden kann sondern nur noch stichprobenartig, also statistisch, also probabilistisch. Dem kann man z.B. durch Einschränkungen der Eingangsdaten vorbeugen.

Hmm.

Mich hatte wahnsinnig die Ungleichbehandlung des Blockbeginnanzeigers und des Blockendeanzeigers gestoert.

Nunja, was soll man machen, sind nunmal zwei verschieden Dinger, da kannst Du nicht auch noch das gleiche Zeichen für nehmen. Zumindest nicht, wenn die Sprache Verschachtelungen zuläßt.

Blockbegrenzer sind Blockbegrenzer, also eine Entitaet.

Gruss,
Ludger

PS: Damit da kein falscher Eindruck entsteht, ich versuche nur auf Saetze und Abschnitte zu antworten, die ich nicht unterschreiben wuerde.

[Christoph Zurnieden]

Hi,

da ich hier eh beim Rechnungschreiben bin...
(Eine normalerweise schöne Beschäftigung, aber nicht wenn der Kunde Einzelteilauflistung wünscht, das auch so meint und ich hier mit einem Satz Buntstiften, einer Zähluhr und dem Verkabelungsplan (in Din-A-0 und noch zu klein) sitze und Schräubchen zähle ;-)

schon ganz gut, aber was uebersetzt der Softwareentwickler denn so?

Darstellungsformen.

ah, da kriegt man Dich zu packen.

Wenn Du nett gefragt hättest hätte ich Dir auch die Hand gerecijht, da brauchst Du nicht im griechisch-römischem Stil nach Angriffspunkten suchen.

Du weisst nicht, was ein Softwareentwickler macht. So so.

Ja, teilweise frage ich mich das wirklich: Was macht der Kerl da eigentlich? (Wahrscheinlich nicht geschlechtsspezifisch, kam mir aber nur bei Männern unter)

Der Softwarentwickler soll genau das tun, was ich geschrieben habe, er soll von einer Darstellungsform (von mathematischen Regeln) z.B. einer humansprachlichen Beschreibung in eine andere Darstellungsform z.B. ix86-32 Maschinencode übersetzen ohne die ursprünglich enthaltene Information zu verändern.
Das ist die Kernaufgabe. Es heißt aber doch "Entwickler"? Ja, gut, dann soll er seine Erfahrung in der Übersetzungsarbeit einbringen und ... ja was denn nun tun? Höchstens noch den Hardwarebedarf angeben, was das eine oder andere Projekt natürlich scheitern läßt. Und was noch?

Nein, der Softwareentwickler ist gar kein Entwickler der ist Übersetzer. Das ist aber auch nichts Schlechteres oder Besseres als Entwickler, deshalb sind Namen ja auch so gerne Schall und Rauch. Mit ein bischen Geschick bei der Formulierung läßt sich gleiches ja auch über einen Architekten sagen.

Also sage, was Du unter Softwareentwickler verstehst oder besser, wie der Softwareentwickler sich selber versteht dann verstehe ich Dich vielleicht auch mal.

Warum? Nun, eines ist ja klar: der grundsätzliche Unterschied zwischen Soft- und Hardware ist der, das Software rein deterministisch ist und Hardware rein probabilistisch funktioniert.

habe ich schon gehoert, das mit der Software. Glauben tue ich immer noch nicht dran. Mag sein, dass es so ist,

Es ist tatsächlich und beweisbar so und nicht anders. Aber wie Du schon richtig bemerktest:

aber es ist praktischer (und defensiver) davon auszugehen, dass dem nicht so ist.

Da fehlt allerdings noch eine wichtige Kleinigkeit am Ende: wenn es möglich ist.
Da Schlimmste, noch vor dem Datenverlust, ist unbemerkte Datenänderung. Auch wenn ich bei Hardware nicht unbedingt Computerhardware meinte (war aber auch mißverständlich ausgedrückt, meine Schuld) so gilt es auch da. Wenn Du wirklich vermeiden willst, das Daten verändert werden, dann mußt Du unter anderem auch den Umstand einschließen, das hin und wieder ein Teilchen/Feld genügend Energie besitzt ein oder mehrere Bit im Speicher zu flippen. Warum meinst Du gibt es z.B. ECC-RAM? Auch bei der Festplatte, da allerdings umgekehrt. Es ist schwierig alles zu löschen, da das Bit keinen Punkt (mit nur einer Dimension) belegt sondern einen relativ großen Raum (mit drei Dimensionen) beansprucht. Das wird dann probabilistisch und die Wahrscheinlichkeitsrechnung zusammen mit der Quantenphysik sagt Dir dann, das Du so oft löschen kannst, wie Du willst und doch nie alles löschen kannst.
Außerdem geht Information nie verloren, aber den Teil kannst Du mit heutiger Hardware noch getrost ignorieren.

Zudem ist unsere Realität 4-dimensional und der Einfluß der Zeit wird im Softwarebereich gerne mal unterschätzt. Was heute nicht funktionieren mag, kann es morgen schon tun.

Hmm.

?
Du bist doch sonst nicht auf's Maul gefallen und jetzt so still?

Blockbegrenzer sind Blockbegrenzer, also eine Entitaet.

Im Lexer, klar, aber im Code? Eher selten.
Aber ich weiß ja, wie Du das meinst.

so short

Christoph Zurnieden

[Ludger]

Hi,

Also sage, was Du unter Softwareentwickler verstehst oder besser, wie der Softwareentwickler sich selber versteht dann verstehe ich Dich vielleicht auch mal.

ja, die Kernfrage, die Frage nach dem Sinn des Lebens so zu sagen. War die letze offene konzeptionelle Frage, die ich mir beantworten konnte,

Ich analysiere das wie folgt.
Menschliche Kooperationsbemuehungen resultieren in einem Wirtschaftssystem, dank der wunderschoenen Erfindung des Geldes, also von konvertiblen und garantierten "Belohnungspunkten" wurde aus der Wirtschaft, also aus der Summe zwischenmenschlicher Kooperationen, die Geldwirtschaft, die uns nun alle beschaeftigt.

Geschaefte sind die Folge, die in der Realitaet stattfinden und irgendwann kam man mal auf die Idee bestimmte Ablaeufe mit den Mitteln der IT (sagen wir mal ab 1940) zu unterstuetzen. Anfaenglich kam man da mit Halbloesungen, da konnte man z.B. wichtige Rechnungsdaten speichern waehrend andere Bereiche der Realitaet wegen hoher IT-Betriebskosten (Speicherplatz und CPU-Zeit z.B.) IT-seitig keine Nachbildung erfahren haben.

So um 1975 kam der Professer Chen auf die Idee sich die Realitaet etwas genauer anzuschauen und kam mit seinem entity relationsship model, der "intellektuellen" Basis der relationalen Datenhaltung. Und da relationale Datenhaltung in Tabellen Entitaeten haelt und die Beziehungen zwischen diesen ueber Regeln implementiert, konnten auf einmal grosse und komplexe Sachverhalte nachgebaut und unterstuetzt werden. Das Aufkommen von Sequel tat ein Uebriges und der Datenzugriff wurde verglichen mit dem ISAM-Datenzugriff besser unterstuetzt. Die Geschaeftslogik liess sich nun schoen modellieren.

Und das fuehrte dazu, dass irgendwann die nachgebaute Realitaet um Sachverhalte erweitert wurde, die es in der Realitaet selbst nur noch als logische Konstrukte im Menschengehirn gibt. Oder nicht einmal mehr das.

Der Softwareentwickler sitzt da nun irgendwie mittendrin. Sein Augenmwek sollte darauf gerichtet sein die Architektur des ganzen brauchbar zu gestalten. So gibts nicht ohne Grund zurzeit solche Modewoerter wie SOA (soll wohl nach SOAP klingen) und Webservices. Man hat also so zu sagen als letztes den Austausch von Daten ueber XML sprechende Dienste optimiert.

Man muss also also IT-Fachkraft in komplexeren Umgebungen irgendwie den ganzen Mist am Laufen halten, da scheint mir Deine Ausage ein Entwickler ist Uebersetzer eines mathematischen Modells in ein anderes mathematisches Modell (die Software) nicht ausreichend.

Bestimmte Leute schwaetzen davon, dass Projektarbeit Kunst ist. Gefaellt mir auch, obwohl ich lange an eine rein ingenieursmaessig gehaltene Taetigkeit geglaubt habe.

Mir schwebt uebrigens so eine "komponentenbaiserte" Architektur vor mit so Sachen wie einem Geschaeftslogikteil und verschiedenen Kommunikationskomponenten (raus aus dem Firmennetz) und solchen Komponenten wie RDBMSe, die XML basiert kommunizieren und OODBMSe mittendrin.

Umgeben wird diese Gruppe, nennen wir sie mal back end, von Clientapplikationen wie websites ("Webapplikationen") oder "rich" Clients aus dem Hause Micro$soft an denen man manchmal nicht vorbeikommt.

Lustig und sicherlich erwaehnenswert der permanente (vielleicht auch nur vermeintliche) Interessenkonflikt zwischen ITlern und BWLern.

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

Also sage, was Du unter Softwareentwickler verstehst oder besser, wie der Softwareentwickler sich selber versteht dann verstehe ich Dich vielleicht auch mal.

ja, die Kernfrage, die Frage nach dem Sinn des Lebens so zu sagen. War die letze offene konzeptionelle Frage, die ich mir beantworten konnte,

Wieviele hast Du denn dann noch offen? Kann man bei der Beantwortung behilflich sein?

Geschaefte sind die Folge, die in der Realitaet stattfinden und irgendwann kam man mal auf die Idee bestimmte Ablaeufe mit den Mitteln der IT (sagen wir mal ab 1940)

Na, sagen wir mal ziemlich genau ab 1890 mit dem US-Census vom gleichem Jahr.

zu unterstuetzen. Anfaenglich kam man da mit Halbloesungen, da konnte man z.B. wichtige Rechnungsdaten speichern waehrend andere Bereiche der Realitaet wegen hoher IT-Betriebskosten (Speicherplatz und CPU-Zeit z.B.) IT-seitig keine Nachbildung erfahren haben.

Um 1940 war die Technik hingegen bereits soweit fortgeschritten, das nur noch Geld die Nutzung einschränken konnte. Mit genügend davon ging hingegen alles. So waren bereits die Techniken des Datamining (schönes Wort bezeichnet aber nur die bekannte statistische Methode Extrema auszusieben, gefunden irgendwann so um die siebzehnhundertschlagmichdoht) inklusive relationeller und objektartiger Beziehungen gut bekannt. Externes Sortieren mit nicht mehr als 3 Registern, dementsprechend auch das Suchen und die Datenhaltung. Und wozu? Eine recht bittere Pille: für die Logistik des Holocausts.

So um 1975 kam der Professer Chen auf die Idee sich die Realitaet etwas genauer anzuschauen und kam mit seinem entity relationsship model, der "intellektuellen" Basis der relationalen Datenhaltung.

Der hat's auch nur beschrieben, nicht erfunden. Schau in seine Literaturliste.

Die Geschaeftslogik liess sich nun schoen modellieren.

Grundsätzliche Geschäftslogik: billig einkaufen, teuer verkaufen und sich nicht von Finanzamt erwischen lassen. Mehr ist da nicht, alles andere ist nur bunte Tapete.

Ja, genau: ich behaupte, das ein Großteil der bunten Klickmichs völlig überflüssig ist und teilweise sogar den Zweck der Geldvermehrung behindert.

Die Datenbanken werden mit riesigen Mengen, wirklich unvorstellbar großen Massen an Daten bestückt, nur um mit ausgefuchstem Datamining etwas an Information rauszuquetschen, um dem Filialleiter nachweisen zu können, das er zu blöd war zu sehen, das er den Umsatz um gnadenlose 0.01% hätte steigern können, hätte er nur rechtzeitig seine Glaskugel befragt.
Einziger Vorteil solcher Datenhaltung ist die Möglichkeit sein Firmengespinst derart zu verweben, das das Finanzamt vor Ablauf der Verjährungsfristen nicht mehr drankommt. Das nützt dem Geschäft, klar, aber nicht unbedingt auf die Weise, mit der die Hochglanzbroschüren werben.
Alles unterhalb großer Firmenkonglomerate und sonstiger Krimineller braucht den Kram einfach nicht -- weder die Daten noch den Bergbau.

Trotzdem sind die Siebziger markant: sie sind die letzten Jahre, die noch wirkliche Fortschritte in der Mathematik der Datenverarbeitung brachten. Seitdem ist -- nunja, ich sag's wie's ist: Ebbe. Alles wurde bunter, jede Einigung auf ein Protokoll wurde frenetisch gefeiert, als ob man eine neue Sortiermethode gefunden hätte, die mit O(0.5) arbeitet aber grundlegend passiert ist nix. Halt, nein, stimmt nicht ganz: es gibt mittlerweile serienreifen quantenkryptographischen Schutz für Netzverbindungen wenn auch nur in engen Grenzen. Aber das ist weniger eine mathematische denn eine reine Ingenieurleistung, die Theorie dafür wurde schon vor rund 80 Jahren gelegt (zu faul zum Nachschauen, wann genau).

Der Softwareentwickler sitzt da nun irgendwie mittendrin. Sein Augenmwek sollte darauf gerichtet sein die Architektur des ganzen brauchbar zu gestalten. So gibts nicht ohne Grund zurzeit solche Modewoerter wie SOA (soll wohl nach SOAP klingen) und Webservices. Man hat also so zu sagen als letztes den Austausch von Daten ueber XML sprechende Dienste optimiert.

Tja, man muß halt stets ein paar neue Kleider erfinden, sonst wird man arbeitslos.

Man muss also also IT-Fachkraft in komplexeren Umgebungen irgendwie den ganzen Mist am Laufen halten,

Ja, wurde denn nur Mist übersetzt?
Wenn das so komplex ist, das sich ganz merkwürdige Seiteneffekte ergeben, dann ist das ein Bug. Wahrscheinlich ist sogar die Komplexität selber der Bug. "Keep it simple, Dude!" ist eine eiserne Regel, wer dagegen verstößt darf sich nicht über Löcher in den Füßen wundern.

da scheint mir Deine Ausage ein Entwickler ist Uebersetzer eines mathematischen Modells in ein anderes mathematisches Modell (die Software) nicht ausreichend.

Dsa ist vollkommen ausreichend, das paßt überall, ist Dir lediglich nicht detailiert genug.

Bestimmte Leute schwaetzen davon, dass Projektarbeit Kunst ist. Gefaellt mir auch, obwohl ich lange an eine rein ingenieursmaessig gehaltene Taetigkeit geglaubt habe.

Kunst kann viel mit Mathematik gemein haben, aber umgekehrt auch? Ist eine gute Frage.

Mir schwebt uebrigens so eine "komponentenbaiserte"

Ist das ein freudscher Vertipper?
(Baiser = im Ofen getrocknete Masse aus gezuckertem und geschlagenem Hühnereiweiß. Süße Luft sozusagen)

Architektur vor mit so Sachen wie einem Geschaeftslogikteil und verschiedenen Kommunikationskomponenten (raus aus dem Firmennetz) und solchen Komponenten wie RDBMSe, die XML basiert kommunizieren und OODBMSe mittendrin.

Hübsch. Vollkommen redundant, aber hübsch.

Umgeben wird diese Gruppe, nennen wir sie mal back end, von Clientapplikationen wie websites ("Webapplikationen") oder "rich" Clients aus dem Hause Micro$soft an denen man manchmal nicht vorbeikommt.

Man kommt immer vorbei, ist mitunter nur mit Brachialgewalt zu schaffen, aber man kommt immer vorbei. Vor allem wenn es sich um fast vierzig Jahre alte Ideen handelt, die ein recht großer Softwarekonzern geklaut^Waufgenommen und zurück^Wweiterentwickelt hat. War es früher Mainframe mit dumb Terminals, so waren es später rich Clienst ohne Mainframe. Hat beides seine Vor- und Nachteile ist aber auch beides nicht grundsätzlich schlecht. Dann kommt besagter großer Softwarekonzern mit Mainframe plus rich Clients (Denn was sind "Webapplikationen" anderes?)? Nein, tut mir leid, aber das ist komplett hanebüchen.

Lustig und sicherlich erwaehnenswert der permanente (vielleicht auch nur vermeintliche) Interessenkonflikt zwischen ITlern und BWLern.

Ist wahrscheinlich recht ambivalent bei den BWLern: einerseits bringt die IT seit rund 30 Jahren nichts Neues mehr, andererseits verkauft sich das aber wie geschnitten Brot.
Weniger höfliche These: für den gemeinen BWLer reduziert sich der Rechner auf den möglichen Gewinn beim Verkauf, ansonsten kann er damit rein gar nix anfangen.

Da ich hauptsächlich klein- und mittelständische Betriebe betreue, kann ich Dir aus eigener Erfahrung sagen, das im Schnitt zwischen dem 50 und 250-fachen an benötigter Rechenleistung erworben wurde, etwa das 1.000-fache an Speicher und dazu noch Software mit rund 50.000 Funktionen zuviel. Das kostet mehr als es bringt, ist ein schlechtes Geschäft für den Benutzer.

Andererseits hat diese Rechenleistung auch, insbesondere in Verbindung mit der digitalen Videoamera aber auch im Bereich Audio und vor allem wegen der preiswerten Breitbandanschlüsse vieles im künstlerischem Bereich möglich gemacht, das vorher extrem kostenintensiv war. Und ohne den dringenden Bedarf oben beschriebener im Grunde vollkommen überflüssiger grellbunter Klickmichs an Rechenkraft hätte sich eben jene Rechenkraft nicht so rasant entwickelt.

"Zwei Seelen wohnen, ach! in meiner Brust" spricht Faust zu Wagner, mir geh's hier ähnlich.

so short

Christoph Zurnieden

[Ludger]

Hi,

eigentlich wollte ich da jetzt ganz langsam mal die Diskussion einstellen, ging es doch anfaenglich mal um sinnvolle Einrueckungen und die Frage der Gleichbehandlung der beiden unterschiedlichen Blockbegrenzern.   ;-)

Um 1940 war die Technik hingegen bereits soweit fortgeschritten, das nur noch Geld die Nutzung einschränken konnte. Mit genügend davon ging hingegen alles.

Ich glaube, das stimmt einfach nicht.

So waren bereits die Techniken des Datamining (schönes Wort bezeichnet aber nur die bekannte statistische Methode Extrema auszusieben, gefunden irgendwann so um die siebzehnhundertschlagmichdoht) inklusive relationeller und objektartiger Beziehungen gut bekannt.

Datamining war zu jener Zeit wirklich ein Mining in den Akten.

Externes Sortieren mit nicht mehr als 3 Registern, dementsprechend auch das Suchen und die Datenhaltung. Und wozu? Eine recht bittere Pille: für die Logistik des Holocausts.

Das habe ich auch irgendwo gelesen. War doch eine amerikanische Firma (IBM?), die geliefert hat, oder?

So um 1975 kam der Professer Chen auf die Idee sich die Realitaet etwas genauer anzuschauen und kam mit seinem entity relationsship model, der "intellektuellen" Basis der relationalen Datenhaltung.

Der hat's auch nur beschrieben, nicht erfunden. Schau in seine Literaturliste.

Die Realitaet hats erfunden, Hr.Chen beschrieben. Natuerlich verweist Hr.Chen auch auf andere Schriften, warum auch nicht.

Die Geschaeftslogik liess sich nun schoen modellieren.

Grundsätzliche Geschäftslogik: billig einkaufen, teuer verkaufen und sich nicht von Finanzamt erwischen lassen. Mehr ist da nicht, alles andere ist nur bunte Tapete.

Nein, das stimmt nicht. Geschaeftslogik kann sehr sehr kompliziert sein. Nicht notwendigerweise kuenstlich kompliziert gemacht.

Ja, genau: ich behaupte, das ein Großteil der bunten Klickmichs völlig überflüssig ist und teilweise sogar den Zweck der Geldvermehrung behindert.

Das ist schon richtig, wenn Du meinst, dass da zuviel Software auf zuviel Hardware laeuft und die Programmierer kuenstlich taeglich ein wenig Komplexitaet hinzubauen (oder so viel sie koennen ;-).

Man muss also also IT-Fachkraft in komplexeren Umgebungen irgendwie den ganzen Mist am Laufen halten,

Ja, wurde denn nur Mist übersetzt?

Jede Software kommt mit einem kuenstlich hinzugebauten Mass an Komplexitaet, je mehr Software laeuft und "integriert" wird, desto mehr (unnoetige) Komplexitaet ist irgendwann vorhanden. Das ist Mist, das ist natuerlich und normal.

da scheint mir Deine Ausage ein Entwickler ist Uebersetzer eines mathematischen Modells in ein anderes mathematisches Modell (die Software) nicht ausreichend.

Dsa ist vollkommen ausreichend, das paßt überall, ist Dir lediglich nicht detailiert genug.

Wem kann denn eine Aussage wie "alles fliesst" detailliert genug sein?

Bestimmte Leute schwaetzen davon, dass Projektarbeit Kunst ist. Gefaellt mir auch, obwohl ich lange an eine rein ingenieursmaessig gehaltene Taetigkeit geglaubt habe.

Kunst kann viel mit Mathematik gemein haben, aber umgekehrt auch? Ist eine gute Frage.

Umgekehrt auch.

Mir schwebt uebrigens so eine "komponentenbaiserte"

Ist das ein freudscher Vertipper?
(Baiser = im Ofen getrocknete Masse aus gezuckertem und geschlagenem Hühnereiweiß. Süße Luft sozusagen)

Ein Schreibfehler, normalerweise wird sowas hier nicht bemaengelt.

Architektur vor mit so Sachen wie einem Geschaeftslogikteil und verschiedenen Kommunikationskomponenten (raus aus dem Firmennetz) und solchen Komponenten wie RDBMSe, die XML basiert kommunizieren und OODBMSe mittendrin.

Hübsch. Vollkommen redundant, aber hübsch.

Beschreibe bitte die Redundanz.

[...] Dann kommt besagter großer Softwarekonzern mit Mainframe plus rich Clients (Denn was sind "Webapplikationen" anderes?)? Nein, tut mir leid, aber das ist komplett hanebüchen.

"Webapplikationen" sind rich clients, aber nicht nur rich clients. Du bist rhetorisch einfach zu gut ausgebildet, hast Du BWL studiert?

Lustig und sicherlich erwaehnenswert der permanente (vielleicht auch nur vermeintliche) Interessenkonflikt zwischen ITlern und BWLern.

Ist wahrscheinlich recht ambivalent bei den BWLern: einerseits bringt die IT seit rund 30 Jahren nichts Neues mehr, andererseits verkauft sich das aber wie geschnitten Brot.
Weniger höfliche These: für den gemeinen BWLer reduziert sich der Rechner auf den möglichen Gewinn beim Verkauf, ansonsten kann er damit rein gar nix anfangen.

Ich meine, dass die Denkweisen einfach nicht auf einen Nenner zu bringen sind. So aehnlich wie ein Arzt (der ITler) seinen Patienten (den BWLer) "besonders" behandeln muss. Lustigerweise scheint der Patient den Arzt zudem nicht so zu moegen und primaer als Kostenfaktor zu betrachten. Aber auch das ist logisch, denn einige ITler taugen einfach nichts ("Powerpoint Consulter" (Prof Wulff, FH Steinfurt)) und manchmal eben berechtigt.

Da ich hauptsächlich klein- und mittelständische Betriebe betreue, kann ich Dir aus eigener Erfahrung sagen, das im Schnitt zwischen dem 50 und 250-fachen an benötigter Rechenleistung erworben wurde, etwa das 1.000-fache an Speicher und dazu noch Software mit rund 50.000 Funktionen zuviel. Das kostet mehr als es bringt, ist ein schlechtes Geschäft für den Benutzer.

Na, sind die denn auch gut beraten worden?   ;-)
(Ich bin sicher, dass ja. :-))

"Zwei Seelen wohnen, ach! in meiner Brust" spricht Faust zu Wagner, mir geh's hier ähnlich.

In diesem Sinne.

Gruss,
Ludger

[Christoph Zurnieden]

Hi,

eigentlich wollte ich da jetzt ganz langsam mal die Diskussion einstellen, ging es doch anfaenglich mal um sinnvolle Einrueckungen und die Frage der Gleichbehandlung der beiden unterschiedlichen Blockbegrenzern.   ;-)

Ach, solange sich keiner beschwert ...

Um 1940 war die Technik hingegen bereits soweit fortgeschritten, das nur noch Geld die Nutzung einschränken konnte. Mit genügend davon ging hingegen alles.

Ich glaube, das stimmt einfach nicht.

Eine theologische Diskussion wollte ich jetzt aber wirklich nicht betreiben.
Klar bekommt man auch für noch soviel Geld nicht alles, aber der Mathematiker würde das durchaus als asymptotische Näherung betrachten. Immerhin ging es um einige Milliarden EUR (nur ungefähre Wertbereinigung, für genaue Zahlen müßt' ich nachschlagen), da schmeißt der amerikanische Geschäftsmann gerne mal das Lexikon von E bis M in die Ecke.

So waren bereits die Techniken des Datamining (schönes Wort bezeichnet aber nur die bekannte statistische Methode Extrema auszusieben, gefunden irgendwann so um die siebzehnhundertschlagmichdoht) inklusive relationeller und objektartiger Beziehungen gut bekannt.

Datamining war zu jener Zeit wirklich ein Mining in den Akten.

Nein, das war komplett computerisiert. Zwar alles über Lochkarten, aber so kleinlich wollen wir ja nicht sein, das hier die Hardware den Begriff definiert.

Externes Sortieren mit nicht mehr als 3 Registern, dementsprechend auch das Suchen und die Datenhaltung. Und wozu? Eine recht bittere Pille: für die Logistik des Holocausts.

Das habe ich auch irgendwo gelesen. War doch eine amerikanische Firma (IBM?), die geliefert hat, oder?

Ja, Hollerith hatte da Lieferschwierigkeiten glaube ich.

Der hat's auch nur beschrieben, nicht erfunden. Schau in seine Literaturliste.

Die Realitaet hats erfunden, Hr.Chen beschrieben.

Sollte bei mir natürlich "gefunden" heißen, nicht "erfunden", sorry.

Grundsätzliche Geschäftslogik: billig einkaufen, teuer verkaufen und sich nicht von Finanzamt erwischen lassen. Mehr ist da nicht, alles andere ist nur bunte Tapete.

Nein, das stimmt nicht. Geschaeftslogik kann sehr sehr kompliziert sein. Nicht notwendigerweise kuenstlich kompliziert gemacht.

Nein, natürlich nicht unbedingt künstlich gemacht, aber all das, was da so hochkomplex aussieht ist es gar nicht und läßt sich immer auf obige drei Regeln reduzieren. Wenn nicht, läuft irgendetwas falsch und die Firma geht bald pleite.

Du darfst aber natürlich auch nicht das Produkt mit dem Geschäft verwechseln. So ist die Logistik eines weltweit agierenden Paketversender mit Sicherheit hochkomplex, jedoch ist die Geschäftslogik auch hier: billig einkaufen (geringe Löhen, Mengenrabatt bei Verkehrsmitteln usw), teuer verkaufen (je nach Unternehmen ist so ein Paket verdammt teuer) und nicht vom Finanzamt erwischen lassen (z.B. "freie" Mitarbeiter beschäftigen, mit dem Finanzminister des Hauptsitzes etwas auskungeln etc)

Jede Software kommt mit einem kuenstlich hinzugebauten Mass an Komplexitaet, je mehr Software laeuft und "integriert" wird, desto mehr (unnoetige) Komplexitaet ist irgendwann vorhanden. Das ist Mist, das ist natuerlich und normal.

Mist ist höchsten noch bei Nutzvieh natürlich und normal, bei Software jedoch einfach nicht hinnehmbar.

Wem kann denn eine Aussage wie "alles fliesst" detailliert genug sein?

Dem Rohrreiniger.

Mir schwebt uebrigens so eine "komponentenbaiserte"

Ist das ein freudscher Vertipper?
(Baiser = im Ofen getrocknete Masse aus gezuckertem und geschlagenem Hühnereiweiß. Süße Luft sozusagen)

Ein Schreibfehler, normalerweise wird sowas hier nicht bemaengelt.

Ich habe nichts bemängelt (denn ich sitze da ja eh im Glashaus) sondern mich nur über den dadurch entstehenden Sinn amüsiert und etwas gestichelt.

Beschreibe bitte die Redundanz.

Da es auch anders geht, ist es redundant.
Oder:
Da es auch ohne geht ist es sogar überflüssig.

"Webapplikationen" sind rich clients, aber nicht nur rich clients.

Das war nur ein Beispiel, das den Sachverhalt erläutern sollte.

Du bist rhetorisch einfach zu gut ausgebildet,

Ich habe in der Jugend so viel Mist gebaut: das dauernde Rausreden übt dahingehend ungemein.

hast Du BWL studiert?

Da ich einfach anzunehmen habe, das Du das nicht beleidigend gemeint hast, werde ich die auf die ansonsten fällige nonverbale Response verzichten.
Achso: nein, ich habe kein BWL studiert.

Da ich hauptsächlich klein- und mittelständische Betriebe betreue, kann ich Dir aus eigener Erfahrung sagen, das im Schnitt zwischen dem 50 und 250-fachen an benötigter Rechenleistung erworben wurde, etwa das 1.000-fache an Speicher und dazu noch Software mit rund 50.000 Funktionen zuviel. Das kostet mehr als es bringt, ist ein schlechtes Geschäft für den Benutzer.

Na, sind die denn auch gut beraten worden?   ;-)
(Ich bin sicher, dass ja. :-))

Problem dabei: es hätte nichts genutzt.
Auch wenn z.B. die alten Sparcstations noch laufen, die sind irgendwann einfach nicht mehr zuverlässig genug wenn die MTTF deutlich überschritten ist. Bei einer Sparcstation wäre das heute vor ungefähr 15 Jahren gewesen. Dazu kommt noch das Finanzamt also gibt es alle paar Jahre neue Maschinen, ob man die braucht oder nicht. Nach und nach liefen die Betriebsysteme nicht mehr mit der neuen Hardware, es wurden neue Betriebsysteme fällig. Darauf liefen dann nach und nach die alten Programme nicht mehr: s.o. Als dann auch noch die Unsitte aufkam, die neuen Maschinen direkt mit aller "nötigen" Software vorzurüsten, war's dann ganz vorbei.
Mittlerweile ist das so schlimm geworden, das es bei der Hardware nur noch entweder "billig" oder "Big Iron" gibt. Dazwischen gibt es rein gar nichts mehr. Wenn Du Dir kein großes Eisen leisten kannst (wer kann das schon?) und möchtest für gutes Geld anständige Qualität bekommen ist das ein aussichtsloses Unterfangen. Wenn es etwas teurer ist, ist es ausschließlich schneller&größer aber hält nur noch halb so lange oder ist gleich beim Einschalten defekt. (Mainboards scheinen am schlimmsten zu sein oder ich bin zu blöd die einzubauen, auf jeden Fall habe ich mittlerweile runde 30% Sofortausfälle bei MBs, dicht gefolgt von RAM mit etwa 12% und (non-SCSI)HDs mit über 5%) Dazu dann noch den Umstand, das man sich mit der voraufgespielten Software bereits nach 5 Minuten im öffentlichem Netz (Internet) irgendeinen Schädling eingefangen hat. Und jetzt komm mir nicht mit Apple, deren Hardware ist mittlerweile genauso schlimm (Preisbereinigt natürlich), nur deren Software ist inzwischen ganz anständig geworden.

Wie Du siehst: man kommt gar nicht drumherum, ob man das nun möchte oder nicht.

so short

Christoph Zurnieden

[Ludger]

Hi,

Grundsätzliche Geschäftslogik: billig einkaufen, teuer verkaufen und sich nicht von Finanzamt erwischen lassen. Mehr ist da nicht, alles andere ist nur bunte Tapete.

Nein, das stimmt nicht. Geschaeftslogik kann sehr sehr kompliziert sein. Nicht notwendigerweise kuenstlich kompliziert gemacht.

Nein, natürlich nicht unbedingt künstlich gemacht, aber all das, was da so hochkomplex aussieht ist es gar nicht und läßt sich immer auf obige drei Regeln reduzieren. Wenn nicht, läuft irgendetwas falsch und die Firma geht bald pleite.

ich weise mal dankbar auf mein persoenliches highlight Deines Beitrags hin und kuendige hiermit an diese Verargumentierung in mein aktives Vokabular mit aufzunehmen. Einfachheit liebe ich bekanntlcih. Und Einwandsbehandlungen erfolgen also mit dem Hinweis darauf, dass Geschaeftslogik nicht mit Produktlogik zu verwechseln ist.

Ich hoffe mal, dass mich sowas noch weiter nach oben bringen und mich nicht eines Tages die Ruebe kosten wird.

Gruss,
Ludger

[Jan L.]

Hallo,

Gibt es andere Coding-Standards (für PERL, C, C++, etc.), die Euch als teoamorientiert und empfehlenswert bekannt sind?

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Ich bevorzuge es auch den Blockbeginn nicht in eine neue Zeile zu schreiben,
aber die Diskussion gibt es schon lange und es gab schon immer kleine
"Glaubenskriege" darüber. Wenn man in ein Projekt einsteigt, muß man sich
halt an die Standards halten, die dort vorgegeben sind. Man gewöhnt sich an
alles...

Gruß, Jan

[Ludger]

Hi,

Man gewöhnt sich an alles...

dann hast Du noch nicht alles gesehen!

(Was haeltst Du bspw. so von falsch eingeruecktem Code und Variablennamen fast ohne bedeutung und inkonsequent irgendwelchen regeln folgend? - Ach so, Du meinst, man gewoehnt sich an alles, was konsequent irgendeiner Regel folgt? Noeeh, glaube ich auch nicht.)

Gruss,
Ludger