ubuntuusers.de

agaida, die Probleme mit dem Code Deines Vorgängers haben schlicht und einfach nichts mit C zu tun. Wenn Dein Vorgänger schlechten C-Code geschrieben hat, dann hätte er auch in einer anderen Sprache schlechten Code geschrieben. Sauberer Code lässt sich nicht erzwingen, auch wenn sich immer wieder fehlgeleitete Programmiersprachen-Designer finden, die dies glauben und die Welt mit Discipline-&-Bondage-Sprachen "beglücken".

Das höre ich jetzt seit über 20 Jahren. Und seit 20 Jahren antworte ich darauf: In einer ordentlichen Sprache ist so was nicht möglich und wird auch nicht noch gefördert. Ich schreibe es jetzt noch einmal: Ja in C kann man strukturierte und gut lesbare Programme scheiben, allerdings wird einem das Gegenteil nicht verboten. Interessehalber kann sich der geneigte Leser mal perl anschauen, vor allem perl::critic und perl::tidy. Darauf wollte ich hinaus. Perl ist ein Paradebeispiel. Auch unter C gibt es Mechanismen, um Schwachsinn zu vermeiden, z.B. strict usw.

Über Perl wurde viel gelästert:

($/,$%,$.,$-)=(gmtime($^T+=86400))[3..6]while($/-12)/4|$--2||++$"&printf 1900+$.."-%02d-%02d\n",++$%,$/==8?8:$/-7

The only language that looks the same before and after RSA encryption. — Keith Bostic

Und deshalb bin ich einfach dafür, dass schlechter Code verhindert wird. Der Code meiner "Vorgänger" war nicht schlecht im üblichen Sinne, sondern einfach nur unwartbar und unzumutbar geschrieben. Es ging da z.B, um C-Objekte, die in Cobol eingebunden wurden und unter einem Unix-Derivat namens Sinix auf einer RM600 liefen. Gegen die Stabilität konnte man nichts sagen, das Zeug lief über 20 Jahre perfekt unter Sinix, und das weltweit. Hoch kam das Ganze erst bei der Migration auf Linux. Generelle Fehler dieser Art haben Kollegen und meine Wenigkeit auch in den Sourcen von Borland gefunden, z.B. in Basisklassen wie Stringverwaltung und TCP-Stacks. Wir haben danach nicht aus Jux und Tollerei gesucht, sondern weil unsere Projekte deswegen auf den Hammer liefen.

Ich weiss ja nicht, ob Du Dir den direkten wirtschaftlichen Schaden für die beteiligten Firmen vorstellen kannst, aber rechne einen normelen Tagessatz eines professionellen Programmierers mal 3 Leute und 3 Tage für einen Dummsinnsfehler.

@agaida: Wenn Du das so siehst, dann ist keine Sprache „ordentlich“. Auch in „Hochsprachen“ wie C#, Python, ja sogar OCaml kann man schlechten und unwartbaren Quelltext schreiben. Man kann „schlechten Quelltext“ nicht durch eine Sprache verbieten. Eine Programmiersprache ist eben immer nur höchstens so gut wie der Programmierer, der sie nutzt.

Deine persönliche Fehlergeschichte ist vielleicht interessant und auch etwas bedauerlich, hat aber trotzdem nichts mit C per se zu tun. Dir hätte dasselbe auch mit Java, XY oder dem von Dir bevorzugten Pascal passieren können.

Ach ja, was meinst Du mit „Mechanismen, um Schwachsinn zu vermeiden“? In C gibt es kein „strict“ ...

agaida schrieb:

Und deshalb bin ich einfach dafür, dass schlechter Code verhindert wird.

Dafür bin ich auch! Außerdem bin ich dafür, dass Weltfrieden einkehrt. Aber der Versuch, guten Code durch eine Programmiersprache zu erwirken ist ungefähr so aussichtsreich, wie den Weltfrieden per Dekret der Bundesregierung einführen zu wollen. Das Argument ist hier _nicht_, dass man auch in C sauber programmieren kann, sondern dass man in jeder anderen Sprache auch unsauber programmieren kann.

@lunar Sorry, da bin ich anderer Meinung, aber ich habe jahrelang für MS-Produkte geschrieben. Und der Schalter war Pflicht:

STRICT Preprocessor Variable The STRICT preprocessor variable is implemented in WINDOWS.H and described in WINDOWSX.TXT. When an application defines STRICT, the C compiler enforces the highest possible level of type checking, which enables the compiler to find as many errors as possible. It is much more productive to find errors at compile time than to find them later using a debugger.

While an application can use the new data types described above without defining STRICT, it must use the new types if STRICT is defined.

To enable STRICT type checking, an application must define the STRICT environment variable before including WINDOWS.H, as follows: #define STRICT #include windows.h

The STRICT environment variable and the new data types are compatible with Windows 3.0, C++, the Microsoft C Compiler's highest warning level (specified by the -W4 option switch), and ANSI C.

Ich kann mich natürlich auch irren.

@Hello World Ich finde Deinen Ansatz, QM in die Richtung SM zu ziehen, einfach nur kindisch. Aber wenn Du es als Ausruck von Freiheit betrachtest, Scheisse zu schreiben, dann mach das... Und den fehlgeleiteten Leuten im QM kannst Du Deine Meinung dann auch erklären. Ich glaub das wird eine recht kurze und einseitige Disskussion.

@agaida: Beruhige Dich und übertreibe nicht. Von Freiheit hat doch niemand gesprochen, schon gar nicht von der Freiheit, „… zu schreiben“. Bis jetzt wurde nur von der Tatsache gesprochen, dass man guten Quelltext nicht durch eine Sprache erzwingen kann. In Perl kann man auch trotz "use strict" wunderbar schlechten Quelltext schreiben.

Und nur im das nochmal klarzustellen: Es geht nicht darum, ob C oder C++ gute oder schlechte Sprachen sind, dass kann jeder halten, wie er will. Es geht nur darum, dass man mögliche Fehler, die ein Benutzer machen kann, einer Sprache nicht unmittelbar vorwerfen kann, sonst wäre keine Sprache brauchbar. Man kann allenfalls mit Recht kritisieren, dass C und C++ die Entwicklung von gutem Quelltext nicht gerade vereinfachen, und daher höhere Anforderungen an die Fähigkeiten eines Programmierers stellen. Aber das ist eigentlich nichts neues.

Was STRICT angeht, so irrst Du Dich tatsächlich: Compiler-Optionen haben nichts mit der Sprache C zu tun.

Lunar schrieb:

@agaida: Beruhige Dich und übertreibe nicht. Von Freiheit hat doch niemand gesprochen, schon gar nicht von der Freiheit, „… zu schreiben“. Bis jetzt wurde nur von der Tatsache gesprochen, dass man guten Quelltext nicht durch eine Sprache erzwingen kann. In Perl kann man auch trotz "use strict" wunderbar schlechten Quelltext schreiben.

Und nur im das nochmal klarzustellen: Es geht nicht darum, ob C oder C++ gute oder schlechte Sprachen sind, dass kann jeder halten, wie er will. Es geht nur darum, dass man mögliche Fehler, die ein Benutzer machen kann, einer Sprache nicht unmittelbar vorwerfen kann, sonst wäre keine Sprache brauchbar. Man kann allenfalls mit Recht kritisieren, dass C und C++ die Entwicklung von gutem Quelltext nicht gerade vereinfachen, und daher höhere Anforderungen an die Fähigkeiten eines Programmierers stellen. Aber das ist eigentlich nichts neues.

Was STRICT angeht, so irrst Du Dich tatsächlich: Compiler-Optionen haben nichts mit der Sprache C zu tun.

Diese Aussage hat mich halt aufgeregt: "auch wenn sich immer wieder fehlgeleitete Programmiersprachen-Designer finden, die dies glauben und die Welt mit Discipline-&-Bondage-Sprachen "beglücken"."

Meinen Irrtum sehe ich ein, da ja wie beschrieben der Präprozessor eingreift. Trotzdem finde ich es toll, wenn z.B. verwendete Variablen vor der Verwendung deklariert werden. Beim Rest stimme ich zu. Und wie Du schreibst: "höhere Anforderungen an die Fähigkeiten eines Programmierers". Deshalb fand und finde ich Pascal zum Lernen passend, dafür wurde die Sprache von Wirth ja auch entwickelt. Diesen höheren Anforderungen kann ein absoluter Programmier-Anfänger in C eigentlich nicht gerecht werden. Die Restriktionen, an denen sich viele C-Programmierer stören, beruhen halt auf dem Entwurf als Lehrsprache. Den wirtschaftlichen Erfolg der Sprache hat Wirth sicher so nicht vorausgesehen.

C in ausgebildeten und verantwortungsvollen Händen ist was Feines, IMHO sind reine Hochsprachen zum Lernen besser.

agaida schrieb:

Trotzdem finde ich es toll, wenn z.B. verwendete Variablen vor der Verwendung deklariert werden.

Also das darf weder unter C noch unter C++! In C (genau genommen C < ANSI-C99) darf man genau genommen nicht mal Variablen deklarieren/definieren, nachdem die erste Funktion oder Anweisung aufgerufen wurde (d.h. alle Variablen müssen direkt am Funktionsbeginn deklariert werden, lokale Variablen in Schleifen sind genausowenig möglich wie "eingeschobene" Variablendeklarationen). So etwas war eher eine Spezialität von Visual Basic (und vielen Skriptsprachen) und ist auch dort verpönt.

Ich meine, es kommt in erster Linie drauf an, was man will: Will man einfach nur eine Anwendung schreiben, kann eine "höhere" Programmiersprache von Vorteil sein, so lange besonderen Bedingungen (z.B. Hardware-Nähe, ...) erfüllt sein müssen. Will man aus Interesse Programmieren lernen (und sich auch etwas Hintergrundwissen aneignen oder später beruflich in diese Richtung gehen), gibt es fast nichts besseres als C/C++. Eine kompromissfähige Zwischenstufe wäre vielleicht noch Java.

Noch eine kleine Klarstellung:

agaida schrieb:

Lunar schrieb:

Was STRICT angeht, so irrst Du Dich tatsächlich: Compiler-Optionen haben nichts mit der Sprache C zu tun.

Meinen Irrtum sehe ich ein, da ja wie beschrieben der Präprozessor eingreift.

Es greift im eigentlichen Sinn weder der Präprozessor noch der Compiler ein. Die Windows.h bzw. dessen Bibliotheken besitzen Verifizierungsroutinen, die im Fehlerfall Compilerfehler auslösen. Die Präprozessorvariable sorgt nur dafür, dass diese Mechanismen überhaupt aktiviert werden. Das es sich um keinen ANSI/ISO-C-Standardsprachumfang handelt, dürfte ja klar sein.

FriedChicken schrieb:

agaida schrieb:

Trotzdem finde ich es toll, wenn z.B. verwendete Variablen vor der Verwendung deklariert werden.

Also das darf weder unter C noch unter C++! In C (genau genommen C < ANSI-C99) darf man genau genommen nicht mal Variablen deklarieren/definieren, nachdem die erste Funktion oder Anweisung aufgerufen wurde (d.h. alle Variablen müssen direkt am Funktionsbeginn deklariert werden, lokale Variablen in Schleifen sind genausowenig möglich wie "eingeschobene" Variablendeklarationen). So etwas war eher eine Spezialität von Visual Basic (und vielen Skriptsprachen) und ist auch dort verpönt.

Nur um das noch zu klären nicht das ein falscher Eindruck entsteht, in Schleifenblöcken und allgemein eingeschobenen Codeblöcken sind weitere Variablendeklarationen nach dem Funktionskopf durchaus erlaubt(Also auch Schleifen lokale Variablen), auch bei preC99 Code. "Eingeschobene" Variablendeklarationen sind weder verpönt noch schlechter Stil, die Deklaration sollte nahe am logischen Kontext stattfinden.

Danke für die Aufklärung, das macht mir C wieder sympatischer. Da hab ich wohl was in den ganz falschen Hals gekriegt. Kleine Anmerkung noch zum Thema Basic. Comet von Simens Nixdorf war z. B. in Business Basic geschrieben. Es muss also nicht immer VB sein, BB war ekelig genug.

alamar schrieb:

Nur um das noch zu klären nicht das ein falscher Eindruck entsteht, in Schleifenblöcken und allgemein eingeschobenen Codeblöcken sind weitere Variablendeklarationen nach dem Funktionskopf durchaus erlaubt(Also auch Schleifen lokale Variablen), auch bei preC99 Code.

Das ist Compiler-abhängig! GCC akzeptiert sowas, MS VC++ beispielsweise nicht (beides in Standardeinstellung). Ohne speziele Compileroption für C99 ignoriert VC++ (bei C-Quellcode) Definitionen, die nach der ersten Anweisung oder dem ersten Funktionsaufruf folgen, im Folgenden ist die Variable also unbekannt. Schier unglaublich, wie der sonst nicht gerade konsequente VC++-Compiler mit solcher Pingeligkeit (und nutzlosen Fehlermeldungen) einen Haufen Zeit zunichte machen kann...

"Eingeschobene" Variablendeklarationen sind weder verpönt noch schlechter Stil, die Deklaration sollte nahe am logischen Kontext stattfinden.

Da stimme ich dir zu. Wo das möglich und sinnvoll ist, sollte man das machen. Die Kritik bezog sich auf VB, wo es möglich ist, undeklarierte Variablen einzusetzten.

Es ist nur dann Compiler abhängig wenn ein Compiler das falsch implementiert, C89 zB. bezieht sich immer auf den Block Anfang und nicht explizit Funktionsanfang. (Gültig sind zb. unter anderem folgende Deklarationen)

int func() { 
  int a;
  for(a=0;a<5;a++) { 
    int b;
    b += a;
  }
  { 
    int c;
    c = a;
  }
  
  return 0;
}

Ja, das stimmt. Da war ich unpräzise.

Was aber leider tatsächlich nicht geht ist z.B.

1
2
3
4

for (int i, i<10; i++) {
  // "int i" liegt außerhalb des  Blocks; obwohl es zum Block gehört, wird das nicht akzeptiert
  // (im Gegensatz zu aktuellen Varablen im Funktionskopf!)
}

oder

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

int fkt() {
  int i = 99;
  int array[100];
  while (i--) array[i] = i;  // Array mit Standardwerten initialisieren
  int x = 1;   // wird (u.U.) ignoriert, da nach Anweisung!
  [...]
  x=5;         // Variable unbekannt, da Deklaration ignoriert!
  [...]
  return x;
}

obwohl es beispielsweise von GCC akzeptiert wird.

Im letzten Beispiel könnte ich es noch akzeptieren, da es zu unsauberen Code verleiten kann. Aber das erste Beispiel ist eine echte Einschränkung (und in C++ und neueren C-Versionen auch abgeschafft).

Mit den richtigen Optionen (-Wall -pedantic -std=c89) meckert da auch der gcc 😉 Problematisch ist Visual Studio was C Programmierung angeht dann übrigens noch weil C99 Support niemals auch nur angefangen wurde sondern nur C++.

also Fakt ist jedoch, soviel ich sagen kann ( hab leider nur Erfahrung mit Pascal, Delphi, PHP und TI-Basic), es handelt sich hier um Programmiersprachen. Wie auch in jeder Sprache gibst verschiedene Akzenzte die bestimmten Bevölkerungskreisen vorenthalten sind bzw verständlich erscheinen. so ist es doch auch beim programmieren. jeder entwickelt seinen eigenen style und fakt ist das ziel ist ein problem zu lösen. klar ist es schön wenn der eigene code auch vom nachbar verstanden wird aber es ist ja nicht pflicht. so hasse ich es variablen vor dem programm beginn zu deklarieren wie bei PASCAL oder Delphi. dies erscheint mir einfach nur unnütz.

außerdem brauch man sich nicht streiten welche sprache gut und schlecht ist. jede hat seinen sinn ( ok ausgenommen BRAINFUCK und Ummmph!) und die eine ist halt da hardwarenah zu programmieren, die andere eignet sich mal ebend für was mathematisches besser und die andere ist halt gut für keine ahnung was.

ich empfehle man guckt sich halt paar sprachen an, guckt nach code beispielen und analysiert den quelltext und denn guckt man nach vor und nachteilen der sprache und fängt denn an eine zu lernen. übung macht den meister. wenn man erst mal eine sprache kann ändern sich höchstens die sysntax und funktionsnamen.

was evtl für einige leute das größere problem ist, das problem was man lösen will solange zu zerlegen bis nur noch probleme da sind die man lösen kann und das is eigentlich die kunst.

ich hoffe ich konnt hier mal meine sempf dazu geben. mfg Logaff