Thread ungelöste Meldung durch use diagnostics (30 answers)
Opened by Auctioneer at 2013-01-03 21:49

topeg
 2013-01-06 13:08
#164679 #164679
User since
2006-07-10
2611 Artikel
BenutzerIn

user image
Meinetwegen du bist Praktiker, dich interessiert nicht, ob eine Variable definiert ist oder existiert, sie hat einfach da zu sein. Aus dem Grund habe ich mich aus der Diskussion weitgehend heraus gehalten.
Aber dann moser nicht herum wenn man dich darauf hinweist wie es besser ginge. Deine ganzen Probleme kommen nämlich durch deine Einstellung. "Egal wie es soll erst mal was machen. Egal was später kommt." Je weiter ein Programm fortschreitet um so wichtiger wird es dass man von Anfang an strukturiert programmiert hat.
Direkt an deinem Beispiel. Warum sind die Werte in %form nicht definiert obwohl sie verwendet werden? An der Stelle, an der %form erstellt wird ist es halt sinnvoll diese mit Werten vor zu belegen, die immer sinnvoll sind, oder wenigstens keinen Fehler erzeugen können. Aber das geht halt über das erste "Es soll einfach was machen" hinaus. Oder weiter gedacht. Warum ist %form kein Objekt bei dem man Werte abfragen kann?
Kleine Scripte sind schnell einfach mal geschrieben. Aber aus kleinen Scripten werden schnell riesige Programme, die dann mit den Problemen aus dem Scriptchen kämpfen. Es ist nicht sinnlos auf einen gute Schreibweise hinzuweisen. In 90% aller Fälle ist es völlig sinnlos aber die restlichen 10% machen einem richtig Arbeit, wenn man es nicht beachtet.

Auch was die Formatierung betrifft. Sicher ist es in der Übertragung schneller wenn man alle "unnötigen" Zeichen weg lässt. Aber für die Programmierung und das bearbeiten ist es sehr Praktisch. Aus dem Grund hat man Hilfsprogramme, die aus dem Arbeitscode den Finalen erzeugen (oder das ist direkt im Programm eingebaut), und das ganze in eine kompakte Form bringen.

Beim strukturierten Programmieren geht es darum dem Programmierer auf lange Sicht Arbeit zu ersparen. Es geht nicht darum irgend eine obskure Agenda zu verfolgen, oder anderen seine Denkweise aufzudrücken. Es geht darum zu helfen.

Du beklagst dich dass wir den Code Hinterfragen und wie sinnvoll er ist. Wir Fragen weil wir sehen das du Probleme damit hast die wir nicht hätten. Einige machen Vorschläge wie man das Problem grundsätzlich lösen kann ohne an den Symptomen herum zu doktorn. Du willst es nicht, OK, aber rechne damit das wir dich immer wieder darauf hinweisen werden.
Mal ehrlich wie viel Stunden hast du damit Verbracht alle Stellen aufzuspüren an denen "$form{...}" benutzt werden und diese zu prüfen. Es hätte sicherlich nicht länger gedauert das durch ein "$cgi->def_param(...)" zu ersetzen (ein gut definiertes suchen/ersetzen macht das auf einen Schlag). Mit einem passenden Objekt my $cgi = myCGI->new();. Auf Einmal hättest du all diese Probleme gelöst. Dann noch schnell ein:
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
12
package myCGI;
use parent CGI;

sub def_param
{
  my $self = shift;
  my $val = $self->SUPER::param( @_ );
  return $val if defined $val;
  return '';
}

1;
und du hättest nie wieder Probleme, du hast später auch noch mehr Möglichkeiten zu Prüfen was vom Client kommt. Ganz zentral ohne den rechtlichen Code verändern zu müssen.

Aber daran bist du ja nicht interessiert, das hast du von Anfang an klar gemacht. Du willst lieber über all if( defined $form{...} ) schreiben. Das ist eine Praktiker Lösung. Das Problem da lösen wo es auftaucht und sich nicht zu fragen warum es überhaupt zu einem Problem kommt. Sicher das ist einmal schnell und einfach, aber dann macht du es noch einmal und noch einmal und und und ...

Und das hat nichts damit zu tun das es ein schlechtes oder gutes Programm ist. Wir benutzen Programm die solche Flicken enthalten und benutzen sie gerne. Aber wir pflegen sie nicht wenn es nicht unbedingt nötig ist. Genauso fahre ich Autos von denen ich weiß das sie schlecht designend sind und ich fahre sie gerne. Das hält mich aber nicht davon ab mich über die Probleme zu ärgern. Z.B. habe ich mich darüber geärgert, das ich die komplette Front abschrauben musste um ein Fernlicht zu wechseln. Auch habe ich die Möglichkeit darüber nachzudenken wie man das besser lösen könnte.

Und es ist ganz klar, Erweiterbarkeit und Pflegeleichtigkeit kosten immer Rechenzeit. Objekte sind langsamer als hoch integrierte Logik. Zusätzliche Abfragen und Funktionen kosten ein paar Takte, Strukturierter Code verbraucht mehr Speicher usw. Die Frage ist einfach wie wichtig ist das? Als ich anfing zu Programmieren habe ich einiges in Assembler und manchmal auch direkt in Maschinencode geschrieben um es sehr schnell und kompakt zu machen. Und das war auch nötig. Wenn ein Prozessor die Rechenleistung einer heutigen Digitaluhr hat dann muss man auf so was achten. Aber den Code kann ich heute nicht mehr lesen. Ich weiß bei machen nicht mal mehr ansatzweise was da passieren soll. Mit der Zeit wurde der Code immer lesbarer, auch weil die nötige Rechenleistung zur Verfügung stand. Ich könnte heute sicher Programme schreiben die 1000 mal schneller sind das das was ich normalerweise schreibe, aber es lohnt sich nicht. Viel wichtiger ist es das ich in drei Jahren noch weiß was im Code passiert. Wenn es mal darauf ankommen sollte, so optimiere ich eine Variante und ich weiß das die Reguläre in zwei Jahren das selbe leisten kann.

View full thread ungelöste Meldung durch use diagnostics