nicht einsehbarer Fehler im code, kann nicht mehr übersetzten

[EinNickname9]

Beides ist gleichwertig und gleichzusetzen.

 

[kneitzel]

Naja - codestyles sind etwas, an das man sich halten sollte und die aber einfach nur gelten auf Grund einer Übereinkunft.

Pattern sind sowas wie Best Practices - Also wenn ein bestimmtes Problem vorliegt, dann bietet es sich als Musterlösung an. Ist also auch nur ein Ratschlag. Der Wert ist in erster Linie eine Begriffsdefinition die in Diskussionen hilft. Wenn ich von einem Observer Pattern rede, dann versteht der Andere direkt, was gemeint ist.

Anti-pattern sehe ich als eine Regel, was man unterlassen sollte. Das kann man auch gerne als Übertreibung formulieren. Mir fällt da aus meiner Vergangenheit ein "NEVER EVER build SQL queries with string concatenation!" ein. Das ist ein deutlicher Ratschlag mit dem klaren Wissen, dass DDL Statements oft nicht anders gebaut können wenn diese dynamisch sind.
Diese Dinge sind wichtig - aber bitte IMMER mit Erläuterung. Eine Aussage wie "Das ist ein Anti-Pattern" besagt nichts. Es wird kein Begriff gebildet (Also nicht wie bei den Pattern etwas, das ich nachschlagen kann!) und es wird auch kein Anhaltspunkt gegeben, was das Problem ist. Also eine Aussage, die man sich so eigentlich sparen kann (So man nicht noch mehr dazu schreibt)

Was das this angeht: Das soll jeder so handhaben, wie er will. Das macht zur Not die IDE so, wie ich es will. Ich mag es nicht und habe es in der Regel nur in Settern weil da in der Regel der Parameter genau so heißt wie die Instanzvariable. Wenn dies nicht so ist, dann kann man es aber auch weg lassen. Die Angst, dass bei einem Refactoring ein Problem entsteht, ist unbegründet (Zumindest IntelliJ fügt ein this. davor, wenn eine Instanzvariable von einem Parameter versteckt wird).

Das einfach einmal als meine 2Cent zu dem Thema.