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

[bernau]

Zitat von stahli:

Vielleicht könnte man in der DP ein Unterforum "Wunschliste an Delphi" auf machen und dort gezielt Meinungen zu Verbesserungen zusammentragen (und ggf. bei allgemeiner Zustimmung an Emb. weiterleiten).

Das wäre ne klasse Sache.

[Meflin]

Zitat von stahli:

@DP: Vielleicht könnte man in der DP ein Unterforum "Wunschliste an Delphi" auf machen und dort gezielt Meinungen zu Verbesserungen zusammentragen (und ggf. bei allgemeiner Zustimmung an Emb. weiterleiten).

http://stackoverflow.com/questions/2...elphi-nitpicks

Und da ließt die Delphi-Prominenz bereits mit.

[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.

[Assarbad]

Zitat von himitsu:

Und grad eben hab ich es auch zum ersten Mal im Apache (PHP) hinbekommen.
> ERROR 500: Internal Server Error

Das ist unfair. Hättest du es lieber wenn Apache irgendwelche Details ausplaudern würde, die einem Angreifer nutzen?

• Was mich am meisten nervt sind Unterbrechungen durch Außenstehende, vor allem durch Nichtprogrammierer. Die haben meist keine Ahnung, daß es eine Weile dauert bis ein Programmierer wieder im "Flow" ist und stören jederzeit ohne Nachdenken mit den banalsten Dingen. Somit verplämpern solche Leute (bspw. vom Marketing) nicht nur meine Zeit sondern ggf. ihre eigene, ohne daß sie es begreifen. Denn am Ende soll ja trotzdem irgendein Termin eingehalten werden.
• An der zweiten Stelle stehen Compilerfehler. Besonders wenn der Optimierer Mist baut. Da kommt es dann bspw. vor, daß eine Annahme getroffen wird, die nicht stimmt und dann in fehlerhaftem Code resultiert. Mein letzter Fall war mit GCC unter x64 Linux. Da verwendete der Optimierer mal locker flockig einen Opcode der eine bestimmte Ausrichtung des übergebenen Speicherbereichs erfordert - und natürlich knallt's. Leider findet man sowas erst, wenn man einen Disassembler/Debugger zur Hand nimmt und nachguckt.
• Zuguterletzt nerven mich schlechte Fehlerberichte von Benutzern (sozusagen das Gegenstück zu den "internen Fehlern" vom Anfang). Wenn es danach geht, bräuchte man auch nur "interner Fehler" anzeigen, denn die Benutzer neigen ohnehin dazu einem nur zu berichten: "Da war ein Fehler". Siehe auch hier.

Ansonsten natürlich die drei Feinde des Programmierers: Tageslicht, frische Luft und das Gebrüll der Vögel.

[Luckie]

Zitat von Assarbad:

denn die Benutzer neigen ohnehin dazu einem nur zu berichten: "Da war ein Fehler".

Oder hier im Forum: Funktioniert nicht. Und dann am besten noch ohne Quellcode zu posten.

Ansonsten sind das genau die Punkte, die mich auch nerven. Wobei es recht schwer ist in den Flow zu kommen, wenn man mit mehreren Kollegen in einem Raum sitzt. Da wird sich unterhalten, da wird rumgeräumt, da arbeiten zwei am Arbeitsplatz nebenan zusammen an einem Code... Und dann heißt es immer wieder: "Kannst du mal gucken...".

[Assarbad]

Zitat von mkinzler:

Tja durch die Unicode-Umstellung rächt sich halt vieles

Vor allem so unsinnige Änderungen wir PChar. Wobei gerade bei PChar zu PWideChar ein gleichnamiger Typ in Win32 existiert (eben PCHAR). Und der ist immer ein Byte pro Element breit. Und da PChar einstmals der einzige verfügbare Typ war bei dem man auch Zeigerarithmetik benutzen konnte, fand dieser Typ an vielen Stellen Verwendung. Auch jetzt bleibe ich noch immer bei meiner Meinung (Englisch).

Zitat von himitsu:

OK, eigentlich nicht das Unicode selber, sondern eher die Kombination aus Ansi und Unicode, bzw. wenn man Methoden erstellen will, welche "beides" Unterstützen sollen und dabei nicht auf die automatische Stringumwandlung von Delphi zurückreifen sollen.

Tja, wieviele böse Worte hätte man sich damals mit einem ordentlichen Präprozessor in Delphi nur sparen können

Aber sei beruhigt. Ich hatte "geerbten" Code (in C) bei dem die ursprünglichen Autoren sinnloserweise die Konvertierung mehrfach hin und zurück vornehmen. Das alles um die gleiche Anwendung auf 9x und NT zu benutzen. Leider haben sie dabei soviele Fehler eingebaut, daß es günstiger war das ganze Ding auszuweiden und stattdessen den "normalen" Weg zu gehen bei dem man entweder für Unicode oder für ANSI/MBCS kompiliert.

Zitat von Luckie:

Wobei es recht schwer ist in den Flow zu kommen, wenn man mit mehreren Kollegen in einem Raum sitzt. Da wird sich unterhalten, da wird rumgeräumt, da arbeiten zwei am Arbeitsplatz nebenan zusammen an einem Code... Und dann heißt es immer wieder: "Kannst du mal gucken...".

Absolut! Leider ist den meisten Chefs offenbar nicht klar, daß der "Arbeiter am Band" und der "Geistesarbeiter" weder von den Herausforderungen her noch von den Arbeitsbedingungen her wirklich vergleichbar sind. Obwohl es normalerweise dann bei mir halbwegs klappte, wenn nur Entwickler im gleichen Raum waren. Aber zuletzt war auch ein Admin dabei und dann war es aus. Der sabbelte ständig irgendwelche belanglosen Dinge dazwischen und an Arbeiten war nicht mehr zu denken.

[himitsu]

Ich weiß garnicht was alle gegen ein nettes GOTO haben,

aber aktuell bin ich wohl total krank, denn ich würde mir auch noch ein GOSUB in Delphi wünschen.

[Luckie]

Bei mir im Raum sind wir fünf Mann. Einer ist Admin, Entwickler und Support, da klingelt dann immer das Telefon. Der andere macht QM und schraubt Rechner zusammen, was auch nicht immer ohne Lärmbelästigung von statten geht.

[wicht]

Das ist Luxus.
Wir sind in einem größeren Raum wohl durchschnittlich 15 Leute. Dazwischen stehen zwar Trennwände und Schränke, aber das ändert nichts daran, dass man doch oft abgelenkt wird. Das ist wohl auch einer der Gründe, warum ich meine Kopfhöhrer von zuhause immer mit zur Arbeit nehme.. Musik lenkt weniger ab, als Leute, die am Telefon Service machen, oder Leute, die für Besprechungen nicht so gerne den Besprecher, sondern das Büro nutzen... Das musste mal raus ...