✔ Programme in C optisch gestalten

[Marschal]

@Crash Kid:
Eine Komplexität eines Programms kann man, meiner Meinung nach, nicht an Hand der Zeilenanzahl mesen.

Denn wenn man im Bereich 3D-2D und der liniaren Algebra etwas etnwickelt hat, würdest man wissen, dass das Entwickeln von zwei Zeilen code, die ein liniares Verhältniss beispielsweise errechnen, Stunden über einem Blatt, einen CAS-System und einer Formelsammlung kosten.

Ich spreche aus Erfahrung

Und genau aus diesem Grunde mag ich lieber eine schöne Benutzerfreundliche Entwicklungsumgebung, die einem die Fragen nach Optik und Gestalltung einer GUI erleichter und man sich lieber auf Alghorytmen konzentrieren kann.

 

[saftmeister]

Und genau aus diesem Grunde mag ich lieber eine schöne Benutzerfreundliche Entwicklungsumgebung, die einem die Fragen nach Optik und Gestalltung einer GUI erleichter und man sich lieber auf Alghorytmen konzentrieren kann.

Zu keinem anderen Sinn und Zweck gibt es Frameworks. Denn die Devise lautet: Don't reinvent the wheel! ;-)

Aber keine Angst, wenn man zum 100sten Mal die gleiche Aufgabe macht, fängt man automatisch an, nach Abkürzungen zu suchen. Bei der Implementierung eines spezifischen Algo ist das meistens nicht möglich.

 

[Marschal]

Und auch genau deshalb mag ich das .NET Framework sieht schick aus, und hat von Haus aus ne Menge Funktionen, abgesehen davon ist managed code sehr handsam und untereinander sehr kompatibel
Deswegen C# .NETinklusive Garbagecollector Dh, ich kann mit Objekten und Variablen um micht schmeisen, ohne mir Gedanken über einen Stackoverflow

 

[Jo890]

Was auch gut ist, ist die WinAPI. Damit kannst du alle Buttons, Eingabezeilen usw. machen.
Es ist dann alles im Windows-Design, falls du dieses Betriebssystem verwendest.
Auf dieser Website (http://www.win-api.de) war mal alles super beschrieben, aber die Tutorials gibt es leider nicht mehr.
Wenn du willst kann ich sie dir dann per Mail schicken, ich hab sie alle abgespeichert.

Crash Kid

Würde mich freuen, wenn du das machen würdest. Danke Email: info@wernergut.com

 

[Frezl]

Aber genau des macht einen Programmierer aus. Man muss alles als "Textform" schreiben.
Dieses "Button rein ziehen, größe verändern" usw. wie bei Visual Studio ist ja langweilig.
Wenn dann schon gescheit...

Du gehörst also auch zu denen, die einen Draht mit den Zähnen durchknabbern, weil ne Kneifzange lame ist?

Solche Entwicklerwerkzeuge wurden erfunden, um die Entwicklung zu vereinfachen und zu beschleunigen. Warum sollte man sie dann nicht verwenden? Spätestens wenn man aus dem Anfängerstadium raus ist, macht es überhaupt keinen Sinn mehr, GUIs von Hand zu coden. Es sei denn, man braucht ein extrem speicherschonendes Programm und muss deshalb auf jede Überflüssige Zeile verzichten...

Grüße, Frezl

 

[Akeshihiro]

Ich selber komme aus der Java-Ecke, aber ich denke, das macht hier kein Unterschied. Ich persönlich befinde mich auch bei der GUI-Entwicklung viel lieber in dem Quellcode als in irgendwelchen Drag&Drop-Klickibunti-Gui-Editoren. Sicher sie nehmen einem viel Arbeit ab, warum auch nicht, mal eben schnell was hierhin verschieben und das passt da nicht, also mal wo andershin verschieben etc. Ich geb zu, dass das sehr angenehm ist. Mir war es allerdings am Anfang wichtig, zu wissen wie welche Komponenten arbeiten anstatt zu wissen, wie man die Maus bewegt. In einem selbst geschriebenen Code findet man die persönliche Struktur, den Charakter des Programmierers wieder und das macht z.B. beim Debuggen viel aus, weil man nicht suchen muss, was man nicht kennt, weil der Editor was generiert hat, das man nicht mitbekommen hat. Außerdem ist es meines Erachtens nach wichtiger zu wissen, was im Hintergrund passiert als möglichst schnell was zusammen zu klickern. Wenn man mehr Erfahrung hat und sich einige solcher GUI-Editoren angeschaut hat, um deren Logik zu verstehen, dann kann man von mir aus sie auch nutzen, werd ich sicherlich auch im Berufsleben machen, aber aus Zeitgründen, denn es geht nunmal deutlisch schneller. Aber was oft fehlt, ist das Wissen über den Hintergrund der Geschichte, weshalb oft Tage für die Fehlersuche draufgehn und genau deswegen bin ich eben der Meinung, man sollte erstmal wissen, was im Detail passiert, bevor man sich Frameworks bedient.

Und um mal darauf zurückzukommen:

Und genau aus diesem Grunde mag ich lieber eine schöne Benutzerfreundliche Entwicklungsumgebung, die einem die Fragen nach Optik und Gestalltung einer GUI erleichter und man sich lieber auf Alghorytmen konzentrieren kann.

Das würde ich so nicht unterschreiben. Nimmt dir so eine Entwicklungsumgebung wirklich die Fragen nach Optik und Geschstaltung? Ich glaube nicht, denn das musst du immer noch selber machen. Sie ersparrt dir lediglich das Tippen diverser Zeilen, weil sie generiert werden, aber sicherlich nicht den Aufbau, denn den musst du schon selber machen. Und auch wenn man in so einem GUI-Editor bequem alles nachträglich abändern kann, ich habe gelernt zuerst mögliche GUIs zu skizzieren und dann erst wirklich eine zu entwickeln, nicht zuletzt um sich das Geändere zu ersparen, sondern auch möglichen generierten Müll und paar andere unschöne Sachen zu ersparen.

 

[Frezl]

@ Akeshihiro:

Mja, in der Java-Ecke hüte ich mich auch vor GUI-Editoren. Ich habs schon mit Eclipse und Netbeans versucht und in keinem habe ich gescheite GUIs zustande gebracht. Immer hüpft irgendwas irgendwo durch die Gegend, ändert seine Größe oder den Abstand zu anderen Elementen, wenn ich ein neues einfüge. Außerdem produzieren die immer unmengen von Code, den ich nicht versteh und nicht editieren darf. Insofern kann ich dich also gut verstehen.

In C++ und Pascal (Delphi) hab ich aber schon mit guten Editoren gearbeitet, die genau das umgesetzt haben, was ich auf dem Bildschirm gebastelt habe. Und der Quellcode war danach auch hübsch übersichtlich und verständlich. Da würde ich also sicher nicht von Hand coden wollen...

Grüße, Frezl

 

[saftmeister]

Gerade in Java möchte ich keine GUI zusammen frickeln. Das ist extrem aufwendig. Es gibt doch nichts eleganteres, als sich mit Netbeans die GUI und mit eclipse den Code dahinter (mit Hilfe von Services ist das kein Problem) zu bauen. Das kann prima im Team erledigt werden.

Eine GUI, die von Hand zusammen gezimmer wurde, ist alles andere, nur nich wieder verwendbar. Wenn man die GUI so zusammen baut, das keine Logik da rein kommt, lediglich Schnittstellen-Calls auf Services (Delegate->Facade), dann kann man prima sowohl GUI also auch Service umbauen. Ohne gleich 200k Zeilen neu zuimplementieren. Oder man tauscht die GUI gleich komplett aus.

Schönes Beispiel:

JBoss für die Geschäftslogik => AMF => Flash-Frontend für die GUI

Funktioniert prima und könnte jederzeit ausgetauscht werden.

 

[Crash Kid]

Also, um mich auch mal wieder zu Wort zu melden...
Akeshihiro bringt meine Meinung voll auf den Punkt! Ich finde auch das eben die selbst geschriebene Benutzeroberfläche besser zu versteh ist, vor allem am Anfang.
Sicher wenn man zum 100.00sten mal des zusammen schreiben muss, dass man dann auf diese Frameworks zurückgreift. Darum handhabe ich es so, dass ich alle Programme
ähnlich aufziehe. Hab meine Vorlage abgespeichert (das Grundgerüst ist ja immer gleich) und verändere diese dann wie ich sie eben brauche.
Ich stell es mir unheimlich schwer vor, einen Computergenerierten Code zu studieren (vor allem bei komplexen Designs) wenn da mal ein kleiner Fehler drin ist.
Und eben auch, dass der Computer den generierten Code nicht so aufbaut wie ich es mache und für verständlich sehe. Ich muss ja damit klar kommen, daher programmiere ich die Oberfläche auch immer selber.

Fazit: Jeder programmiert so wie er es für richtig hält, der eine mit der Hilfe der andere komplett ohne. Jeder wie er am besten damit zurecht kommt.

 

[saftmeister]

Also, um mich auch mal wieder zu Wort zu melden...
Akeshihiro bringt meine Meinung voll auf den Punkt! Ich finde auch das eben die selbst geschriebene Benutzeroberfläche besser zu versteh ist, vor allem am Anfang.

Geschenkt...

Sicher wenn man zum 100.00sten mal des zusammen schreiben muss, dass man dann auf diese Frameworks zurückgreift. Darum handhabe ich es so, dass ich alle Programme
ähnlich aufziehe. Hab meine Vorlage abgespeichert (das Grundgerüst ist ja immer gleich) und verändere diese dann wie ich sie eben brauche.

Dann hast du das Prinzip eines Frameworks bereits angewendet. Denn wenn man Framework mal eindeutscht: "Rahmen-Werk". Es gibt also einen Rahmen, den man an seine derzeitigen Bedürfnisse anpasst. Demzufolge hast du ein Rahmen-Werk erstellt, und greifst also immer auf die Basis zu, erweiterst sie aber um die projekt-spezifischen Bedürfnisse.

Allein die Tatsache, dass das Framework aus deiner eigenen Feder stammt, ist dann ein Diskussionspunkt. Schließlich kannst du deinen Code zwar kennen, aber du bist vor eigenem Code viel betriebsblinder als vor fremden. Daher halte ich Frameworks, die von Community-Projekten (z.B. Tapestry für Java) kommen, für robuster und fehlerfreier.

Ich stell es mir unheimlich schwer vor, einen Computergenerierten Code zu studieren (vor allem bei komplexen Designs) wenn da mal ein kleiner Fehler drin ist.

Du stellst es dir also vor? Heißt das, du hast damit noch gar keine Erfahrungen?

Und eben auch, dass der Computer den generierten Code nicht so aufbaut wie ich es mache und für verständlich sehe. Ich muss ja damit klar kommen, daher programmiere ich die Oberfläche auch immer selber.

Das ist ein Punkt, über den man nicht diskutieren kann, da ein Totschlagsargument (du willst dich nicht überzeugen lassen).

Fazit: Jeder programmiert so wie er es für richtig hält, der eine mit der Hilfe der andere komplett ohne. Jeder wie er am besten damit zurecht kommt.

Wie oben, nur das ich eine andere Meinung dazu habe: Ein Projekt besteht i.d.R. aus mehreren Personen. Einem Analysten, der die funktionelle Beschreibung liefert. Sprich, wie soll das Programm aussehen, was sollen für Funktionen implementiert werden, wie soll die Benutzerschnittstelle aussehen, etc. Einem Architekten, der sich darum Gedanken macht, welche Programmier-Standards angewendet werden sollen, der die Programm-Architektur vorgibt. Und dem Entwickler, der zwar seine eigene Stilblüte einbringt, aber grundsätzlich nach den Vorgaben des Analysten und Archtikten implementiert. Deine Sätze zeigen mir eines: Du hast noch nicht in einem größeren Team gearbeitet, wo du Vorgaben bekommst, wie etwas zu implementieren ist. Vielleicht kommt das ja noch ....