Variable (Programmierung)
In der Programmierung ist eine Variable ein abstrakter Behälter für eine Größe, welche im Verlauf eines Rechenprozesses auftritt. Im Normalfall wird eine Variable im Quelltext durch einen Namen bezeichnet und hat eine Adresse im Speicher einer Maschine.
Der durch eine Variable repräsentierte Wert und gegebenenfalls auch die Größe kann – im Unterschied zu einer Konstante – zur Laufzeit des Rechenprozesses verändert werden.
Arten von Variablen
Grundsätzlich unterscheidet man zwischen Wertevariablen und referenziellen Variablen. In einer Wertevariablen wird ein Wert direkt abgelegt, während eine referenzielle Variable als Wert die Speicheradresse des eigentlichen Wertes, einer Funktion oder eines Objektes enthält. Deshalb werden referenzielle Variablen auch als Zeiger bezeichnet.
Beispiele in der Programmiersprache C#
const int i = 3; // Konstante; keine Variable
int j = 3; // Wertevariable
object k = (object)3; // referenzielle Variable auf einen Wert
object o = new object(); // referenzielle Variable auf ein Objekt
object n = null; // referenzielle Variable auf das null-Objekt (Zeiger auf Speicheradresse 0)
Func<int> f = () => 3; // referenzielle Variable auf eine Funktion
Verwendung von Variablen
Es lassen sich verschiedene Arten der Verwendung von Variablen unterscheiden:
- Eingabevariablen erhalten Werte, die von außen ins Programm, die Funktion oder Methode eingegeben werden (siehe Parameter).
- Ausgabevariablen enthalten später die Resultate der Rechnung.
- Referenzvariablen (Zeiger) dienen sowohl als Eingangs- als auch Ausgangsvariable. Der Wert kann während der Rechnung verändert werden.
- Hilfsvariablen nehmen Werte auf, die im Verlauf der Rechnung benötigt werden.
- Umgebungsvariablen repräsentieren die äußeren Randbedingungen eines Programms.
- Metasyntaktische Variablen dienen zur bloßen Benennung von Entitäten oder Teilabschnitten des Programmcodes.
- Laufzeitvariablen[1]
Sichtweisen von Variablen
Das Konzept der Variablen wird von Programmiersprachen unterschiedlich interpretiert:
- in einer rein funktionalen Programmiersprache sind Variablen einfach nur Bezeichner, das heißt, sie werden wie im Lambda-Kalkül nur dazu verwendet, die Eingabeparameter für eine Funktion zu bezeichnen. Während der Berechnung eines Funktionswerts ändert sich der Wert der Variablen deshalb nicht. Ein Ausdruck mit Variablen hat stets den gleichen Wert, unabhängig davon, an welcher Stelle im Programm er auftritt. Diese Eigenschaft ist unter dem Begriff referentielle Transparenz bekannt.
- in einer imperativen Programmiersprache kann sich dagegen der Wert einer Variablen während des Programmablaufs ändern. Der gleiche Ausdruck mit Variablen kann deshalb an verschiedenen Stellen des Programms oder zu verschiedenen Zeiten in der Programmausführung ganz unterschiedliche Werte haben.
Dementsprechend definieren verschiedene Programmiersprachen den Begriff der Variablen ganz unterschiedlich. Im Fall von Java heißt es:
„Eine Variable ist ein Speicherplatz.“[2]
In der Sprachdefinition von Scheme heißt es dagegen
„Scheme erlaubt es, dass Bezeichner für Speicherplätze stehen, die Werte enthalten.
Solche Bezeichner heißen Variablen.“[3]
Allgemein müssen für eine Variable in einer imperativen Programmiersprache vier Aspekte unterschieden werden:
- der Speicherplatz selbst als Behältnis für Daten,
- die in dem Speicherplatz abgelegten Daten,
- die Adresse des Speicherplatzes und
- der Bezeichner, unter dem der Speicherplatz angesprochen werden kann.
Kompliziert wird die Situation außerdem dadurch, dass unter einem bestimmten Bezeichner an verschiedenen Stellen des Programms oder zu verschiedenen Zeiten in der Programmausführung unterschiedliche Speicherplätze angesprochen sein können und dass es auch anonyme, also namenlose Variablen gibt.
L-Wert und R-Wert von Variablen
Typisch für imperative Programmiersprachen ist, dass ein Bezeichner auf der linken Seite einer Wertzuweisung eine andere Bedeutung („L-Wert“) hat als auf ihrer rechten Seite („R-Wert“). Die Anweisung
x := x + 1
bedeutet: „Nimm den Wert der Variablen mit dem Namen x, erhöhe ihn um eins und speichere dies an die Adresse von x.“ Der L-Wert einer Variablen ist also ihre Adresse, der R-Wert ihr Inhalt.
Variablen als Parameter von Funktionen
Auch die Parameter einer Funktion werden in deren Deklaration durch Variablen repräsentiert, die dann formale Parameter heißen. Beim Aufruf der Funktion werden den formalen Parametern dann Ausdrücke als tatsächlicher Parameter zugeordnet. Für die Übergabe der tatsächlichen Parameter an die Funktion gibt es unterschiedliche Mechanismen. Verbreitet sind die Übergabe durch Wert und die Übergabe durch Referenz.
Typen von Variablen
Mit jeder Variablen in einem Programm ist notwendigerweise ein bestimmter Datentyp (kurz: Typ) verbunden. Dies ist schon allein deshalb notwendig, weil nur der Datentyp festlegt, welche Operationen auf und mit der Variablen sinnvoll und zulässig sind. Der Datentyp einer Variablen kann auch die Speichergröße der Variablen festlegen. In der Regel hat der Programmierer die Möglichkeit, in einer Deklaration diesen Typ festzulegen. In vielen Programmiersprachen ist eine solche explizite Deklaration sogar verpflichtend. Andere Programmiersprachen bieten implizite Deklarationen, die dann verwendet werden, wenn keine expliziten Deklarationen vorhanden sind. So kannte Fortran die Konvention, dass Variablen, deren Namen mit Buchstaben zwischen I und N beginnen, vom Typ INTEGER sind und alle anderen vom Typ REAL, sofern nichts anderes festgelegt wird. Andere Programmiersprachen kennen sogenannte latente Typen. Hier sind Deklarationen nicht nötig, sondern die Maschine erkennt den Typ einer Variablen bei ihrer ersten Verwendung an ihrem Inhalt und führt diesen Typ dann stillschweigend weiter mit. In manchen Programmiersprachen kann der nicht explizit angegebene Typ einer Variablen unter gewissen Voraussetzungen auch vom Compiler mittels Typinferenz anhand anderer Typen, mit denen die Variable in einem Zusammenhang steht, erschlossen werden.
In dynamisch typisierten Programmiersprachen kann sich der Typ einer Variablen erst zur Laufzeit eines Programmes ergeben und auch während der Programmausführung ändern. Folgendes Beispiel in JavaScript illustriert dies:
function show(value) {
if (typeof value === 'number')
value += " ist eine Zahl";
console.log(value);
}
show('Hallo Welt!');
show(42);
Variablen in einer Blockstruktur
Ein wichtiges Konzept von Programmiersprachen ist das Unterprogramm, ob es nun Prozedur, Funktion, Methode oder noch anders heißt. Die allgemeinste Form dieses Konzepts ist der in der Programmiersprache Algol 60 erstmals eingeführte Block. Praktisch alle Programmiersprachen, die dieses Konzept in irgendeiner Form anbieten, erlauben es, dass Blöcke ihre eigenen Variablen besitzen, die sich von den Variablen anderer Blöcke eindeutig unterscheiden lassen. Solche Variablen heißen lokale Variablen. Eine Variable, die im ganzen Programm für alle Blöcke zur Verfügung steht, heißt globale Variable. Die Programmiersprache PHP kennt sogar den Begriff einer superglobalen Variable, die für alle Programme verfügbar sind, die zur selben Zeit von einem PHP-Interpreter bearbeitet werden.
Globale Variablen sind scheinbar bequem, weil sie im ganzen Programm sichtbar sind. Es ist nicht notwendig, sie beim Aufruf einer Funktion als Parameter zu übergeben. Sie werden aber auch leicht zur Fehlerquelle, wenn man zum Beispiel eine globale Variable versehentlich oder sogar bewusst für verschiedene Zwecke benutzt.
Auch kann es passieren, dass man eine lokale Variable mit dem Namen der globalen Variablen verwendet, von dem man annimmt, dass er im Programm bisher noch nicht benutzt wurde. Wenn es diesen Namen aber schon als Variable mit passendem Typ gibt, sofern dieser überhaupt vom Compiler oder vom Laufzeitsystem geprüft wird, dann wird deren Wert unkontrolliert überschrieben und umgekehrt. Ein schwer zu findender Fehler ist oft die Folge.
Erfahrene Entwickler verwenden globale Variablen nur auf modularer Ebene und nur dann, wenn es sich nicht vermeiden lässt.
Sichtbarkeitsbereich von Variablen (Scope)
Unter dem Sichtbarkeitsbereich (englisch scope) einer Variablen versteht man den Programmabschnitt, in dem die Variable nutzbar und sichtbar ist. Da eine lokale Variable in den meisten Programmiersprachen den gleichen Namen tragen darf wie eine globale Variable, sind Sichtbarkeitsbereiche nicht notwendig zusammenhängend: Durch die Deklaration einer lokalen Variable wird die gleichnamige globale Variable für einen bestimmten Block „verdeckt“, das heißt, sie ist in diesem Block nicht sichtbar.
Die Sichtbarkeitsregeln können auf zwei unterschiedliche sich gegenseitig ausschließende Arten festgelegt werden. Dabei ist das Konzept der Bindung wichtig. Bindung bedeutet hier die Zuordnung eines bestimmten Namens zu der damit verbundenen Variablen.
- lexikalisch (oder statisch), das heißt, der umgebende Quelltext bestimmt die Bindung
- dynamisch, das heißt, die Ausführungsschicht zur Laufzeit des Programms bestimmt die Bindung.
Im Fall einer lexikalischen Bindung sind die Bindungen für einen ganzen Block immer die gleichen, weil sie allein durch die Blockstruktur vorgegeben sind. Man kann daher allein durch Analyse des Quelltextes einer Funktion verstehen, wie sich die Funktion verhält. Dieses Konzept unterstützt daher modulare Programmierung.
Bei dynamischen Bindungsregeln können zur Laufzeit immer neue Bindungen eingeführt werden. Diese gelten dann so lange, bis sie explizit aufgehoben werden oder durch eine neue dynamische Bindung verdeckt werden. Man kann daher durch Analyse des Programmtextes einer Funktion nicht notwendigerweise verstehen, wie sich diese verhält. Selbst die Analyse des gesamten Programmtextes eines Programms hilft nicht. Es lässt sich statisch nicht verstehen, wie sich die Funktion verhält. Ihr Verhalten hängt von den jeweiligen (direkt und indirekt) aufrufenden Funktionen ab. Dies widerspricht dem Konzept des modularen Programmierens.
Die meisten modernen Programmiersprachen unterstützen nur lexikalische Bindung, zum Beispiel C++, C, ML, Haskell, Python, Pascal. Einige wenige unterstützen nur dynamische Bindung, zum Beispiel Emacs Lisp, Logo, und einige, zum Beispiel Perl und Common Lisp, erlauben dem Programmierer, für jede lokale Variable festzulegen, ob sie nach lexikalischen (statischen) oder dynamischen Regeln gebunden sein soll.
Beispiel lexikalisch im Gegensatz zu dynamisch
C++ und C verwenden lexikalische (statische) Gültigkeitsbereiche:
int x = 0;
int f() { return x; }
int g() { int x = 1; return f(); } /* g() => 0 */
Im obigen Programmfragment ergibt g() immer 0 (den Wert der globalen Variablen x, nicht den Wert der lokalen Variablen x in g()). Dies ist so, weil in f() immer nur das globale x sichtbar ist.
In Perl können lokale Variablen lexikalisch (statisch) mit dem Schlüsselwort my oder dynamisch mit dem irreführenden Schlüsselwort local deklariert werden.[4] Das folgende Beispiel entspricht dem obigen in C:
$x = 0;
sub f { return $x; }
sub g { my $x = 1; return f(); }
print g()."\n";
Dieses Beispiel benutzt my, um $x in g() einen lexikalischen (statischen) Sichtbarkeitsbereich zu geben. Daher wird g() immer 0 ergeben. f() kann g()’s $x nicht sehen, obwohl dies zum Zeitpunkt, zu dem f() aufgerufen wird, noch existiert.
$x = 0;
sub f { return $x; }
sub g { local $x = 1; return f(); }
print g()."\n";
Dieses Beispiel benutzt local, um $x in g() einen dynamischen Sichtbarkeitsbereich zu geben. Somit kann f() den lokal, in g(), geltenden Wert von $x verwenden und g() liefert den Wert 1.
In der Praxis sollte man in der Regel für Variablen in Perl "my" verwenden.
Lebensdauer von Variablen
Unter der Lebensdauer einer Variablen versteht man den Zeitraum, in dem die Variable Speicherplatz reserviert hat. Wird der Speicherplatz für andere Zwecke wieder freigegeben, so „stirbt“ die Variable und ist nicht mehr nutzbar. Lokale Variablen werden bei jedem Aufruf der Funktion erstellt. In der Regel wird der Speicherplatz beim Verlassen der Funktion wieder freigegeben. Sichtbarkeitsbereich und Lebensdauer von Variablen sind in klassischen blockstrukturierten Programmiersprachen so aufeinander abgestimmt, dass Speicherplatz für eine Variable nur so lange zugeordnet sein muss, wie Code aus dem Sichtbarkeitsbereich ausgeführt wird. Als Konsequenz davon lässt sich eine besonders einfache Art der Speicherverwaltung verwenden: Lokale Variablen werden automatisch zur Laufzeit auf einem Stapelspeicher angelegt, sobald ein Block betreten wird. Bisweilen werden diese Variablen daher automatische Variablen genannt. Technisch gesprochen wird ein Aktivierungsblock auf einem Laufzeitstapel angelegt, der beim Verlassen des Blocks wieder entfernt wird.
In manchen Programmiersprachen, zum Beispiel C, gibt es einen Zusatz static bei der Deklaration, der nur die Sichtbarkeit einer Variablen auf den Namensraum der Funktion einschränkt, nicht aber ihre Lebensdauer. Die Sichtbarkeit einer solchen Variablen verhält sich also wie die einer lokalen Variablen, die Lebensdauer dagegen wie die einer globalen, das heißt, beim Eintritt in die sie umschließende Funktion hat sie exakt den gleichen Wert wie am Ende des letzten Aufrufs der Funktion. Auf der Implementierungsseite sind dafür keine besonderen Vorrichtungen notwendig: Die Variable wird einfach im Aktivierungsblock des Hauptprogramms angelegt.
Speicherzuweisung
Die Besonderheiten der Variablenzuweisung und die Darstellung ihrer Werte variieren stark, sowohl zwischen Programmiersprachen als auch zwischen Implementierungen einer bestimmten Sprache. Viele Sprachimplementierungen weisen Platz für lokale Variablen zu, deren Umfang für einen einzelnen Funktionsaufruf auf dem Aufrufstapel gilt und deren Speicher bei der Rückkehr der Funktion automatisch zurückgefordert wird. Im Allgemeinen wird bei der Namensbindung der Name einer Variablen an die Adresse eines bestimmten Blocks im Speicher gebunden, und Operationen an der Variablen manipulieren diesen Block. Das Referenzieren ist häufiger bei Variablen, deren Werte beim Kompilieren des Codes große oder unbekannte Größen haben. Solche Referenzvariablen (Zeiger) verweisen auf die Position des Werts, anstatt den Wert selbst zu speichern, der aus einem Speicherbereich zugewiesen wird, der als Heap bezeichnet wird.
Gebundene Variablen haben Werte. Ein Wert ist jedoch eine Abstraktion. In der Implementierung wird ein Wert durch ein Datenobjekt dargestellt, das irgendwo gespeichert ist. Das Programm oder die Laufzeitumgebung muss Speicher für jedes Datenobjekt reservieren und, da der Speicher endlich ist, sicherstellen, dass dieser Speicher zur Wiederverwendung bereitgestellt wird, wenn das Objekt nicht mehr zur Darstellung des Werts einer Variablen benötigt wird.
Vom Heap zugewiesene Objekte müssen zurückgefordert werden, insbesondere wenn die Objekte nicht mehr benötigt werden. In einer Programmiersprache mit Garbage Collector, zum Beispiel C#, Java oder Python, fordert die Laufzeitumgebung Objekte automatisch zurück, wenn vorhandene Variablen nicht mehr auf sie verweisen können. In Programmiersprachen ohne Garbage Collector, zum Beispiel C oder C++, muss das Programm und der Programmierer explizit Speicher zuweisen und ihn später freigeben, um seinen Speicher zurückzugewinnen. Andernfalls kommt es zu Speicherverlusten, bei denen der Heap während der Programmausführung aufgebraucht wird.
Wenn sich eine Variable auf eine dynamisch erstellte Datenstruktur bezieht, kann auf einige ihrer Komponenten nur indirekt über die Variable zugegriffen werden. Unter solchen Umständen müssen Garbage Collectors einen Fall behandeln, in dem nur ein Teil des von der Variablen erreichbaren Speichers zurückgefordert werden muss.
Namenswahl
Die Wahl von Variablennamen bleibt meist dem Programmierer überlassen. Zur Vereinfachung der Nachvollziehbarkeit der Quelltexte empfiehlt es sich, möglichst selbsterklärende Variablennamen oder auch sogenannte sprechende Variablennamen zu verwenden, selbst wenn dies zu recht langen Bezeichnern führt.[5] Namenskonventionen für Variablen verbessern die Lesbarkeit und Wartbarkeit der Quelltexte. Moderne Editoren haben Vorrichtungen, um den Schreibaufwand auch bei langen Variablennamen zu reduzieren. Nach der Kompilierung ist der Programmcode weitgehend oder sogar vollständig unabhängig von den verwendeten Variablennamen.
Initialisierung
Variablen sollten vor ihrer Benutzung initialisiert werden, das heißt, einen definierten Wert zugewiesen bekommen. Dies kann durch die Vergabe von Standardwerten durch das Laufzeitsystem der verwendeten Programmiersprache geschehen oder durch explizite Zuweisung eines Wertes an die Variable.
Bei Programmiersprachen, die nicht automatisch alle verwendeten Variablen initialisieren, sind uninitialisierte Variablen eine Quelle für schwer zu findende Fehler: Da die Variable ohne Initialisierung einen zufälligen Wert enthält, wird auch das Verhalten des Programms unvorhersagbar, so dass es manchmal falsche Ergebnisse liefert oder gar abstürzt. Enthält der für die Variable reservierte Speicherbereich einen scheinbar erwarteten Inhalt aus einem vorhergehenden Programmdurchlauf, so spricht man auch von einer Speicherinterferenz.
Siehe auch
Weblinks
Einzelnachweise
- Festlegen und Löschen von Laufzeitvariablen – ein Beitrag im C++-Community-Forum (die betreffende Seite wurde zuletzt geändert am 10. Juli 2008); mit einem auch sogenannten Zitat vom Visual Studio Analyzer wo es dann im Folgenden heißt: „Laufzeitvariablen sind Name/Wert-Paare, die von Ereignisabonnenten festgelegt und von Ereignisquellen gelesen werden. Das Verwenden von Laufzeitvariablen hilft beim Sammeln genauer Einzelheiten über bestimmte Ereignisse.“
- Tim Lindholm, Frank Yellin: The Java Virtual Machine Specification. Addison-Wesley, 1996: “A variable is a storage location.”
- Michael Sperber, William Clinger, R. K. Dybvig, Matthew Flatt, Anton van Straaten: Report on the Algorithmic Language Scheme. Revised (5.97): “Scheme allows identifiers to stand for locations containing values. These identifiers are called variables.”
- What’s the difference between dynamic and static (lexical) scoping? Perl FAQ 4.3
- N. Gorla, A. C. Benander, B. A. Benander: Debugging Effort Estimation Using Software Metrics. In: IEEE (Hrsg.): IEEE Transactions on Software Engineering. Band 16, Nr. 2, Februar 1990, S. 223–231, doi:10.1109/32.44385 (englisch).