Was nervt euch so, während der Programmierung oder so allgemein

[himitsu]

Zitat von mkinzler:

Das ist ja eher ein Problem dass php case-sensitive ist

das ist nochwas ... es ist nicht alles CaseSensitive ... einiges z.B. Methodennamen sind es anscheinend nicht
und da mein lokales MySQL hier unter Windows läuft, sind es auch die Tabellennamen nicht.

Aber laß einfach mal einen Buchstaben weg oder vertausch was.

Ich hatte z.B. bis so um 10 hier an zwei Stellen "$Titel" stehen, anstatt $Title und das viel erst auf, als ich zufällig das "Titel" kopiert hatte, für ein DB-Feld nutzen wolle und sich die DB beschwerte da existiere was nicht.


@wicht:
Da hast du doch eine Marktlücke entdeckt.
Hardware-Simmulations-Software-Programmierer ... ich seh neue Jobs am Horizont

@Nersgatt:
Ist das nicht immer so?
Irgendwo wartet ein gemeiner Fehler, um dann im "richtigen" Moment hervorzuspringen.

[Nersgatt]

Zitat von himitsu:

@wicht:
Da hast du doch eine Marktlücke entdeckt.
Hardware-Simmulations-Software-Programmierer ... ich seh neue Jobs am Horizont

Da hab ich in meiner Software, die relativ starken Gebrauch von Barcodescannern macht, einen Modus eingebaut, dass ich "per Programm" scannen kann. Also ohne den Scanner selbst. Unser Hotlinedamen haben mich dafür fast geknutscht. So können Sie jetzt auch per Fernwartung beim Kunden Dinge ausprobieren. Früher mussten sie immer am Telefon dem Kunden sagen "so, jetzt halten sie mal den Scanner an den Barcode".

Zitat:

@Nersgatt:
Ist das nicht immer so?
Irgendwo wartet ein gemeiner Fehler, um dann im "richtigen" Moment hervorzuspringen.

Und zwar immer 5 Minuten vor dem 3-wöchigen Urlaub!

[blackfin]

Zitat:

...hat man die Hardware meistens leider erst, wenn man beim Kunden auf der Baustelle ist....

Das kenn ich auch nur zu gut. Oder man hat eine "Dummy-Box", die nur die Steuerungs-Platinen enthält, aber die sonstigen Hardware-Teile und Sensoren nicht, aber man soll dann die Heizkurve von irgendnem Heizelement anpassen, das man nie zu Gesicht bekommen hat.

Was mich auch noch EXTREM nervt:
Man wartet ewig darauf, bis der Kunde sich intern über irgendwelche Implementationen geeinigt hat, dafür vergehen dann mehrere Wochen oder Monate, in denen man keine Zeile Code schreiben kann, weil der nicht aus den Puschen kommt.
Sobald der Kunde aber weiss, was er will, soll man es dann innerhalb von wenigen Tagen fertig haben, da es ja nun so schnell wie möglich ausgeliefert werden soll! Ab diesem zeitpunkt nervt der Kunde täglich, wie weit man denn schon ist und dass ihnen nun die Deadline im Nacken sitzt.
Meiner Meinung nach ist so eine Vorgehensweise die Bugwerkstätte Nummer 1

[divBy0]

Oh ja, das ist auch ganz toll. Habe gerade heute wieder so eine Aktion gehabt. Fernwartung gibt es nicht, also die Exe per Mail an die IT und die kopieren dann entsprechend um.

[rollstuhlfahrer]

was mich bei einem Projekt genervt hat, ist, dass Delphi/Pascal zwar die Fähigkeit von goto bietet, man diese aber nicht nutzen soll. da kommen dann Strukturen wie folgende raus:

Delphi-Quellcode:

  // Anti-GOTO-Struktur
  if ScanRows then
  begin
    if ScanCols then
    begin
      if ScanFields then
      begin
        Result := true;
      end
      else
      begin
        Result := false;
      end;
    end
    else
    begin
      Result := false;
    end;
  end
  else
  begin
    Result := false;
  end;

Mit einem einfachen goto wäre das viel einfacher gegangen. Und auch viel leserlicher und schöner:

Delphi-Quellcode:

  
procedure MitGoto();
// ...
begin
  //GOTO-Struktur
  if not ScanRows then
  begin
    Result := false;
    goto ende;
  end;

  if not ScanCols then
  begin
    Result := false;
    goto ende;
  end;

  if ScanFields then
  begin
    Result := false;
    goto ende;
  end;

  :ende
end;

Bernhard

PS: Nach mehrfachem Umbau sieht der Ablauf völlig anders aus und man braucht auch kein Goto mehr.

[himitsu]

Result := ScanRows and ScanCols and ScanFields; .
was aber nicht bedeutet, daß ich was gegen GOTO hätte (nutze es ja manchmal selber)

[Mithrandir]

Dennoch ist der Vorschlag von himi der Bessere, auch wenn man nix gegen GOTO hat...

[Schorschi5566]

Ist aber falsch.

Result := ScanRows and ScanCols and not ScanFields;
Ach nee, die goto-Procedure ist nur anders.

[sh17]

Wie wäre es mit:
(ist doch auch elegant,geht aber nur, wenn danach schluß ist)

Delphi-Quellcode:

  
procedure MitTryFinally();
// ...
begin
  try
    if not ScanRows then
    begin
      Result := false;
      exit;
    end;

    if not ScanCols then
    begin
      Result := false;
      exit;
    end;

    if ScanFields then
    begin
      Result := false;
      exit;
    end;
  finally
    //:ende
  end;
end;

Zitat von rollstuhlfahrer:

was mich bei einem Projekt genervt hat, ist, dass Delphi/Pascal zwar die Fähigkeit von goto bietet, man diese aber nicht nutzen soll. da kommen dann Strukturen wie folgende raus:
Mit einem einfachen goto wäre das viel einfacher gegangen. Und auch viel leserlicher und schöner:

Delphi-Quellcode:

  
procedure MitGoto();
// ...
begin
  //GOTO-Struktur
  if not ScanRows then
  begin
    Result := false;
    goto ende;
  end;

  if not ScanCols then
  begin
    Result := false;
    goto ende;
  end;

  if ScanFields then
  begin
    Result := false;
    goto ende;
  end;

  :ende
end;

Bernhard

[Namenloser]

Generell sollte man goto schon vermeiden, denn meistens lassen sich solche Konstrukte anders besser lösen. Ich habe letztens allerdings zum ersten mal seit Jahren mal wieder ein goto verwendet (ich bin nicht mal sicher, ob ich es unter Delphi überhaupt schon jemals benutzt habe - es sei denn man zählt exit und break dazu, die beiden Varianten nutze ich recht häufig):

Delphi-Quellcode:

label
  loopend;
begin
  Result := nil;
  for i := 0 to FWorld.Source.LevelCount-1 do
  begin
    Level := FWorld.Source[i];
    for x := 0 to Level.EdgeLength - 1 do
      for y := 0 to Level.EdgeLength - 1 do
        if Assigned(Level[x,y].Content) and (Level[x,y].Content.Typ=AType)
           and Level[x,y].CanRemoveBlock then
        begin
          Result := Level[x,y].Content;
          goto loopend;
        end;
  end;
  loopend:
  { Weiterer Code }

(loopend ist vllt nicht gerade der aussagekräftigste Name für ein label, zugegeben, aber mir fiel in dem Moment nix besseres ein)
Das war wirklich einer der wenigen Anwendungsfälle, wo ein goto imo die beste, übersichtlichste Lösung darstellte. Ohne hätte man hier in jeder Schleife Result prüfen und ggf. die Schleife mit break abbrechen müssen. Höchstens hätte man eine Unterfunktion erstellen und das goto durch exit ersetzen können. Aber letzlich wäre das auch nix anderes als ein verkapptes goto gewesen und hätte zusätzlich noch Overhead durch das ganze function-begin-end-Geplänkel erzeugt und den Code auseinandergerissen.