nicht angemeldet T-Rex
Der Martin
Auge
Robert B.
Rolf B
Der Martin
T-Rex
Rolf B
Robert B.
T-Rex
Moin,
bei einem neuen Projekt soll ich mich an die PSR 12 halten. Um genauer zu sein, wird gesagt das mein Variablenname $arArray sich nicht an die PSR 12 Vorgaben hält. Er soll $array heißen.
Jetzt kann ich leider diesbezüglich nichts finden. Meiner Meinung nach hält sich $arArray an die PSR 12 Vorgaben.
Damit ich aber wirklich sicher bin, bevor ich eventuell in eine Konfrontation gehe, wollte ich hier nochmal nachfragen wie ihr das seht? Verstößt $arArray gegen die PSR 12?
Wie sieht es mit anderen Variablennamen aus? $strString, $iInteger, $objObject, $bBoolean?
Gruß
T-Rex 7
Hallo,
bei einem neuen Projekt soll ich mich an die PSR 12 halten. Um genauer zu sein, wird gesagt das mein Variablenname $arArray sich nicht an die PSR 12 Vorgaben hält. Er soll $array heißen.
hmm, ich finde in der PSR-12 gar keine konkreten Vorgaben für Bezeichner.
Jetzt kann ich leider diesbezüglich nichts finden.
Ach, du auch nicht? 😉
Wie sieht es mit anderen Variablennamen aus? $strString, $iInteger, $objObject, $bBoolean?
Keine Ahnung, aber meine persönliche Meinung: Bezeichner-Präfixe, die den Typ angeben, machen den Code nicht wirklich verständlicher. Wenn schon Präfixe nach irgendeinem System, dann ist es nützlicher, wenn die den Verwendungszweck angeben. Der Typ ergibt sich daraus oft implizit.
Einen schönen Tag noch
Martin
Hallo
bei einem neuen Projekt soll ich mich an die PSR 12 halten. Um genauer zu sein, wird gesagt das mein Variablenname $arArray sich nicht an die PSR 12 Vorgaben hält. Er soll $array heißen.
Jetzt kann ich leider diesbezüglich nichts finden. Meiner Meinung nach hält sich $arArray an die PSR 12 Vorgaben.
Damit ich aber wirklich sicher bin, bevor ich eventuell in eine Konfrontation gehe, wollte ich hier nochmal nachfragen wie ihr das seht? Verstößt $arArray gegen die PSR 12?
Wie sieht es mit anderen Variablennamen aus? $strString, $iInteger, $objObject, $bBoolean?
Bleibt also die Regel aus PSR-1, die für die Schreibweise ausdrücklich keine Empfehlung ausspricht.
Tschö, Auge
Moin T-Rex,
"PSR may refer to …"
Abk. zumindest 1x ausschreiben kann beim Verständnis helfen 😉
(Vermutlich hättest du damit auch gleich schon den passenden Link gefunden.)
Viele Grüße
Robert
Naja. Immhin wusste Tante Gertrut Google (also die, welche mich immer noch mit Keksen füttert) wie ich „unterwegs“ bin und hat mir als erstes diese „PSR 12“ - also vor den Testberichten über die gleichnamige Bohrmaschine - angeboten.
(Was den „Senf“ betrifft: Fachlich ist „alles gesagt“.)
Hallo T-Rex,
wie schon herausgestellt, machen die PSRs dazu keine Aussage.
Aber ich.
Was Du da verwendest, ist eine Form der Ungarischen Notation. Aber du verwendest sie falsch, und bist damit in zahlreicher Gesellschaft.
Wie der Wikipedia-Artikel schildert, hatte Charles Simonyi, der diese Notation bei und für Microsoft erfand, damit eine semantische Ergänzung zu Variablennamen im Sinn. Es ging ihm niemals um den deklarativen Datentyp.
Aber die Betriebssystemabteilung von Microsoft sah das anders, sie waren vermutlich noch zu assemblerlastig und heilfroh, eine minimale Typisierung einführen zu können. Und so bekamen wir Namen wie hFile (was ok ist), aber dann auch dwCounter (dw = double word, ein 32-bit Wert) - und das ist in einer Hochsprache genauso sinnlos wie $arWords.
Dass eine Variable ein Array ist oder ein Integer oder ein String, weiß man zumeist relativ einfach. In C/C++ weiß es schon der Compiler und die Intellisense im Editor - in PHP nicht unbedingt, aber neuere Versionen von PHP unterstützen Typdeklarationen, nicht nur Type Hints, und geben dem Editor damit auch klare Hinweise. Für ältere PHP Versionen gibt es phpdoc Kommentare, mit denen man Typen deklarieren kann. Anständige Editoren verstehen auch phpdoc.
Was davon nicht abgedeckt wird, ist die Bedeutung des Strings oder des Integers in einer Variablen. Ist es ein Zähler, ein Index, ein Name, ein Key, ein DB-Handle, eine File-Ressource? Das war das Problem, das Simonyi lösen wollte.
Dein ar-Präfix finde ich deshalb komplett überflüssig, genauso wie der Namen $array für eine Variable sinnbefreit ist. Hier im Thread ist das natürlich nur ein Demo-Name, aber ich meine, von Dir solche Namen auch schon in Codeauszügen gesehen zu haben. Vielleicht irre ich mich ja auch. Wie auch immer - wenn Du eine Datenbankzeile hast, dann nenne die Variable $row. Nicht $array, nicht $arRow und schon gar nicht $arArray. Wenn Du einen Namen mit explode in Teile zerlegt hast, dann nenne das beispielsweise $nameParts (oder $name_parts). Wenn Du zählen willst, wieviele Vokale in einem Namen stecken, zähle das in $cVokale oder deutscher $zVokale - das war Simonyis Idee: c für Count (oder z für Zähler).
Guck in den verlinkten Wikipediaartikel für weitere Informationen. Vor allem in den letzten Abschnitt, Kritik. Wenn Du auf mich kleines Licht nicht hören willst, dann vielleicht auf Koryphäen wie Robert C. Martin (Agile Manifest, Clean Code), Linus Torvalds (Git, Linux) oder Prof. Dr. Bjarne Stroustrup (Vater von C++).
Rolf
Hallo Rolf,
Was davon nicht abgedeckt wird, ist die Bedeutung des Strings oder des Integers in einer Variablen. Ist es ein Zähler, ein Index, ein Name, ein Key, ein DB-Handle, eine File-Ressource? Das war das Problem, das Simonyi lösen wollte.
genau das habe ich ja auch schon empfohlen. Mehrmals in den letzten Jahren.
Ich wusste nur nicht, wo die Idee ursprünglich herkam.
Einen schönen Tag noch
Martin
Du glaubst wirklich, dass ich meine Variablen $arArray oder $a, $b, $c nenne? 👍😂🤣 Danke für den Lacher.
Ich vereinfache den Code immer so gut ich kann, damit man sich auf das Problem konzentrieren kann und nicht auf das drumherum.
Um dein Beispiel auf zu greifen finde ich $arWords sehr schön. Man sieht sofort, dass es ein Array ist, welches anscheinend Wörter beinhaltet. Man weiß nicht welche Wörter. Eventuell kann man die Variable noch umbenennen, um auch gleich noch zu sehen welche Wörter, zumindest die Art z.B. $arSalutions oder $arVerstärkungsWörter 😁.
Was man aber sofort sieht ist der Datentyp. Ob das ein Interpreter oder Compiler sowieso schon weiß interessiert mich als Programmierer nicht bzw. gehe ich mal davon aus, dass beide einfach richtig funktionieren. Ich weiß jedoch als Programmierer sofort, dass dort ein Array drin ist (sofern der Name und die Zuweisung stimmen). Ergo kann ich mittels foreach darüber iterieren. Eine Programmlogik würde ich auf ein $ar im Variablennamen niemals aufbauen.
Was steht in $words? Ist es ein Array? Oder ein Objekthandler? Ein String? Datenbankhandler? Filehandler? Ich weiß es nicht. Meine IDE weiß es vielleicht. Moment lass mal kurz die Maus greifen und mit dem Mauszeiger über die Variable. Jap, ist ein Array. Hat jetzt locker 2 Sekunden gedauert und eine Menge Konzentration, den Mauszeiger genau über die Variable zu positionieren. So ist es zumindest im PHPStorm. Und der weiß auch nicht immer was in der Variable ist. Soweit ich weiß steigt er bei Singletons aus. Zu allem Überfluss muss ich mir jetzt auch noch merken das es ein Array ist, denn sonst kann ich in ein paar Minuten das gleiche Spiel wieder machen.
Und das nennt ihr jetzt effektive Entwicklung? $arWasAuchImmer und man sieht an zwei Buchstaben was Sache ist - einfach, effektiv, lesbar.
Benutze ich es falsch - ja! Mir sind nur die Grundlegenden Typen wichtig. Ist es eine Zahl, ein String, ein Objekt, Array, Funktion oder ein Filehandler. Ids kennzeichne ich auch noch extra. Das wars ... und es macht den Code so viel lesbarer!
Mir ist der Status eines Menschen völlig egal. Es geht um Argumente. Wenn der letzte pädophile Rechtsradikale mir etwas gutes beim Programmieren zeigt, dann nehme ich es dankend an. Und wenn "Koryphäen von irgendwas" keine Argumente haben, dann haben sie keine.
Gruß
Koryphäen T-Rex
Hallo T-Rex,
die Argumente der Koryphäen stehen im Wiki-Artikel. Wenn Du für Dich andere Schwerpunkte setzt, dann ist das Deine freie Entscheidung.
Der grundsätzlich ungetypte Charakter von PHP hat hier natürlich einen maßgeblichen Einfluss. Martin, Torvalds und Stroustrup haben eine andere "Muttersprache".
Rolf
Moin Rolf,
Der grundsätzlich ungetypte Charakter von PHP hat hier natürlich einen maßgeblichen Einfluss. Martin, Torvalds und Stroustrup haben eine andere "Muttersprache".
In Stroustrups „Muttersprache“ gibt es mittlerweile allerdings das Schlüsselwort auto, das es dem reinen Quellcode-Leser auch nicht gerade einfach macht …
Viele Grüße
Robert
Ich verstehe nicht was für eine Rolle eine typenstarke und typenlose Programmiersprache macht? Egal in welcher Programmiersprache man ist, es kann doch nur von Vorteil sein, dass man sofort sieht ob es ein Array oder ein Objekt (oder Sonstwas) ist, ohne das man es sich merken oder durch eine IDE herleiten muss.
Gruß
Verfasser
Hallo T-Rex,
du hast die Kritik-Sektion in der Wikipedia gelesen, die ich Dir verlinkt habe?
Rolf
du hast die Kritik-Sektion in der Wikipedia gelesen, die ich Dir verlinkt habe?
Klar, soll ich sie dir zerreißen und dir zeigen dass da keine Argumente stehen oder die Argumente haltlos sind?
Gruß
Kritiker T-Rex
Hallo T-Rex,
nicht nötig. Wenn Du die dort aufgeführten Probleme für Dich nicht als Problem siehst, brauchen wir das nicht zu diskutieren, das läuft dann nur auf ein "nein, doch, nein, doch" hinaus, bis irgendwer dann das "oh!" bringt. Lass uns uns darauf einigen, dass wir uneinig sind.
Rolf
@@T-Rex
Egal in welcher Programmiersprache man ist, es kann doch nur von Vorteil sein, dass man sofort sieht ob es ein Array oder ein Objekt (oder Sonstwas) ist, ohne das man es sich merken oder durch eine IDE herleiten muss.
Das sieht man doch am Variablenbezeichner:
Wenn nicht, ist der Variablenbezeichner möglicherweise schlecht gewählt.
🖖 Живіть довго і процвітайте
@@Gunnar Bittersmann
Wenn nicht, ist der Variablenbezeichner möglicherweise schlecht gewählt.
Ich schreibe in JavaScript üblicherweise nicht
Gunnar Bittersmannconst foo = document.querySelector('#foo');
const bar = document.querySelectorAll('.bar');
sondern
const fooElement = document.querySelector('#foo');
const barElements = document.querySelectorAll('.bar');
So erkennt man am Bezeichner, um was es sich handelt: ein Elementobjekt bzw. ein Array eine Liste von Elementobjekten.
🖖 Живіть довго і процвітайте
Hallo,
Egal in welcher Programmiersprache man ist, es kann doch nur von Vorteil sein, dass man sofort sieht ob es ein Array oder ein Objekt (oder Sonstwas) ist, ohne das man es sich merken oder durch eine IDE herleiten muss.
muss man das denn? Wichtig ist meines Erachtens, dass man den Verwendungszweck eines Bezeichners erkennt (Zähler, Index, Farbwert, Fehlercode, Fehlermeldung). Der Typ ergibt sich doch dann daraus.
Ansonsten schließe ich mich Gunnar an: Sinnvoll gewählte Bezeichner verraten schon von sich aus, was sie sind und wofür sie stehen.
Einen schönen Tag noch
Martin
Müssen? ist hier nicht die Frage! Es ist doch praktisch! Und bislang habe ich mein Lebenlang noch kein "echtes" Gegenargument gehört. Es kam immer nur ein "das ist doof", "Das macht man so nicht", "das ist doof, weil andere sagen dass es doof ist".
Ich hab mal ein echtes Beispiel aus dem Projekt mitgebracht an dem ich gerade arbeite. Der Variablenname ist nicht von mir: $securityCertificateLib. Ihr sagt beide (Du und Gunnar), dass man anhand des Namens erkennen kann/soll um was für einen Datentyp es sich handelt. Kann man das? Ich denke ja. Es wird ein Objekt sein (und da ich mehr vom Code sehe, es ist wirklich eins). Aber ... man muss die Variable lesen, sie verstehen (Sprache), sie verstehen (Sinn) und dann noch ableiten welcher Datentyp es ist.
Ich hätte sie $objSecurityCertificateLib genannt. Wenn man den Sinn verstehen möchte liest man alles. Will man nur den Datentyp wissen reichen 3 Buchstaben. Das ist doch wesentlich einfacher und ich weiß nicht wieso sich alle dagegen derart sträuben?
Gruß
$dinoTrex
Um genauer zu sein, wird gesagt das mein Variablenname $arArray sich nicht an die PSR 12 Vorgaben hält. Er soll $array heißen.
Naja. Aber das von Dir explizit genannte „$arArray“ ist, weil „doppelt gemoppelt“, ein Verstoß gegen „In der Kürze liegt die Würze!“ und damit schwerer lesebar als „$Array“ oder gar „$arr“.
Es ist doch praktisch!
Wie gezeigt: Längst nicht immer.
Und bislang habe ich mein Lebenlang noch kein "echtes" Gegenargument gehört. Es kam immer nur ein "das ist doof",
Selbst wenn es etwas wie „$arWords“ war, dann zeigt „$Words“ (also der Plural) allein schon an, dass es eine „geplante Mehrheit“ ist. Und es geht ja nicht um Python…
Hallo T-Rex,
Das ist doch wesentlich einfacher und ich weiß nicht wieso sich alle dagegen derart sträuben?
Dazu fällt mir der Kommentar eines Autofahrers ein, als im Verkehrsfunk die Falschfahrerwarnung kam: „Ein Geisterfahrer? HUNDERTE!“
Wenn man der einzige ist, der eine Meinung vertritt, ist man entweder das einsame Genie - oder im Irrtum.
Rolf
Ich bin mein Leben lang mit diesem "Witz" konfrontiert. Dem entgegen kann ich diesen einen Moment in der Geschichte halten, wo "alle" in einem Zirkuszelt jubelten, weil es endlich den absoluten Krieg gab.
Ist es also richtig immer das zu machen was alle machen? Ist das Argument, jeder macht es, also mache ich es auch, so stichhaltig, damit man es auch macht. Was ist mit dem Ersten der diesen "Trend" ausgelöst hat? Der konnte niemandem folgen. Ist er dann der Irre Geisterfahrer oder das einsame Genie?
Eins wird sich bei mir niemals ändern. Ich werde immer logischen Argumenten folgen. Und wenn ich für alle der einsame irre Geisterfahrer bin, dann ist das so.
Ein schönes Zitat möchte ich noch unterbringen, auch wenn es hier nicht zu 100% passt: "Wenn alle an eine Lüge glauben, dann ist der, der die Wahrheit spricht zwangsläufig ein Lügner."
Gruß
Geisterfahrer Genie
T-Rex
Ich werde immer logischen Argumenten folgen.
„Logik“ funktioniert aber nur im Zusammenhang mit Tatsachenwahrnehmung. Die Absence einer Reaktion auf mein „Geschreibsel“ bei gleichzeitigem Vortrag irgendwelcher unkonkreten Allgemeinbetrachtungen lässt es zu, einen „passt nicht zu meinen fixen Vorstellungen - Filter“ zu vermuten.
Hallo Raketenwilli,
sei es wie es will - wir sind uns alle einig, dass wir uneinig sind und sollten das Thema ruhen lassen.
Rolf
Das ich meine Variablen nicht $arArray nenne und das nur eine Vereinfachung ist, wurde schon längst geschrieben.
Ich mach dir keinen Vorwurf, wenn du es überlesen hast. Aber bitte greif mich nicht persönlich an, wenn ich schlicht keine Lust hab ständig darauf ein zu gehen.
Aber wenn wir schon dabei sind ...
Der Fakt, dass du auf einen Kommentar geantwortet hast, in dem ich ein besseres Beispiel gebracht habe, als das von dir aus dem Threabaum gezogenem veralteten Beispiel, beweist Eindrucks voll, dass du den von dir angebrachten Tatsachenbestand selbst ignorieren möchtest, was dein Vorwurf auf dich selbst zurückwirft.
Oder um es mit anderen Worten zu sagen: "Wer ohne Sünde ist werfe den ersten Stein".
... fertig.
Jetzt brauchen wir einen objektiven Richter, der entscheidet wesen Penis länger ist. Ach da fällt mir was ein..
Gruß
vom 6 Meter großem Dino 🤣😂
Das ich meine Variablen nicht $arArray nenne und das nur eine Vereinfachung ist, wurde schon längst geschrieben.
Dort fand ich vor allem:
Mir ist der Status eines Menschen völlig egal. Es geht um Argumente. Wenn der letzte pädophile Rechtsradikale
Kleiner Hinweis: Hiervon ist nur das „letzte“ ein Status. Das andere („pädophile Rechtsradikale“ ist a) eine Beschreibung einer Krankheit (F65.4, gemäß ICD-10-GM-2022) und b) einer höchst bemerkenswerten Dummheit, verbunden mit einer erheblichen sozialen Fehlleitung, regelmäßig beruhend auf Minderwertigkeitskomplexen welche mehrheitlich auf kränkenden Ablehnungserfahrungen beruhen.
Von solchen willst Du also was lernen?
Dort fand ich auch:
Du glaubst wirklich, dass ich meine Variablen $arArray oder $a, $b, $c nenne? 👍😂🤣 Danke für den Lacher.
Oha. Also ich nenne Variablen - mit guter Begründung - durchaus [$]c, [$]i, [$]k, [$]l, [$]m. Zum anderen war es Deine Beschreibung. Untersuche, warum zahlreiche Leser annehmen, das Du mit „$arArray“ tatsächlich „$arArray“ meinst. Vielleicht haben die zu viel von Deinem sonstigen Sermon gelesen, in welchem Du die tatsächlichen Informationen sorgfältig versteckst.
Moin T-Rex,
Und bislang habe ich mein Lebenlang noch kein "echtes" Gegenargument gehört.
Im von Rolf verlinkten Wikipedia-Artikel zur Ungarischen Notation wird ein valides Gegenargument genannt: Wenn sich der Datentyp ändert, müsste man konsequenterweise auch überall den Bezeichner-Namen ändern – unabhängig davon, ob sonst im Code irgend eine Änderung nötig wäre (z.B. weil die APIs kompatibel zueinander sind).
Ich hab mal ein echtes Beispiel aus dem Projekt mitgebracht an dem ich gerade arbeite. Der Variablenname ist nicht von mir: $securityCertificateLib. Ihr sagt beide (Du und Gunnar), dass man anhand des Namens erkennen kann/soll um was für einen Datentyp es sich handelt. Kann man das? Ich denke ja. Es wird ein Objekt sein (und da ich mehr vom Code sehe, es ist wirklich eins). Aber ... man muss die Variable lesen, sie verstehen (Sprache), sie verstehen (Sinn) und dann noch ableiten welcher Datentyp es ist.
Sprache zu verstehen ist generell nie verkehrt und daraus ergibt sich, dass es sehr wahrscheinlich ein Objekt ist.
(Das ist übrigens der Vorteil komplett objekt-orientierter Sprachen: alles sind Objekte 😀)
Wenn man den Sinn verstehen möchte liest man alles. Will man nur den Datentyp wissen reichen 3 Buchstaben.
Wieso sollte man nur den Datentyp, aber nicht die Bedeutung einer Variablen wissen wollen?
Viele Grüße
Robert
Moin Robert,
ein valides Gegenargument genannt: Wenn sich der Datentyp ändert, müsste man konsequenterweise auch überall den Bezeichner-Namen ändern
Absolut! Denkt man an der Stelle nicht weiter ist es ein Gegenargument! Aber jetzt denken wir mal weiter. Anstatt ein Array zurück zu geben, geben wir ein Objekt zurück. In meiner Welt muss aus einem $arBezeichnungs ein $objBezeichnung werden. In der Welt von Gunnar (und vielen anderen) muss aber AUCH aus einem $bezeichnungs ein $bezeichnung werden. Das S fällt weg. Somit müssen BEIDE Welten etwas am Bezeichner verändern. Somit kann man nicht sagen "das eine oder das andere ist besser". In einer Welt wo man seine Variablen durch nummeriert würde dieser Nachteil nicht auftreten $a1, $a2. (bin mal gespannt ob das jetzt jemand als Tipp versteht und dagegen argumentiert 🤣😂)
Hinzu kommt, dass man den Code ändern muss (sowohl in meiner als auch in allen anderen Welten). Funktioniert ein foreach noch? Oder wurde von einem Objekt auf ein Array geändert? Dann wurden vielleicht vorher Methoden aufgerufen? Oder ist es jetzt ein String und so weiter...
Objektorientierung heißt ja nicht umsonst auch "geschlossen für Veränderung". Wenn man etwas anderes zurück gibt als vorher erwartet wurde, hat man bei weitem andere Probleme als eine Datentypabkürzung. Und wenn man den Code an der Stelle sowieso schon umbauen muss, na dann kann man auch den Variablennamen anpassen...
Wenn man eine IDE als Grund anführt den Datentyp nicht anzugeben, da die IDE den Datentyp schon weißt, dann ist es nur legitim zu sagen, dass man über besagte IDE auch die Variablennamen ändern kann. Bei Phpstorm geht das mittels "Umschalt+f6". Dann werden alle gleichen Variablennamen im selben Kontext geändert. Ist kein Aufwand mehr. Brauche ich persönlich aber selten.
Wieso sollte man nur den Datentyp, aber nicht die Bedeutung einer Variablen wissen wollen?
Das eine schließt das andere nicht aus. Die Bedeutung ist doch wunderbar und ich hab nirgends geschrieben, dass man auf sie verzichten sollte.
Grüße zurück
Weltenbummler T-Rex
Moin T-Rex,
Absolut! Denkt man an der Stelle nicht weiter ist es ein Gegenargument!
Es kommt wohl darauf an, in welche Richtung man weiterdenkt … 😉
Aber jetzt denken wir mal weiter. Anstatt ein Array zurück zu geben, geben wir ein Objekt zurück.
Ich werde mal konkret: Anstatt ein Array zurückzugeben, gebe ich eine Liste/einen Vektor/… jedenfalls ein Objekt mit Listensemantik zurück.
In meiner Welt muss aus einem $arBezeichnungs ein $objBezeichnung werden. In der Welt von Gunnar (und vielen anderen) muss aber AUCH aus einem $bezeichnungs ein $bezeichnung werden.
In meinem Beispiel änderte sich auch nichts an der Bezeichnung des Inhaltstyps, d.h. der Name bliebe gleich.
Somit müssen BEIDE Welten etwas am Bezeichner verändern.
Nicht zwingend.
Hinzu kommt, dass man den Code ändern muss (sowohl in meiner als auch in allen anderen Welten).
Das kommt auf die API-Kompatibilität an:
Funktioniert ein foreach noch?
In meinem Beispiel: ja.
Oder wurde von einem Objekt auf ein Array geändert? Dann wurden vielleicht vorher Methoden aufgerufen? Oder ist es jetzt ein String und so weiter...
Oder ist ein String ein Array von Zeichen?
Objektorientierung heißt ja nicht umsonst auch "geschlossen für Veränderung".
Nicht geschlossen, sondern gekapselt für kontrollierten Zugriff. Objektorientierung heißt auch APIs und im Idealfall stabile und kompatible APIs.
Wenn man etwas anderes zurück gibt als vorher erwartet wurde, hat man bei weitem andere Probleme als eine Datentypabkürzung.
In einer typisierten Programmiersprache kann das nicht passieren. In allen andern muss man sich sicher sein oder prüfen – unabhängig vom Variablennamen!
Und wenn man den Code an der Stelle sowieso schon umbauen muss, na dann kann man auch den Variablennamen anpassen...
Oder man muss nur an einer Stelle den Typ ändern und der Rest bleibt gleich …
Viele Grüße
Robert
Aber die Betriebssystemabteilung von Microsoft sah das anders, sie waren vermutlich noch zu assemblerlastig und heilfroh, eine minimale Typisierung einführen zu können. Und so bekamen wir Namen wie hFile (was ok ist), aber dann auch dwCounter (dw = double word, ein 32-bit Wert) - und das ist in einer Hochsprache genauso sinnlos wie $arWords.
Bekannte Ausnahme: Python
Inhaltlich sind die erst einmal kaum zu unterscheiden, haben dann aber andere Eigenschaften hinsichtlich der vorhandenen/erlaubten Methoden, was in der Hochsprache Python eine solche Benennung vorteilhaft erscheinen lässt.
Man versuche:
import sys
x = [ 1, 2, 3 ]
print( sys.getsizeof( x ), "Bytes" ) #88 Bytes
x.append( 4 )
vers.
import sys
y = ( 1, 2, 3 )
print( sys.getsizeof( y ) , "Bytes") #64 Bytes
y.append( 4 ) #AttributeError: 'tuple' object has no attribute 'append'
vers.
import sys
z = range( 1, 4 )
print( sys.getsizeof( z ) , "Bytes") #48 Bytes
z.append( 4 ) #AttributeError: 'range' object has no attribute 'append'
Andererseits sollte man das beim Programmieren seines Zeugs durchaus im Kopf behalten können und einige Sachen, wie z.B. der range, haben regelmäßig ein eher begrenztes Auftreten im Rahmen einer geringen Anzahl von Iterationen über denselben.
Hint: Die Ausgabe des reservierten Speichers zeigt warum das gemacht wird. Auch die jeweilige An- oder Abwesenheit von Methoden hat Auswirkungen auf die Laufzeit.