Wer sagt, dass Textdateien unbedingt auf der Festplatte liegen müssen?Zitat von Cherry
Nur 10x pro Sekunde? Fail, zu langsam für anspruchsvolle Sachen. 1000x pro Sekunde? Fail, zu viele unnötige Festplattenzugriffe, außerdem kann man ja nicht gleichzeitig auf eine derartige Datei zugreifen.
Eine RAM-Disk würde auch gute Dienste machen
Kann Windows sowas überhaupt?Wer sagt, dass Textdateien unbedingt auf der Festplatte liegen müssen?
Eine RAM-Disk würde auch gute Dienste machen
--
Nicht von Haus aus, aber es gibt diverse Software dafür.
Konvertierung von Datentypen, ach ja ... ich kann mich in C noch an die Funktion atoi erinnern, ein Beispiel wie man Funktionen nicht benennen sollte.
--
Ich bin eine Säbelzahnkatze *miau*
Wie würdest du es benennen? Soll übrigens für "ASCII to Integer" stehen, soweit ich weiß.
int convertAsciiToInt ( const char * ascii);
oder
int asciiToInt ( const char * ascii);
Beschreibende Methodennamen sind da in meinen Augen am besten. Sind zwar mehr zu tippen, aber wozu gibt es heutzutage die Auto-Vervollständigung.
Damals war es ja mehr der gute Ton alles kurz zu machen, als es leicht lesbar zu machen.
--
atoi ist aber beschreibend (und in meinen Augen auch leicht lesbar). Der einzige Unterschied zwischen atoi und AsciiToInt ist doch der, dass in atoi "Ascii" und "Int" abgekürzt sind. Das Problem mit atoi ist wohl eher, dass heute nicht jedem sofort klar ist, wofür das "a" steht (mir war es anfangs auch nicht klar). Ich schätze, dass der Term "ASCII" zur Blütezeit von C sehr viel präsenter war und es machte Sinn ihn durch "a" abzukürzen. Heute sieht es allerdings nicht sehr viel anders aus: Wenn der Name einer Funktion sinnvoll abgekürzt werden kann und es bei der abgekürzten Version immernoch klar ist, was die Funktion macht, wird der Name abgekürzt. Und das ist absolut in Ordnung. Selbst eine derart ausführliche Sprache wie Java hat in ihrem Repertoire Funktionen mit abgekürzten Namen, wie etwa die mathematischen Funktionen, weil es erstens Sinn macht solch elementaren Funktionen kurze Namen zu geben und zweitens, weil die Abkürzung immernoch Sinn ergibt und es klar ist, was die Funktion macht. Krampfhafte Ausführlichkeit ist meiner Meinung nach genauso schädlich (selbst heute, mit automatischer Vervollständigung), wie kryptische Abkürzungen. Es muss abgewogen werden und abgewogen hast du ja auch, oder weshalb ist deine Wahl auf "AsciiToInt" und nicht etwa auf "ConvertAsciiEncodedCStringToIntegerAndReturnTheResult" gefallen?
Weil es einen Unterschied gibt zwischen "verbose" Namen und einfach beschreibenden Namen. Aber nein, schon klar darauf willst du nicht hinaus.
Wie du selbst sagst muss man wissen was das "a" und das "i" zu bedeuten hat. Dann erst mach auch das "to" im Methodennamen Sinn.
Das Ganze mit den Methoden von java.lang.Math zu vergleichen finde ich nicht ganz so passend.
Immerhin hast du hier mathematische Ausdrücke die damit quasi von der fachlichen Seite vorgegeben sind.
Meine Wahl ist von daher eher auf asciiToInt gefallen.
Ich finde hier sieht man von vornherein was die Methode tun wird. Hierfür ist auch kein Wissen nötig was irgendein Abkürzung nun genau bedeutet.
Sicherlich gäbe es hier noch passendere Name.
Man könnte sich z.B. sparen was überhaupt zurück gegeben wird, da man dies idR auch anderweitig sehen kann.
--
Gutes Argument, daran habe ich nicht gedacht. Ich habe zu wenig Erfahrung mit Javas Bibliotheken um passendere Beispiele nennen zu können (falls es welche gibt) und Lust darauf noch weniger.
"ascii" und "Int" sind aber auch Abkürzungen. Aber ich schätze, dir geht es mehr darum, dass das "to" hervorgehoben ist.
Aber es sind (im Kontext der Softwareentwicklung) eindeutige Abkürzungen. atoi könnte dagegen zum Beispiel auch "all to int" oder sonst was stehen.
--
"all to int" macht - zumindest für mich - keinen Sinn, vor allem weil es itoa gibt. Mir fällt jetzt auf Anhieb auch nichts ein, was sonst (außer "ASCII") für das "a" in atoi stehen könnte und Sinn machen würde. Hand aufs Herz, es ist doch nicht so, dass man die benötigte Information alleine aus dem Funktionsnamen entschlüsseln muss. In der Praxis schaut man sich doch immer die Dokumentation, oder zumindest die Deklaration an. Selbst bei AsciiToInt ist nicht alles sofort klar und man muss die Deklaration heranziehen. Darüber hinaus handelt es sich nicht um irgendeine Funktion aus der Bibliothek eines Drittanbieters, sondern um eine Funktion aus der Standardbibliothek von C, die im Header stdlib.h definiert und unter "String conversion" aufgelistet ist (zumindest auf cplusplus.com).
Zugegeben, das "a" in atoi könnte für jemanden, der den Funktionsnamen zum ersten mal liest, schwierig zu entziffern sein (wie gesagt, ich wusste anfangs auch nicht, dass es für ASCII steht). Aber das alleine reicht für mich nicht aus um den Funktionsnamen als "ein Beispiel wie man Funktionen nicht benennen sollte" zu betiteln, in Anbetracht dessen, dass - wie ich meine - der Term ASCII früher deutlich präsenter war und damit auch klar war, was mit dem "a" gemeint ist, sowie in Anbetracht der Punkte, die ich oben genannt habe und vielleicht noch aus Respekt gegenüber den Autoren der C-Standardbibliothek.
Geändert von Kyuu (11.09.2012 um 11:32 Uhr)
Das "a" könnte aber auch Array heißen, da hier ein Char-Array in die Funktion reingereicht wird. Ein String ist ja in C nichts weiter, als ein Char-Array.
Ein C-String ist ein nullterminiertes Char-Array. Aber es würde mich jetzt, ehrlich gesagt, überraschen, wenn das "a" tatsächlich für "Array" stehen würde, denn der zugrundeliegende Datentyp, bzw. hier die Codierung der Zeichen ist entscheidender als die Datenstruktur.
Berechtigungen
Zitieren
