> http://heise.de/-1245697
Da sind ja einige, kl. Fehler im Artikel.
a) Unter Unix untersucht type auch, ob ein Kommando ein Builtin ist,
'which' wäre vielleicht passender.
> type echo
> echo is a shell builtin
b) Anfangs ist von jType.java die Rede. Der Dateiname muss natürlich
JType.java lauten, zumindest auf ernsthaften Betriebssystemen. Da
Windows solche Dateinamen nicht verbietet sollte man, gerade in einem
Javaartikel - die platformneutrale Möglichkeit ergreifen.
c) System.exit(0);
sollte man überhaupt keinem Anfänger oder Umsteiger empfehlen.
System.exit beendet nicht nur das Programm, sondern die ganze JVM,
also sowohl Programme, die man aus diesem Programm heraus gestartet
hat (wenn das überhaupt möglich ist), als auch ein Programm, von dem
heraus man dieses gestartet haben könnte. Mit System.exit macht man
die Verwendung aus solche einem Programm heraus also vorläufig
unmöglich.
d) Der catch-all-Block ist überflüssig, weil ungefangene Ausnahmen eh
das Programm unter Ausgabe des Stacktraces terminieren. Womöglich
will der Autor zur Verteidigung vorbringen, dass er nur etwas
veranschaulichen will, aber hier wird der allgemeinste Typ von
Exception gefangen, was man auch nicht empfehlen kann - man kann
einem Anfänger nicht zeigen, wie man's richtig macht, in dem man
zeigt, wie man's falsch macht. Ein Dilemma, wenn man kurz und einfach
bleiben will, aber dafür ist man ja auch Profi, und nicht ein
selbsternannter Experte von der Straße.
e) Ein Konstruktor ist keine spezielle Methode. Er mag ähnlich
aussehen, aber einige Gründe, wieso er das nicht ist, nennt der
Redakteur selbst. Weitere Punkte: mit Reflektion findet man den
Konstruktor nicht unter der Methoden, man kann für eine erzeugte
Referenz nicht den Konstruktor erneut aufrufen, man muss ihn mit 'new
' ansprechen - das wären 3 weitere.
f) "In dem Fall wird eine Fehlerbedingung (eine Exception mit der
entsprechenden Meldung erzeugt," - eine Fehlerbedingung?
Alle mir bekannten Bedeutungen des Begriffs 'Bedingung' bedeuten,
dass erst die Umstände existieren, die einen Fehler verursachen.
Darauf reagiert das Programm mit einem Fehlerobjekt, bzw.
Ausnahmeobjekt. Aber nicht mit der Bedingung.
g) Präfixe wie bei sPathSep oder bLong sind bei statisch typisierten
Sprachen wie C und Java wirklich überflüssig. Was ist 's' - String,
Stack, Sound? bLong ist ein Boolean? Ich hätte gedacht ein Byte oder
eine BufferedExceptionFactoryImplementation. Moderne IDEs können
einem in kleinen Assistenzfensterchen zeigen, welchen Typs die
Variablen sind, und Tooltiptexte sind eine weitere Möglichkeit der
IDE, zu verraten, worum es sich handelt. Buchstaben sind dagegen sehr
limitiert und in anderer Hinsicht ein Ärgernis: Sie sorgen dafür,
dass die alphabetische Sortierung zugleich eine nach Typ ist,
schränken also die Möglichkeiten ein, und sind ein ergonomisches
Hindernis beim Erfassen des hoffentlich bedeutungsvollen Namens. In
Ausnahmefällen kann es gar sinnentstellend sein: idifferent sieht
viel mehr nach indifferent aus, als nach different. Außerdem ist der
Typ ein Implementierungsdetail, und wird nicht von gängigen Tools auf
Korrektheit geprüft. Zusammen mit Präfixen für
private/public/protected (p? pupopi? uoi?), für volatile, für static
und _member, sowie iIprefix für 'implements interface' und nach
Möglichkeit noch, ob mbn (may be null) und te (throws Exception) hat
man rasch eine Sprache in der Sprache, und mit Firmenrichtlinien, in
welcher Reihenfolge dieser Zinnober zu ordnen ist, und bevor man die
erste Variable richtig deklariert hat, ist schon Mittagspause. (final
vergessen).
h) if (sPathName==null || sPathName.isEmpty())
throw new Exception ("FATAL: Path variable is empty!");
Oder null. :)
i) Ein Zip packt man so, dass es ein Ordner ist, in dem dann alles
drin ist, so dass der Auspacker nicht verstreut zwischen eigenen
Dateien das Zeuch des Packers findet. Hier nur 3 Files, aber so
fängt's an! :)
// Aus dem Quellcode, nicht dem Artikel:
j) Was haben wir hier für eine gymnastische Übung vor uns, welchen
Boilerplatestunt?
final static String sAppName = JType.class.getSimpleName ();
Wenn rechts des Zuweisungsoperators eh "JType" steht, dann kann man
schlecht behaupten, dass diese Technik eine Umbenennung der Klasse
überstehen würde. Und benutzt wird es unten in der Usagemethode:
System.err.println ("usage: JType name ...");
täte es dort auch, aber man würde natürlich erwarten, dass da 2 Worte
zu -A -L -V verloren werden.
k) Der Konstruktor ist zu lang, er macht fast alle Arbeit alleine. Er
sollte kürzere Methoden aufrufen, und diese sollten so benannt sein,
dass man sieht, wie die Gesamtaufgabe in kl. Teilaufgaben zerfällt.
Nicht wirklich l) :) sPrintDottedNumber - da kommt der
C-Programmierer heraus (wie bei den vielen printf-Statements). Aber
gut - why not? NumberFormat wäre idiomatischer.
Da sind ja einige, kl. Fehler im Artikel.
a) Unter Unix untersucht type auch, ob ein Kommando ein Builtin ist,
'which' wäre vielleicht passender.
> type echo
> echo is a shell builtin
b) Anfangs ist von jType.java die Rede. Der Dateiname muss natürlich
JType.java lauten, zumindest auf ernsthaften Betriebssystemen. Da
Windows solche Dateinamen nicht verbietet sollte man, gerade in einem
Javaartikel - die platformneutrale Möglichkeit ergreifen.
c) System.exit(0);
sollte man überhaupt keinem Anfänger oder Umsteiger empfehlen.
System.exit beendet nicht nur das Programm, sondern die ganze JVM,
also sowohl Programme, die man aus diesem Programm heraus gestartet
hat (wenn das überhaupt möglich ist), als auch ein Programm, von dem
heraus man dieses gestartet haben könnte. Mit System.exit macht man
die Verwendung aus solche einem Programm heraus also vorläufig
unmöglich.
d) Der catch-all-Block ist überflüssig, weil ungefangene Ausnahmen eh
das Programm unter Ausgabe des Stacktraces terminieren. Womöglich
will der Autor zur Verteidigung vorbringen, dass er nur etwas
veranschaulichen will, aber hier wird der allgemeinste Typ von
Exception gefangen, was man auch nicht empfehlen kann - man kann
einem Anfänger nicht zeigen, wie man's richtig macht, in dem man
zeigt, wie man's falsch macht. Ein Dilemma, wenn man kurz und einfach
bleiben will, aber dafür ist man ja auch Profi, und nicht ein
selbsternannter Experte von der Straße.
e) Ein Konstruktor ist keine spezielle Methode. Er mag ähnlich
aussehen, aber einige Gründe, wieso er das nicht ist, nennt der
Redakteur selbst. Weitere Punkte: mit Reflektion findet man den
Konstruktor nicht unter der Methoden, man kann für eine erzeugte
Referenz nicht den Konstruktor erneut aufrufen, man muss ihn mit 'new
' ansprechen - das wären 3 weitere.
f) "In dem Fall wird eine Fehlerbedingung (eine Exception mit der
entsprechenden Meldung erzeugt," - eine Fehlerbedingung?
Alle mir bekannten Bedeutungen des Begriffs 'Bedingung' bedeuten,
dass erst die Umstände existieren, die einen Fehler verursachen.
Darauf reagiert das Programm mit einem Fehlerobjekt, bzw.
Ausnahmeobjekt. Aber nicht mit der Bedingung.
g) Präfixe wie bei sPathSep oder bLong sind bei statisch typisierten
Sprachen wie C und Java wirklich überflüssig. Was ist 's' - String,
Stack, Sound? bLong ist ein Boolean? Ich hätte gedacht ein Byte oder
eine BufferedExceptionFactoryImplementation. Moderne IDEs können
einem in kleinen Assistenzfensterchen zeigen, welchen Typs die
Variablen sind, und Tooltiptexte sind eine weitere Möglichkeit der
IDE, zu verraten, worum es sich handelt. Buchstaben sind dagegen sehr
limitiert und in anderer Hinsicht ein Ärgernis: Sie sorgen dafür,
dass die alphabetische Sortierung zugleich eine nach Typ ist,
schränken also die Möglichkeiten ein, und sind ein ergonomisches
Hindernis beim Erfassen des hoffentlich bedeutungsvollen Namens. In
Ausnahmefällen kann es gar sinnentstellend sein: idifferent sieht
viel mehr nach indifferent aus, als nach different. Außerdem ist der
Typ ein Implementierungsdetail, und wird nicht von gängigen Tools auf
Korrektheit geprüft. Zusammen mit Präfixen für
private/public/protected (p? pupopi? uoi?), für volatile, für static
und _member, sowie iIprefix für 'implements interface' und nach
Möglichkeit noch, ob mbn (may be null) und te (throws Exception) hat
man rasch eine Sprache in der Sprache, und mit Firmenrichtlinien, in
welcher Reihenfolge dieser Zinnober zu ordnen ist, und bevor man die
erste Variable richtig deklariert hat, ist schon Mittagspause. (final
vergessen).
h) if (sPathName==null || sPathName.isEmpty())
throw new Exception ("FATAL: Path variable is empty!");
Oder null. :)
i) Ein Zip packt man so, dass es ein Ordner ist, in dem dann alles
drin ist, so dass der Auspacker nicht verstreut zwischen eigenen
Dateien das Zeuch des Packers findet. Hier nur 3 Files, aber so
fängt's an! :)
// Aus dem Quellcode, nicht dem Artikel:
j) Was haben wir hier für eine gymnastische Übung vor uns, welchen
Boilerplatestunt?
final static String sAppName = JType.class.getSimpleName ();
Wenn rechts des Zuweisungsoperators eh "JType" steht, dann kann man
schlecht behaupten, dass diese Technik eine Umbenennung der Klasse
überstehen würde. Und benutzt wird es unten in der Usagemethode:
System.err.println ("usage: JType name ...");
täte es dort auch, aber man würde natürlich erwarten, dass da 2 Worte
zu -A -L -V verloren werden.
k) Der Konstruktor ist zu lang, er macht fast alle Arbeit alleine. Er
sollte kürzere Methoden aufrufen, und diese sollten so benannt sein,
dass man sieht, wie die Gesamtaufgabe in kl. Teilaufgaben zerfällt.
Nicht wirklich l) :) sPrintDottedNumber - da kommt der
C-Programmierer heraus (wie bei den vielen printf-Statements). Aber
gut - why not? NumberFormat wäre idiomatischer.