"C" versus Pascal

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1242341)

Imho hat das (ungarische Notation) hat aber eher etwas mit schlechtem Codestil zu tun

Bei normalen Variablen ja, eindeutig.

Bei visuellen Komponenten sehe ich das anders. Niemand weiß die Namen aller Komponenten auf allen Formularen auswendig. Wenn die aber mit der ungarischen Notation bezeichnet sind, braucht man nur schreiben btn und hat alle Buttons. Die Liste dürfte bei den meisten Formularen komplett in die Quelltextvervollständigung passen oder zumindest kurz genug sein um diese sofort zu überblicken.

Deshalb spart man sich so den Blick auf das Formular, wenn man den Code dahinter schreibt. Und auch im Objektinspektor findet man die Komponenten so sehr schnell.

[blackfin]

Leicht OT, muss ich aber hier mal loswerden:
Ich persönlich finde Sprachen wie Python, die mir vorschreiben, wie ich Quellcode einzurücken und zu formatieren habe, viel viel schlimmer und nerviger als ungarische Notation, curly braces oder C im Allgemeinen. :)
Ohne einen angepassten Editor / IDE oder Autoformatter sind solche Sprachen der Graus (für mich...) und in meinen Augen die echten "Unfälle", auch wenn z.B. Python sonst eine geniale Sprache wäre.

Dagegen finde ich den (mentalen) Wechsel zwischen C-Notation und Pascal-Notation relativ leicht machbar.
Ich programmiere µCs eigentlich gerne mit C und könnte mir da auch irgendwie kein Pascal vorstellen, im Gegensatz zu den Desktop-Anwendungen zu den µC-Projekten.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1242346)

Bei visuellen Komponenten sehe ich das anders.

Komischerweise sehe ich das auch so wie Du. Weiß auch nicht warum.

[jaenicke]

Zitat:

Zitat von blackfin (Beitrag 1242449)

Ich persönlich finde Sprachen wie Python, die mir vorschreiben, wie ich Quellcode einzurücken und zu formatieren habe, viel viel schlimmer und nerviger als ungarische Notation, curly braces oder C im Allgemeinen. :)

Naja, also wenn ich so manche Delphi Quelltexte sehe, die so grauenvoll formatiert sind, dass man kaum etwas erkennen kann... da würde ich mir fast schon wünschen, dass da der Compiler aussteigt und nen Fehler ausspuckt...

[blackfin]

Zitat:

Naja, also wenn ich so manche Delphi Quelltexte sehe, die so grauenvoll formatiert sind, dass man kaum etwas erkennen kann... da würde ich mir fast schon wünschen, dass da der Compiler aussteigt und nen Fehler ausspuckt...

Generell hast du ja recht, aber ich verstehe eine Programmiersprache als ein Werkzeug.
Wenn mir ein Hobel vorschreiben würde, in welchem Winkel ich die Tischkante anzulegen habe, und zwar nur so, würde ich mir den nicht kaufen :)
Natürlich muss ein Werkzeug auch elementare Dinge verhindern, wie z.B. mit G0 ins Werkstück fahren :lol: (Generelle Syntax, Klammern, Trenner, Operatoren etc.), aber so etwas wie den persönlichen Geschmack der Formatierung meiner Meinung nach nicht, man kann es auch übertreiben.
Selbstredend gibt es bei keinem Zwang dann auch immer Leute, die dann Müll(code) produzieren, aber das nehme ich lieber in Kauf als aufgezwungenen Stil... :)

Um aber wieder auf das Thema zurückzukommen, habe ich an den Threadersteller gleich eine Frage:
Was erwartest du dir hier eigentlich genau für eine Diskussion?
Einfach nur ein "ich mag C lieber, weil..." oder ein haarkleines auseinandernehmen der einzelnen Features?
Versteh das nicht falsch, das soll kein Angriff sein, sondern eine ernstgemeinte Frage, da ich mir unter einer "C vs Pascal"-Diskussion ausser den üblichen Verdächtigen (bessere Lesbarkeit beim einen, kürzerer Code beim anderen etc.) nicht viel vorstellen kann :)

Wenns allein um die Erfahrung geht:
Ja, ich stimme dem allgemeinen Kanon in einer Sache mit ein: Von mir selbst geschriebener C-Code ist nach einiger Zeit der Nicht-Sichtung auf Anhieb immer etwas schwieriger zu lesen als verglecichbarer Pascal-Code, von dem her stimmt es meiner Meinung nach schon, dass C auf den ersten Blick immer etwas schwieriger zu verstehen ist. Wenn man dann aber wieder im Projekt "drin" ist, nehmen sich beide nicht viel.
Allerdings ist auch C / C++ von der "Unlesbarkeit" nicht sonderlich schlimm. Schlimmer finde ich da generell asynchronen Code mit Callback-Gespringe (egal welche Sprache :-))

[Furtbichler]

Bei C fällt mir ein Codeschnippsel ein, der zum Verschlüsseln des Kennwortes beim Unix-Login verwendet wird bzw. vor 30 Jahre wurde, als ich mich im Rahmen des Studiums damit beschäftigt habe. Dort wurden zwei Arrays deklariert:

Delphi-Quellcode:

var
  a1 : array [0..19] of Byte;
  a2 : array [0..19] of Byte;

Und dann wurde mit

Delphi-Quellcode:

for i:=0 to 39 do a1[i] := foobar[i]

in beide Arrays geschrieben, um anschließend u.a. mit

Delphi-Quellcode:

a2[x]

zu arbeiten. Das ist doch krank, oder?

Natürlich geht das ebensogut mit Delphi, aber das macht normalerweise keiner. Was ich damit sagen will (und schon vorher erwähnte): Ich glaube, die Sprache an sich ist schon ok. Sie erlaubt ne ganze Menge, aber das macht ein Hobel oder ein Hammer auch: Es sind eben Universalwerkzeuge. In den Händen eines guten Handwerkers sind sie sehr nützlich, aber wenn ein Cretin das in die Finger bekommt...

Ebenso bei 'C': Ich glaube, ein Programmierer wird bei der Sprache bleiben, die ihm am besten liegt: Typsicher + Prosa? Delphi! Modern, robust und elegant? C#! Kompakt-Tricks-Kryptisch-Kurz? C. Nicht die Sprache ist schräg, sondern die Programmierer, die es lustig finden, wenn außer ihnen niemand den Code versteht. Bei 'C' tummeln sich einfach mehr Nerds als bei Delphi. Dafür scheint mir Delphi eine Sprache für Individualisten und Einzelkämpfer zu sein. Wäre dem nicht so, wäre die virale Verbreitung moderner Softwarearchitekturen auch hier in der DP stärker zu beobachten.

Im C#-Team, mit dem ich derzeit arbeite, gibt es keine Diskussion über Formatierung (weil das imho zweitrangig ist) aber dafür hitzige Diskussionen über Bezeichner, Architektur, Clean Code, SoC, LoD, SRP, OCP usw. Wenn in einer Methode 10 Zeilen sind, wird schon refaktorisiert usw. Das kenne ich von Delphi-Teams so nicht. Wenn man sich die Diskussionen hier so anschaut, dann scheinen die 'Guten' gerade mal das Viewmodel-Konzept in Ansätzen umzusetzen, zumindest was die strikte Trennung von Funktion und UI betrifft. Einige andere Ansätze sind vereinzelt anzutreffen. Nicht, das das keiner so umsetzt, aber der Fokus in den Diskussionen hier ist ein anderer.

In einem 'C' Forum kann ich mir ketzerisch vorstellen, das man darüber diskutiert, wie schneller und kryptischer man eine Routine noch machen kann.

Na ja, Vorurteile eben ;-)

[Namenloser]

C-Programmierer spielen gerne mit dem Feuer. Ich muss gestehen, ich hatte mich vor diesem Semester nie wirklich mit C beschäftigt, aber mir wurde Angst und Bange, als ich erfuhr, wie alleine schon printf funktioniert...

Solange man alles richtig macht, eine sichere Sache. Aber ein kleiner Flüchtigkeitsfehler reicht, um den kompletten Stack zu zerschießen. Ggf. reicht es auch schon, das gleiche Programm nur für eine andere Architektur zu kompilieren...

Sowas würde in Pascal mit WriteLn oder in Delphi mit Format nie passieren.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1242485)

Nicht, das das keiner so umsetzt, aber der Fokus in den Diskussionen hier ist ein anderer.

Das liegt aber denke ich auch daran, dass solche Diskussionen in Entwicklungsteams eher intern passieren. So ist es zumindest bei uns.

Vereinzelt gibt in Foren wie diesem auch Fragen in der Richtung, aber die spiegeln nur selten die Diskussionen dazu wieder.

Zitat:

Zitat von Furtbichler (Beitrag 1242485)

Im C#-Team, mit dem ich derzeit arbeite, gibt es keine Diskussion über Formatierung

Die macht Visual Studio ja auch normalerweise automatisch.
In Delphi mache ich das eher unbewusst so, dass eine Quelltextformatierung hinterher in der Regel keine Änderungen mehr verursacht.

[Popov]

Kleinwenig OT: blackfin hat Python erwähnt. Hört sich interessant an, wollte es mir mal angucken. Auf der Seite von Phyton findet man anscheinend einen Compiler. Weiß einer ob es da eine IDE dafür gibt (kostenlos mal zum testen), oder programmiert man da mit dem Editor?

[DeddyH]

https://wiki.python.org/moin/Integra...ntEnvironments