Warum dürfen lokale und Membervariablen den gleichen Namen haben?

Warum ist es in den objektorientierten Programmiersprachen eigentlich so, dass Membervariablen denselben Namen haben dürfen wie lokale Variablen?

class Test
{
    private int number;

    private void Function()
    {
        int number = 0;

        number++;
        // --> Lokale Variable

        this.number++;
        // --> Membervariable
    }
}

Wenn man sich nicht angewöhnt, Membervariablen immer mit einem m_ oder dergleichen zu benennen, kann das ganze ja ein Risiko sein:

Einmal das this vergessen und es wird die falsche Variable benutzt.

Oder irgendwo eine lokale Variablendeklaration löschen und vergessen, alle Vorkommnisse zu löschen, und der Compiler interpretiert den Aufruf, der der lokalen Variable galt, plötzlich für die Membervariable.
(Hätte die Variable anders geheißen, hätte es Compilerfehler gegeben, weil der Name nicht bekannt ist.)

Warum hat man nicht von vornherein festgelegt, dass Membervariablen und lokale Variablen bzw. Parameter nicht denselben Namen haben dürfen und das einen Compilerfehler bringt? Gibt es einen praktischen Grund, die Namensgleichheit zu erlauben?

NeeLa

Die Variable Membervariable liegt schlicht und weg in einem übergeordneten Sichtbarkeitsbereich, das kann schon relativ gut an den Klammern sehen.

Es gilt hier also viel mehr das grundsätzliche Prinzip der scopes und hat weniger mit oop Sprache oder nicht zu tun.

Edit: Im übrigen wird man damit keine Probleme haben, wenn man sich an die allg. Namenskonventionen hält. So fangen in c# die Eigenschaftsmethoden (mit denen man auf private member zugreift) grundsätzlich mit einem Großbuchstaben an, wärend private member mit einem Unterstrich beginnen sollten und lokale Variablen einfach klein geschrieben werden.

Das ist ja wohl gerade das, was OP meinte. Z.B. kann man afaik in C# in untergeordneten Scopes keine Variablennamen aus übergeordneten Scopes erneut benutzen, obwohl die Sichtbarkeit klar geregelt ist:

class blubb {
    void bla() {
        int i;
        {
            int i; // error
        }
    }
}

NeeLa schrieb:

Die Variable Membervariable liegt schlicht und weg in einem übergeordneten Sichtbarkeitsbereich, das kann schon relativ gut an den Klammern sehen.

Das ist mir auch klar. Ändert aber nichts an der Gültigkeit der Frage, wieso ein Compiler die Benennung so zulässt. Es wäre möglich gewesen, die Programmiersprache so zu definieren, dass es nicht möglich ist. Was war jetzt die Intention, es doch zuzulassen?

NeeLa schrieb:

Es gilt hier also viel mehr das grundsätzliche Prinzip der scopes und hat weniger mit oop Sprache oder nicht zu tun.

Wie periscopes gesagt hat: Das Phänomen existiert innerhalb von Funktionsscopes nicht.

NeeLa schrieb:

Edit: Im übrigen wird man damit keine Probleme haben, wenn man sich an die allg. Namenskonventionen hält.

Das ist mir selbst auch klar und ich mache es auch so. Aber es stellt technisch gesehen ja schon ein Risiko dar.

PS: Bezüglich Namenskonvention: Viel Spaß, wenn du mal gezwungen bist, VB.NET zu programmieren und ein Public Property hast sowie Funktionen, wo ein gleichnamiger Parameter vorkommt (z.B. ein Konstruktor, der alle wesentlichen Propertys setzt). Da nützt dir die Tatsache, dass dein Property großgeschrieben und dein Parameter kleingeschrieben ist, gar nichts.

SeppJ

Ja ja schrieb:

NeeLa schrieb:

Die Variable Membervariable liegt schlicht und weg in einem übergeordneten Sichtbarkeitsbereich, das kann schon relativ gut an den Klammern sehen.

Das ist mir auch klar. Ändert aber nichts an der Gültigkeit der Frage, wieso ein Compiler die Benennung so zulässt. Es wäre möglich gewesen, die Programmiersprache so zu definieren, dass es nicht möglich ist. Was war jetzt die Intention, es doch zuzulassen?

Damit nicht irgendein Depp deinen Code kaputt machen kann, indem er einen gleichlautenden Bezeichner in einem größeren Scope einführt. Und umgekehrt nicht irgendein anderer Depp den gesamten Code kaputt machen kann, indem er einen gleichlautenden Bezeichner in einem kleineren Scope einführt.

NeeLa

Viel Spaß, wenn du mal gezwungen bist, VB.NET zu programmieren

Lieber werfe ich meinen Laptop aus dem Fenster des 8. Stocks und spring hinter her als mit VB.NET zu programmieren, aber gut.. .

Fakt ist, ihr Vergleicht das:

public static void Main(String[] args)
        {
            int a;
            {
                int a;
            }
        }

mit dem:

class Program
    {
        int a;
        public static void TestFunc()
        {
            int a = 10;
            Console.WriteLine(a);   // 10
        }
    }

Na? Fällt da nicht irgendwie was kleines auf?

SeppJ schrieb:

Damit nicht irgendein Depp deinen Code kaputt machen kann, indem er einen gleichlautenden Bezeichner in einem größeren Scope einführt.

Ja gut, das würde erklären, wieso es zum Beispiel in C++ möglich ist, dass Membervariablen und globale Variablen denselben Namen haben dürfen.
Aber meine Frage bezieht sich ja nur auf die Variablen innerhalb einer Klasse. Und eine Klasse ist doch immer ein- und dieselbe Übersetzungseinheit.
Das heißt, derjenige, der die Membervariable einfügen kann, hat auch Zugriff auf sämtliche Funktionen und damit lokalen Variablen dieser Klasse. Wie soll also ein Depp meinen Code kaputtmachen können?

NeeLa schrieb:

Viel Spaß, wenn du mal gezwungen bist, VB.NET zu programmieren

Lieber werfe ich meinen Laptop aus dem Fenster des 8. Stocks und spring hinter her als mit VB.NET zu programmieren, aber gut.. .

Naja, ich bin nicht so selbstmorgefährdet, also ertrage ich die Last.

NeeLa schrieb:

Na? Fällt da nicht irgendwie was kleines auf?

Ich weiß, dass das technisch was anderes ist. Den technischen Hintergrund bezüglich Variablenlaufzeit usw. verstehe ich.

Hier geht es also nur um eine Benennungskonvention im Programmiersprachenstandard:
Gibt es einen Grund, wieso man zulassen muss, dass Membervariablen und lokale Variablen gleich heißen dürfen? Könnte das Verbieten dieses Features irgendetwas kaputtmachen?
(So wie im obigen fiktiven C++-Beispiel, wo das Einfügen einer gleichnamigen globalen Variable in einer generischen Bibliothek meinen Code kaputtmachen könnte, wenn gleiche Namen nicht erlaubt wären, weil der Schreiber der Bibliothek meine Klasse gar nicht kennt und bei ihm der Fehler daher nicht auftritt, sondern erst, wenn ich mich wieder dransetze.)

EOP

NeeLa schrieb:

Lieber werfe ich meinen Laptop aus dem Fenster des 8. Stocks und spring hinter her als mit VB.NET zu programmieren, aber gut.. .

Vorher Fenster öffnen nicht vergessen - du könntest dir sonst weh tun.

NeeLa

Vorher Fenster öffnen nicht vergessen - du könntest dir sonst weh tun.

Ich seh schon, "Ergen Omut Pockmann", kurz EOP. Leidenschaftlicher VB.NET Programmierer. Bezahlt seinen Senf seit der Beta von .NET bis dato mit VB. In seiner Freizeit streicht er nicht nur Senf auf seine Brötchen, gerne gibt er seinen Senf auch in Forumbeiträgen dazu _Kostenlos ..

Das war dann mal mein Senf.

EOP

NeeLa schrieb:

Ich seh schon, "Ergen Omut Pockmann", kurz EOP. Leidenschaftlicher VB.NET Programmierer. Bezahlt seinen Senf seit der Beta von .NET bis dato mit VB. In seiner Freizeit streicht er nicht nur Senf auf seine Brötchen, gerne gibt er seinen Senf auch in Forumbeiträgen dazu _Kostenlos ..

Das war dann mal mein Senf.

Selten so einen schwachsinnigen post gelesen.
Dagegen sind sogar meine top-notch.

NeeLa

Achso klar, wenn wir schon schwachsinnig sind:

Vorher Fenster öffnen nicht vergessen - du könntest dir sonst weh tun.

Ich denke aber "absolut sinnlos" trifft es viel besser, oder was war deine Intention mit diesem Kommentar?

Aber heeey,

Dagegen sind sogar meine top-notch.

vor allem wenn jemand Ironie in vollem Maße benutzt, aber scheinbar nicht mal ansatzweise dazu in der Lage ist sarkasmus zu verstehen.

Mechanics

@NeeLa: lass bitte diese Diskussionen, EOP ist halt so. Gewöhn dich dran, der Umgangston in dem Forum kann recht locker sein, man muss nicht auf alles angehen. Außerdem fand ich als unbeteiligter seinen Kommentar auch lustiger

hustbaer

Ja ja schrieb:

PS: Bezüglich Namenskonvention: Viel Spaß, wenn du mal gezwungen bist, VB.NET zu programmieren und ein Public Property hast sowie Funktionen, wo ein gleichnamiger Parameter vorkommt (z.B. ein Konstruktor, der alle wesentlichen Propertys setzt). Da nützt dir die Tatsache, dass dein Property großgeschrieben und dein Parameter kleingeschrieben ist, gar nichts.

Ist VB.NET alles ernstes immer noch case-insensitive?
Ist aber eigentlich auch egal. Wenn das so ist, dann muss man in VB einfach andere naming conventions verwenden.

hustbaer

@Mechanics
EOP sowie 1-2 andere nerven schon gewaltig. Ich verstehe nicht wieso man das gut heissen sollte. Nur weil die meisten aufgegeben haben (inklusive der Moderatoren) heisst das ja nicht dass es gut so ist.

NeeLa

Naja, die Datenbank kann den Platz für meinen Account jetzt jedenfalls anderweitig verwenden. Ich kann dafür leider kein Verständnis aufbringen.
Ich möchte mich an dieser Stelle nur noch bei den Moderatoren für die nicht passenden Beiträge zu diesem Thread entschuldigen.

Viel Spaß weiterhin mit dem Forum!

EOP

hustbaer schrieb:

@Mechanics
EOP sowie 1-2 andere nerven schon gewaltig. Ich verstehe nicht wieso man das gut heissen sollte. Nur weil die meisten aufgegeben haben (inklusive der Moderatoren) heisst das ja nicht dass es gut so ist.

Ceterum censeo Carthaginem esse delendam. :p

NeeLa schrieb:

Naja, die Datenbank kann den Platz für meinen Account jetzt jedenfalls anderweitig verwenden. Ich kann dafür leider kein Verständnis aufbringen.
Ich möchte mich an dieser Stelle nur noch bei den Moderatoren für die nicht passenden Beiträge zu diesem Thread entschuldigen.

Viel Spaß weiterhin mit dem Forum!

Na dann heul doch.

@hustbaer:
Bei vBullettin gab es eine praktische Option: "ignore this member"
Musst du bei phpBB eben brain-technisch implementieren.

So, nach den Off-Topic-Diskussionen, wie sieht's denn nun mit meiner ursprünglichen Frage aus?

Hätte es Probleme geben können, wenn man in einer Programmiersprache von vornherein verbietet, dass lokale Variablen in Memberfunktionen einer Klasse und die Membervariablen dieser Klasse nicht denselben Namen haben dürfen?

Wie gesagt, in Bezug auf globale Variablen oder Konstanten ist mir das klar:
Wenn ich eine Bibliothek verwende und der Schreiber der Bibliothek irgendwann eine Konstante einbaut, die denselben Namen hat wie irgendein Member in meiner Klasse, dann haben wir ein Problem. Der Schreiber der Bibliothek kennt meine Klasse nicht, kann also nichts dafür. Seine Bibliothek kompiliert. Aber mein Code kompiliert jetzt nicht mehr.

Dieses Phänomen trifft jedoch nicht auf Variablen innerhalb einer Klasse zu:
Wenn ich eine Klasse schreibe und da irgendwelche lokalen Variablen benutze und dann schreibt jemand anderes meine Klasse weiter und führt eine Membervariable mit dem Namen ein, naja, dann muss er sich eben darum kümmern, dass die lokalen Variablen vorher erstmal alle umbenannt werden bzw. den Namen seiner Membervariable ändern.
Aber die Situation, dass er eine Änderung an der Klasse durchführt, die bei ihm gar kein Problem macht, sondern erst bei mir nicht mehr kompiliert, das geht eben nicht. Denn die Klasse ist ja ein Ganzes und muss auch als Ganzes kompiliert werden. Eine Situation wie oben mit der globalen Variable ist hier also meines Wissens nach nicht möglich. Der Bearbeiter einer Klasse hat immer Zugriff auf alle Teile der Klasse.

Deshalb nochmal die Frage: Gäbe es trotzdem ein Problem, wenn man von Anfang an die gleiche Benennung von lokalen und Membervariablen einer Klasse verbieten würde?

SeppJ

Ja ja schrieb:

Deshalb nochmal die Frage: Gäbe es trotzdem ein Problem, wenn man von Anfang an die gleiche Benennung von lokalen und Membervariablen einer Klasse verbieten würde?

Warum sollte man etwas ohne Grund verbieten? Man könnte auch verbieten, dass Bezeichner mit 'i' losgehen, damit man es nicht mit int verwechseln kann.

hustbaer

@Ja ja
Das Problem tritt genau so bei Membervariablen auf, und zwar bei Membervariablen von Basisklassen.
Lösen könnte man das lediglich dadurch dass Membervariablen immer irgendwie qualifiziert werden müssen (bzw. theoretisch auch dadurch dass lokale Variablen immer qualifiziert werden müssen, was aber wohl die umständlichere Variante wäre).

@SeppJ
Ist ja nicht ohne Grund. Es ist ne potentielle Fehlerquelle.
Man kann jetzt unterschiedlicher Meinung darüber sein wie schlimm diese ist. Aber dass grundsätzlich die Gefahr besteht, dass es zu Verwechslungen kommt, ist mMn. klar.

hustbaer

EOP schrieb:

@hustbaer:
Bei vBullettin gab es eine praktische Option: "ignore this member"
Musst du bei phpBB eben brain-technisch implementieren.

Du könntest auch einfach deine sinnlosen Beiträge einstellen. Wäre für alle Beteiligten weniger Arbeit (sogar für dich, musst dann ja weniger tippen).