Ist nur guter Codestil, keine Pflicht.
Meine Frage an dich wäre ja jetzt, was spricht gegen ein this? Und für die (nicht unwahrscheinliche) Gegenfrage warum? bleibt hier nur der Verweis darauf, dass es nun einmal Konvention ist. Ist genau wie ein self. in Delphi sauberer, da man sehr leicht lokale Variablen und "globalere" Klassenvariablen unterscheiden kann.
Was ein Dozent bemängelt und was nicht ist, nun ja, nicht so wirklich wichtig. Hatte damals auch sehr verschiedene Tutoren, die Übungen korrigiert haben. Da gab es auch einzelne, da konnte man abgeben was man wollte und andere hatten da sehr viel eingeschränktere Vorstellungen (z.B. wurden 0 Punkte vergeben, wenn einzelne Kommentare fehlten).
Letztlich ist für dich später wichtiger, was dein Arbeitgeber verlangt. Meiner Meinung nach gibt es keine Firma, die möchte dass man auf gar keinen Fall seine Variablen Qualifiziert (wäre auch sinnlos), aber ich kenne einige die eben darauf bestehen.
Insbesondere bei Konstanten hat es auch eine Menge Vorteile. Sagen wir mal du hast folgendes :
Code:
class Klasse1 {
public static final int IRGENDWAS = 1;
public void doFoo(final int x) {
if (x == IRGENDWAS) {
doSomething();
}
else {
doSomethingElse();
}
}
}
class Klasse2 {
public static final int IRGENDWAS = -1;
public void doFoo() {
Klasse1 klasse1 = new Klasse1();
klasse1.doFoo(IRGENDWAS);
}
}
Ok, ein wenig konstruiert und absolut schlecht benannte Variablen, aber was du hier siehst ist das Problem, dass beide Klassen ein gleich benannte Konstante enthalten, die aber unterschiedliche Werte hat. Wenn Klasse2 etwas umfangreicher wäre, dann kannst du sehr leicht übersehen, dass du hier eine Konstante gleichen Namens defininert hast. Noch interessanter wird es, wenn du zwei verschiedene Dateien hast, die im import auftauchen. Beide enthalten entsprechend wieder eine gleich benannte Konstante mit unterschiedlichen Werten, welche würdest du jetzt korrekt übergeben?
Hier ist der Fall :
Code:
class Klasse2 {
public static final int IRGENDWAS = -1;
public void doFoo() {
Klasse1 klasse1 = new Klasse1();
klasse1.doFoo(Klasse1.IRGENDWAS);
}
}
eindeutiger. Es wird ein Fehler vermieden der nicht gemacht werden braucht. Wie gesagt, es ist einfach Konvention. Das mit dem Leerzeilen nachträglich einfügen ist halt auch so eine Sache. Es kostet einfach weniger Zeit alles gleich zu tun.
Ich weiß nicht wie viel Erfahrung du schon mit größeren Projekten hast (wer in dem Alter studiert...)
Jedenfalls kommen immer wieder Leute, die sagen ihre Kommentare und die Formatierung folgt noch. Ich frage dann gerne häufiger nach wann. Habe es selten erlebt, dass das so wirklich klappt. Und wenn du mal etwas umfangreichere Projekte hast, an denen mehr als eine Person arbeitet, du wirst schnell merken dass ein Nachher zu spät ist. Bezieht sich hier nicht direkt auf deinen Code, ist vielmehr der Tipp es dir gleich richtig anzugewöhnen. Je später du so etwas machst, desto schwerer wird es dir fallen. Und glaub mir, deinem späteren Chef (oder dem aktuellen) wird es auch besser gefallen, wenn du gleich sauber arbeitest (wie gesagt, super unsauber ist das hier nicht!)