Prüfen ob Eingabefeld leer ist !?!

[negaH]

Zitat:

orry, aber das stimmt so ja nun nicht. So eine Aussage ist imho sogar gefährlich, guter Stil hat überhaupt null mit Effizenz zu tun. Das ist völlig unabhängig davon wie leicht man sie erreichen kann.
Natürlich spricht nichts gegen Trim und einen Menge gegen StringReplace, aber das hat nichts mit Stil zu tun.

Doch meiner Meinung nach schon. Es ist Effizienz in der Programmierung und transportiert wird das über den Stil. Es gibt also durchaus Programmierstile die weit effizienter als andere sind.

Die Effizienz zeigt sich in diesem Beispiel "Trim contra StringReplace" im Wissen des Programieres was für die geforderte Problemlösung das beste Mittel zum Zweck darstellt. EIn guter Programmierstil wird also durchaus auf Grund von Effizienz eben Trim() benutzen statt StzringRepleace(). 1.) weil Trim() effizienter ist, 2.) weil Trim() ein annerkanntes PASCAL Ur-konstrukt ist, und 3.) ganz wichtig weil man viel effiztienter einen Source der Trim() benutzt verstehen kann. Programmierstil ist immer auch Effizienz, Effizienz durch Disziplin, Sauberkeit, Nachdenken, gezieltem Nachdenken bei der Programmierung (das machen wir ausschließlich im Kopf) was nichts anderes als effizient ist !
Alleine der Punkt das es Programmier gibt die Trim() und StringReplace() kennen und andere kennen nur StringReplace() ist ein Effizienz-Kriterium. Derjenige der beides kennt, also mehr Wissen besitzt wird einen anderen Stil haben und gleichzeitig auch effizienter arbeiten können. Oder der Punkt das partout ein Programmierer sich nicht von erfahrenen Leuten überzeugen lasen möchte, er also die gemachten Argumente nicht wertfrei unter die Lupe nimmt, zeigt wie in-effizient dieser Programmierer sein wird. Er ist nicht willens sein Wissen zu erweitern, eben nicht effizient !

Stil und Effizienz gehören für mich zusammen, der Stil ist ein Hilfmittel für Effizienz und Effizienz isz das Ziel eines Stiles.

[edit]
Sieht man es nämlich nicht so passiert folgendes:

Der Progreammierer meint er hätte einen guten Stil weil er alles OOP konform aufdrösselt und somit ein Problem mit 1000'enden Sourcezeilen lösst obwohl 10 Zeilen ausgereicht hätten. Augenscheinlich hat er einen sauberen Programmierstil aber er ist ineffizient !! Das fehlen von Effizienz in seinem Source/Stil macht aber den ansonsten guten Stil den er hat absout sinn und zwecklos, denn die Hauptaufgabe eines Programmes/Sources ist es nur und ausschließlich nur ein Problem zu lösen. Je weniger Sourcen dazu notwendig sind im Vergleich zu anderen Sourcen, desto effizienter wird das Program. Logisch, es ist meistens schneller, leichter zu verstehen und weniger Fehleranfällig und besser wartbar.

Stil ohne Effizienz ist also genauso hirnrissig wie ein Auto ohne Räder.

[/edit]

Gruß Hagen

[3_of_8]

Da kann man nichts mehr hinzufügen.

[jfheins]

Dann lass es



Auf Druck von Meflin ... ich konnte mich nicht wehren ...

[3_of_8]

Das war gedacht als ein "FULL ACK".

[Der_Unwissende]

Zitat von negaH:

Doch meiner Meinung nach schon. Es ist Effizienz in der Programmierung und transportiert wird das über den Stil. Es gibt also durchaus Programmierstile die weit effizienter als andere sind.

Stimmt zwar soweit, aber hier fehlt doch die allgemeinere Aussage, dass guter Stil immer = höhere Effizienz ist. Es gibt Stile (Existenquantor!) die ... Nicht alle guten Stile....

Zitat von negaH:

Die Effizienz zeigt sich in diesem Beispiel "Trim contra StringReplace" im Wissen des Programieres was für die geforderte Problemlösung das beste Mittel zum Zweck darstellt.

Sorry, aber das ist doch kein geschickt gewähltes Beispiel. Ich meine StringReplace macht etwas völlig anderes als Trim. Beides entspricht auch nur dem Aufruf einer Funktion. Ist es jetzt guter Stil die Funktion foo aufzurufen oder besser blubb? Das hat imho nichts mit Stil zu tun. Methoden (hier mal losgelöst von Objekten als allgemeines Wort für Funktion/Prozedur zu verstehen) die nicht vergleichbar sind (wie ebend StringReplace und Trim) haben keinen Einfluss auf den Codestil.

Vielleicht habe ich auch eine falsche Definition von gutem Stil (falls es eine einheitliche Definition gibt). Aber wenn ich alles OOP konform gestalte, dann habe ich ein Programm das OOP konform ist. Da wäre mir nicht klar dass alle OOP Programme einem Stil folgen. Ich denke mal ich muss mit dir da nicht über den Unterschied sprechen, der ist dir auch klar.
Guten Stil macht für mich die Lesbarkeit des Codes (im sehr Allgemeinen) an. Gute Lesbarkeit führt zu weniger Fehlern, robustem Code der leicht(er) wartbar ist.
Dazu ist ein guter Stil unabdingbar. Ich würde sagen guten Stil erkennt man unter anderem daran dass:

• Ein Stil existiert (einheitlich über das ganze Projekt!)
• Der Code überhaupt verstanden werden kann
• Hierzu insbesondere sinnvolle Namen verwendet werden
• Sauber eingerückt wird
• Eine Anweisung pro Zeile verwendet wird
• Parameter sauber qualifiziert werden (insbesondere auch Konstanten)
• Entscheidungen erklärt werden
• vieles vieles mehr

Es sind nur ein paar Punkte dessen, was man noch alles dazu zählen kann. Ob dabei dann 1000 LOC rauskommen oder 10 hat doch nichts mit dem Stil zu tun. Ich kann doch auch einen 1000 Zeilen Code auf 10 Zeilen bringen, dann steht einfach mehr in jeder Zeile, das ändert also nur die Lesbarkeit des Codes (und damit den Stil), die Effizienz verändert es gar nicht (ist ja der gleiche Code).

Zitat von negaH:

EIn guter Programmierstil wird also durchaus auf Grund von Effizienz eben Trim() benutzen statt StzringRepleace(). 1.) weil Trim() effizienter ist, 2.) weil Trim() ein annerkanntes PASCAL Ur-konstrukt ist, und 3.) ganz wichtig weil man viel effiztienter einen Source der Trim() benutzt verstehen kann.

Nun ja, ich benutze Trim eigentlich eher, weil ich alle Steuerzeichen am Anfang und Ende eines String entfernen möchte, aus keinem anderen Grund. Das ich nicht StringReplace verwende liegt daran, dass StringReplace dies gar nicht direkt leistet. Das Trim dabei sehr gut lesbar ist, ist ein schöner Nebeneffekt, aber mein Hauptgrund ist allein die Funktionalität (mir ist keine andere Funktion bekannt die gleiches leistet).
Würde ich trim nicht kennen, würde ich wohl eine Methode schreiben die eben diese Aufgabe erfüllt, klar ist der Code dann schon lesbarer, aber durch den Overhead einer weiteren Methode (mehr Zeilen, evtl. eine andere Unit und dann natürlich auch der Aufruf...) wird der Code nicht effizienter, nur besser im Stil.

Zitat von negaH:

Alleine der Punkt das es Programmier gibt die Trim() und StringReplace() kennen und andere kennen nur StringReplace() ist ein Effizienz-Kriterium. Derjenige der beides kennt, also mehr Wissen besitzt wird einen anderen Stil haben und gleichzeitig auch effizienter arbeiten können. Oder der Punkt das partout ein Programmierer sich nicht von erfahrenen Leuten überzeugen lasen möchte, er also die gemachten Argumente nicht wertfrei unter die Lupe nimmt, zeigt wie in-effizient dieser Programmierer sein wird. Er ist nicht willens sein Wissen zu erweitern, eben nicht effizient !

Wow, dass ist doch eine ganz andere Diskussion. Ist nicht so dass ich die nicht gerne führen würde, aber wir sind schon Offtopic genug.
Ich finde du würfelst hier (leider) sehr viel durcheinander. Das es Effiziente Programmierer gibt ist schon so ein Satz, der mir so gar nicht gefällt. Das klingt so, als ob man trivial die Effizienz eines Menschen bestimmen könnte. Gerade du weißt aber sicherlich auch, dass dies nicht so ohne weiteres möglich ist. Es gibt kreative Prozesse die da einfliessen. Über welchen Zeitraum misst man also die Leistung um die Effizienz einschätzen zu können? Und bist du bei all deinen Arbeiten gleich Effizient oder mitteln wir da einfach? (mich würde dann deine Standardabweichung interessieren )
Also ganz ehrlich, Leute die sich nicht helfen lassen wollen, da geb ich dir völlig recht, die nutzen keinem etwas. Natürlich werden die es nie weit bringen und schaden letztlich nur sich selbst.
Leute die ein gewissen Wissensstand noch nicht haben, können diesen aber noch erreichen. Natürlich gibt es immer Dinge die man noch nicht kennt. Niemand wird je alle Bibliotheken und Komponenten und ihre Möglichkeiten im Ganzen kennen. Und dann kommen auch ständig neue hinzu. Wichtig ist also, dass man nicht einzelne auswendig lernt, sondern erkennt wie man an fehlendes Wissen (bei Bedarf) ran kommt. Leute die das nicht schaffen werden sicherlich nie all zu gute Arbeiten leisten können. Aber es sind Menschen, sie haben also die Fähigkeiten dies zu erkennen und etwas zu ändern. Das sie nicht effizient sind klingt für mich eher danach, dass man sich einfach einen besseres anderes Modell nimmt.

Wie gesagt, guter Codestil (da stimme ich völlig mit dir überein) ist wichtig und hat natürlich auch etwas mit Disziplin zu tun. Jeder sollte aus sehr vielen Gründen auf eben diesen Stil achten und es ist nur von Vorteil. Wissen noch nicht zu haben ist keine Schande, nichts mehr lernen zu wollen schon!
Das sind alles Punkte in denen wir (soweit ich es sehe) völlig übereinstimmen. Aber wie im oberen Beispiel gezeigt, ich kann den gleichen Code in einem beliebigen Stil aufschreiben, es ändert nichts an seiner Effizienz.

Gruß Der Unwissende

[negaH]

Gut zu sehen das es unterschiedliche Meinungen gibt. Meistens basieren diese Unterschiede aber einfach nur darauf das man zu einem Wort eine andere inhaltliche Bedeutung gibt.

Stil ist für mich alles das was der Programmierer wie denkt und dann in einen Source umsetzt. Der Stil beginnt also schon bei der Denkweise eines Programmieres. Ist er faul so geht er methodisch und systematisch in seinem Debken vor. Ist er exakt, so versucht er erstmal das zu lösende Problem zu durchdenken bis er es verstanden hat. Ist er diszipliniert so wird er seinen Source stets gleich formatieren. Das Primäre ist der Denkprozess und wie dieser abläuft ist der Stil ! Stil ist also für mich der Charakter eines Sources. Nicht nur ob er gut lesbar ist sondern ob er technisch gut umgesetzt wurde, dh. also die richtigen Mittel gewählt wurden um ein Problem möglichst einfach und doch voll funktionsfähig zu lösen. Ergo: auch ein OOP Source mit vielen 1000'enden Zeilen an Source kann von der Form her ein guten Programmierstil folgen. Allerdings kann das durchaus nur 25% der Miete sein denn wenn der Programmierer das gleiche Problem mit einem identisch guten Stil und Source lösen konnte, aber mit 10 Zeilen auskommen konnte, dann ist das ein wirklich guter Stil. Denn er hat die richtigen Mittel für das Problem angewendet und konnte so mit viel höherer Effizienz das Problem lösen. Um dies zu können benötigt er das Wissen darum auf welchen unterschiedlichen Wegen er ein Problem lösen kann, eben ob er OOP, prozedurale oder formale Programmierungen benutzt. Das ist eine Basis im Programmierprozess und wird sich individuell in einem bestimmten Stil ausdrücken. Ergo: ich sehe den Programmierstil eines Menschens als seine Art und Weise ein Problem zu lösen, als seinen Wissenstands, als seinen Charakter, an. Wahrscheinlich vile weit gefasster als du das machst

Guter Stil heist also das man exakt die Mittel zur Lösung eines Problems anwendet die minimal exakt das erledigen was man benötigt, nicht mehr und auch nicht weniger.

Und die gleiche Definition kannst du 1 zu 1 übertragen auf den Schreibstil deines Lieblings Buch Autors. Für mich ist diese Möglichkeit sehr wichtig, bedeutet es doch für mich das ich das Wort Stil und dessen für mich richtige wörtliche Bedeutung, universell auf verschiedene Bereiche anwenden kann. Das Wort Stil ergibt so einen reproduzierbaren und übertragbaren Sinn für mich und steht nun nicht mehr alleine als Programmier-stil der nur das gute Aussehen eines Sources beschreibt sondern eben das was der Source inhaltlich rüberbringen soll. Stil besteht also aus Form und Inhalt und Zielsetzung.

Trim() ist in unserem Beispiel die bessere Lösung, aus vielen Gründen heraus. StringReplace() ist ebenfalls eine korrekt funktionierende Lösung allerdings für diese Problematik ein eher falsches Mittel der Wahl. Da beide Lösungen funktional identische Lösungen sind, kann man sie sehr wohl auch miteinander vergleichen.


Gruß Hagen

[GuenterS]

Man sollte aber auch an die Wiederverwendbarkeit bzw. Erweiterbarkeit des 10 Zeilen Source Codes und des 1000 Zeilen OOP Codes denken.

Man kann ein gestelltes Problem lösen, in 10 Minuten mit wenigen Zeilen von Code, der aber sehr viele fixe, reincodierte Annahmen trifft, die vielleicht nur bei einem einzigen Kunden nämlich dem wofür man die Erweiterung programmiert vorliegen. Kommt dann ein weitere Kunde dazu oder ändern sich ein paar der fix eincodierten Dinge, ist wieder Programmierung notwendig, die man sich eigentlich hätte ersparen können, wenn man es gleich richtig bzw. besser gelöst hätte. Qualität eines Quellcodes liegt meiner Meinung nach nicht in der kürze des Quellcodes.
unabhängig davon ob dieser nun Objekt Orientiert ist oder nicht.

[negaH]

Hi GuenterS,

dem kann ich nur zustimmen, allerdings sehe ich da auch kein Problem zu meinen obigen Aussagen. Denn es ist ebenfalls eine Frage der Zielsetzung wenn man verscheidene Kunden mit unterschiedlichen Bedürfnissen befriedigen möchte und das mit einem universelleren Source. Andererseits das negativ Bespiel bei dem der Programmierer auf Grund dessen das er alles so universell machen möchte und niemals termingerecht zu Potte kommt. Auch hier wieder die Frage des Programmierstils und der Erfahrung abschätzen zu können was der beste Mittelweg zum Ziel ist.

So jetzt habe ich den Thread aber so richtig OT gemüllt, sorry.

Gruß Hagen

[GuenterS]

Ich hab das auch nicht als Widerspruch gemeint, sondern eher als eine Art Zusatz. Ich sehe oft das Problem, aus irgendwelchen Gründen geht der Quellcode nicht und komme dann drauf, dass das jemand anderes der schon lange nicht mehr in der Firma ist, fix eincodiert hat. Manchmal sieht man einfach es war Zeitmangel, manchmal auch Unkenntnis, Faulheit oder Vergesslichkeit. Manche stellen sind kommentiert, manche gar nicht, manchmal wird auch einfach nur der Datensatz einer Tabelle mit der höchsten ID genommen, weil man damals davon ausgegangen ist es gibt in der Tabelle eh nur einen. Nachdem sich das bei einem Kunden geändert hat, hat es natürlich nicht mehr so funktioniert wie man es gedacht hat, leider waren auch nur ein paar Zahlen anders, so dass man selbst nicht so wirklich leicht drauf kommt.


sorry fürs so viele ot

[sir-archimedes]

Hallo,

ich möchte mich auch noch kurz zu diesem Thema äußern. Meiner Ansicht nach, sollte man mit dem Ausdruck "effiziente Programmierer" aufpassen. Denn was soll effizient sein? Der Programmierer bei seiner Arbeitsweise? Soll der Code, der dabei herauskommt, besonders effizient sein? Soll der Code, der nachher herauskommt, besonders wartbar sein?

Ich meine, dass man stark differenzieren sollte. Was möchte man in der Regel? Man möchte in möglichst kurzer Zeit die Lösung für ein Problem entwickeln, wobei die Lösung möglichst effizient ist und somit die Rechenzeit so stark es geht verkürzt. Desweiteren soll die Lösung wartbar und lesbar sein. Sie sollte meistens erweiterbar sein, robust gegenüber fehlerhaften Daten/Fehleingaben. Da kommt sicherlich einiges hinzu.

Leider kann man keinen eindeutig richtigen Weg angeben - es gibt viele Wege, wie man Software entwerfen und entwickeln kann. Es hängt hier auch sehr viel vom Projekt im Einzelnen ab: Wenn ich an einer 3D-Engine entwickele, dann kommt es an vielen Stellen stark auf Performance an - da sind die Algorithmen ausschlaggebend und es fließt viel Zeit in die Entwicklung eines Algorithmus, der etwas noch schneller kann, als ein anderer Algorithmus. Es kann passieren, dass man nicht auf Anhieb versteht, wieso der Algorithmus so schnell ist und funktioniert - dafür gibt es dann Kommentare und Dokumentation. Trotzdem sollte der Programmierer versuchen, das ganze übersichtlich, gut eingerückt und mit aussagekräftigen Variablen- und Methodennamen aufzuschreiben.

In anderen Projekten kommt es nicht so sehr auf die Performance, sondern viel mehr auf Erweiterbarkeit, Robustheit und Fehlerfreiheit an. Hier ist es effizienter, wenn man einige Codezeilen mehr schreibt, wenn dadurch ein Fehlerfall mehr abgefangen werden kann, oder der Code nachher lesbarer ist. Dann kann man den Code einfacher erweitern, findet Fehler schneller, etc.

Somit sind für mich effizient Programmieren und guter Stil zwei unterschiedliche Paar Schuhe. Man darf zu Gunsten von effizienter Programmierweise seinen guten Stil nicht vernachlässigen. Guter Stil hat meines Erachtens nichts damit zu tun, möglichst schnell zum Ziel zu kommen, sondern sich an die Vorgaben, die für das aktuelle Projekt gelten, vollständig zu halten und systematisch seine Aufgaben zu entwickeln. Somit wünschen wir uns alle Programmierer, die effizient, aufs Wesentliche konzentriert, unter Einhaltung des guten Stils, arbeiten und somit in kurzer Zeit ein ausgereiftes, robustes Programm entwickeln.

Gruß,
Dominik