methoden einzeln importieren oder * nehmen?

[NDEBUG]

Hallo, typische Anfängerfrage ... wenn ich z.B. folgende imports im Quelltext habe

//============================================================================
//   IMPLEMENTATION REQUIRED IMPORTS
//============================================================================
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.ParserConfigurationException;

macht es dann sinn einfach

//============================================================================
//   IMPLEMENTATION REQUIRED IMPORTS
//============================================================================
import javax.xml.parsers.*

zu schreiben?

Also krieg ich durch das Sternchen unnötigen overhead rein, den man vermeiden sollte oder ist das reine Geschmackssache?

 

[Noctarius]

Nein bekommst durch das * keinen unnötigen Overhead, da der Compiler trotzdem nur die Klassen im Bytecode verewigt die auch wirklich gebraucht werden.

Mein Codeformatter ist so eingestellt, dass sobald mehr als 5 Klassen eines Packages genutzt werden, automatisch der Asterisk (*) benutzt wird.

 

[Wildcard]

Im Bytecode gibt es gar keine imports mehr, demzufolge ist das völlig egal. Der Nachteil des '*' ist lediglich, das man an den import statements nicht mehr sofort ablesen kann was wirklich verwendet wird.

 

[Noctarius]

Im Bytecode gibt es gar keine imports mehr...

Das kann ich so nicht stehen lassen 😀 Die "Imports" stehen sehr wohl im Bytecode und zwar als Canonicalname der Klasse damit der JVM Linker Weiß was er tun soll 😀 Nur als Importanweisung existieren sie nicht mehr. Deine Aussage ist daher ein klein wenig irreführend *mal klugscheiß* 😀

 

[Wildcard]

Was war daran nun irreführend? Es gibt keine Imports mehr, nur FQNs. ???:L

 

[NDEBUG]

Danke für die prompte Antwort...

 

[musiKk]

Ich kriege jedes Mal Hass, wenn ich online irgendwo Quelltext sehe und eine mir unbekannte Klasse nicht in den Imports steht, sondern von irgendeinem * erschlagen wird, ergo bin ich fürs explizite Importieren (btw von Klassen, nicht Methoden).

Immerhin kann ich mich ja freuen, dass der Platzhalter nur für Klassen und nicht Pakete gilt, sonst würden viele wahrscheinlich nur noch [c]import org.*; import java.*;[/c] etc. schreiben...

 

[Noctarius]

@musiKk:

import java.**

*duck* ;-)

 

[musiKk]

Da haste mir aber nen Schrecken eingejagt. 😉

 

[Noctarius]

Was war daran nun irreführend? Es gibt keine Imports mehr, nur FQNs. ???:L

Ja für jemanden der tiefer in Java hängt ist der Unterschied klar aber für jemand anderes klingt es so als ob die "importierten" Klassen an die Stelle des Imports gestopft werden (gelinked). Daher wollte ich nur klarstellen, dass die Imports schon noch da sind, nur in etwas anderer Form.

 

[Wildcard]

Sehe ich anders. Ein Import hat keinerlei semantische Bedeutung, ist nur eine Kurzschreibweise daher kann man IMO auch nicht sagen das im Bytecode imports in anderer Form vorliegen.

 

[bygones]

Ich kriege jedes Mal Hass, wenn ich online irgendwo Quelltext sehe und eine mir unbekannte Klasse nicht in den Imports steht, sondern von irgendeinem * erschlagen wird, ergo bin ich fürs explizite Importieren (btw von Klassen, nicht Methoden).

ich bekomm jedesmal Hass wenn ich eine Klasse anschauen will und erstmal bis zeile 100 scrollen muss weil jedes import extra aufgefuehrt wird ;-)

 

[musiKk]

Das ists mir voll wert.
Und: Das Scrollen dauert keine Sekunde, das Durchsuchen der verschiedenen Namespaces mit den Wildcards länger.

 

[schalentier]

ich bekomm jedesmal Hass wenn ich eine Klasse anschauen will und erstmal bis zeile 100 scrollen muss weil jedes import extra aufgefuehrt wird ;-)

Ich denke, dass ist ein eindeutiges Zeichen, dass an der Klasse irgendwas falsch ist. 100 Zeilen Imports bedeuten, dass die Klasse von 100 anderen Klassen abhaengt. Versteckt man diese Tatsache mit einem *-Import hat man nichts gewonnen. Also besser gar nicht verwenden und Klassen mit zu vielen Imports mal aufraeumen.

 

[bygones]

Also besser gar nicht verwenden und Klassen mit zu vielen Imports mal aufraeumen.

das natuerlich ....

Das ists mir voll wert.
Und: Das Scrollen dauert keine Sekunde, das Durchsuchen der verschiedenen Namespaces mit den Wildcards länger.

was weiss ich - 90% der imports kommen aus bekannten Java libs ... da reicht mir dann java.util.* zu sehen und nicht jede einzelne auffuehrung.
und wenn bei dir das scrollen weniger als 1 Sek dauert heisst das du schaust so und so nicht auf die imports... dann kann man sie ja auch "verkuerzen"

Fuer die wenigen Imports die unbekannt sind kann ich dann auch F3 auf der Klasse / Methode in Eclipse nutzen.

Ganz generell... wenn ich eine fremde Klasse betrachte will ich schnell und einfach sehen was diese Klasse macht, d.h. ich will unnoetige Codeaufblaehungen nicht haben (zb ausfuehrliche imports), ebenso wie ich will dass public methoden nach oben kommen und privates nach unten (und v.a. gemischt) etc etc etc

 

[FatFire]

wenn ich eine fremde Klasse betrachte will ich schnell und einfach sehen was diese Klasse macht, d.h. ich will unnoetige Codeaufblaehungen nicht haben (zb ausfuehrliche imports)

Also ich definiere unnötige Codeaufblähungen anders. Unnötige Codeaufblähungen ist für mich z.B. einen Taschenrechner zu schreiben und jede Taste einzeln mit bt1, bt2, bt3...zu deklarieren anstatt Arrays zu benutzen. Wenn man ausführliche Imports als Codeaufblähung ansieht, sind Kommentare wohl auch überflüssig und Autoren- sowie Copyrightinfos gehen wohl mal gar nicht?!?

Gruß FatFire

 

[bygones]

Wenn man ausführliche Imports als Codeaufblähung ansieht, sind Kommentare wohl auch überflüssig und Autoren- sowie Copyrightinfos gehen wohl mal gar nicht?!?

Autoren und Copyrightinfos stoeren nicht...

und wegen kommentaren poste ich mal wieder mein Lieblingsbuchzitat:

Sometimes you see comments that are nothing but noise. The restate the obvious and provide no new information.
[Java]
/**
* Default constructor
*/
public MyClass() {
}
[/Java]
no, really ? Or how about this:

/** The day of the month */
private int dayOfMonth

And then there is this paragon of redundancy

/**
 * Returns the day of the month
 * 
 * @return the day of the month
 */
 public int getDayOfMonth() {
    return dayOfMonth
 }

Zitat aus Clean Code - Robert C. Martin

und ja das find ich unnoetig und schrecklich... die API gehoert kommentiert, jedoch ist es ein Indiz je mehr Kommentare eine Methode braucht (sowohl als javadoc als auch als interne kommentare), dass die Methode schon fuer den Autor ist unverstaendlich und ueberarbeitet werden sollte.

aber das fuehrt wahr. zu sehr vom eigentlich thema ab !

 

[FatFire]

Na, mit Kommentaren meinte ich dann schon die sinnvollen Kommentare. 😉
Für mich gibt es eine recht einfache Begründung, warum die Imports vollständig mit drin sein sollten: wenn einer den Quelltext nicht mit einer richtigen IDE bearbeitet, wird es für ihn verdammt schwer, sowas wie F3 in Eclipse manuell nachzuvollziehen. Dann ist es für denjenigen einfach schöner, wenn er den Kram wirklich bis ins kleinste aufgekräuselt sieht.
Und für die Nutzer einer IDE ist es doch mal echt gar kein Problem: ein Klick auf das kleine Minus links neben dem ersten Import und schwupp, schon ist die ganze Importgeschichte komprimiert.

Daher: gebt den Texteditornutzern eine Chance! 🙂

Gruß FatFire

 

[bygones]

Daher: gebt den Texteditornutzern eine Chance! 🙂

ich geb den Pferdekutschen auf der Strasse auch keine Chance... sollen sich n Auto kaufen 😀

 

[musiKk]

und wenn bei dir das scrollen weniger als 1 Sek dauert heisst das du schaust so und so nicht auf die imports... dann kann man sie ja auch "verkuerzen"

Ich lese einen Quelltext ja nicht wie ein Buch von vorne bis hinten. Da interessiert mich mal eine Methode hier und da, weil ich sehen will, wie ein Interface implementiert wird oder ich will einen Gesamtüberblick. Wenn dort mal eine Klasse BlubberBla auftaucht, dann will ich schnell sehen können, wo die herkommt.

Dass das meiste aus [c]java.util[/c] oder ähnlichem kommt, tut dabei imho nichts zur Sache. Ich merke das in Eclipse oft am Content Assist, dass viele gängige Namen durchaus in fünf oder mehr verschiedenen Libraries vorkommen (obwohl ich nicht ausschließen möchte, dass die Zahl daran liegen kann, dass ich in irgendwelchen Testprojekten relativ viele Libraries eingebunden habe). Ich will nicht raten müssen, von wo nun eine Klasse kommt. Ich will im Browser nach dem Klassennamen suchen und als ersten Treffer bei einem Import landen (und wenn nicht, dann möchte ich davon ausgehen können, dass die Klasse im gleichen Package liegt).

An Lizenzinformationen dachte ich auch schon. Dass Dich die nicht stören, wundert mich in Anbetracht der Diskussion auch, da die auch meist redundant sind. Wenn die zentral abgelegt werden, reicht das. Aber das ist hier OT, denke ich.

 

[bygones]

Ich will im Browser nach dem Klassennamen suchen und als ersten Treffer bei einem Import landen (und wenn nicht, dann möchte ich davon ausgehen können, dass die Klasse im gleichen Package liegt).

in eclipse - auf Klasse / Methode und F3... dauert auch nicht mal ne sekunde ;-)

bygones... zwei versch. meinungen und keiner wird den anderen "ueberzeugen" 😀

 

[musiKk]

Stimmt, ich mach trotzdem kurz weiter. 😉

Bei Quelltext in Eclipse ists mir völlig egal, da nehme ich natürlich auch F3. Im Browser habe ich Quelltext dann, wenn ich mal irgendwelchen Beispielcode sehe oder ein SVN online durchschaue (SourceForge oder wasweißich).

So, fertig. Könnt mir auch eh alles Wurst sein. Viele Entwickler benutzen Eclipse und lassen die Standardeinstellung von 99 Imports bevor der * genutzt wird. Da hab ich ja meistens, was ich will. 😀

 

[Saxony]

Hiho,

ich finde die Einzelimports auch wesentlich übersichtlicher als die * Methode. Wie musiKk schon schreibt, liest man Quellcode nicht immer mit seiner lieb gewonnen IDE.

import com.thirdparty.core.*;
import com.thirdparty.runtime.*;
import com.thirdparty.util.*;
import com.thirdparty.model.*;
import com.thirdparty.ui.*;
...
public void macheEtwas() {
  new IrgendeineKlasse().macheAuchEtwas();
}

So und nun die Quizfrage: aus welchem package ist IrgendeineKlasse ohne F3 zu verwenden? 😉

bye Saxony

 

[bygones]

public void macheEtwas() {
  new IrgendeineKlasse().macheAuchEtwas();
}

So und nun die Quizfrage: aus welchem package ist IrgendeineKlasse ohne F3 zu verwenden? 😉

wen interessierts ? was bringt dir das mehr Information als

import com.thirdparty.core.IrgendeineKlasse;
// ganz viele andere imports und code so dass 
// der import oben nicht mehr auf dem Screen ist wenn man hier ist...
public void macheEtwas() {
  new IrgendeineKlasse().macheAuchEtwas();
}

whau nun weiss ich dass IrgendeineKlasse aus com.thirdpary.core kommt - oh moment.. nein ich muss wieder hochscrollen und schaun woher das jetzt kommt... das hat geholfen - moment... wofuer eigentlich ?

dann seid wenigstens konsequent (wenn euch diese Information scheinbar so viel bringt) und schreibt

new com.thirdparty.core.IrgendeineKlasse().macheAuchEtwas();

 

[Saxony]

wen interessierts ?

Das interessiert dahingehend, dass wenn ich Quellcode aus einem src Ordner lese sofort weiß durch welche Unterverzeichnisse ich mich hangeln muss um IrgendeineKlasse.java zu finden!

 

[Saxony]

import com.thirdparty.core.IrgendeineKlasse;
// ganz viele andere imports und code so dass 
// der import oben nicht mehr auf dem Screen ist wenn man hier ist...
public void macheEtwas() {
  new IrgendeineKlasse().macheAuchEtwas();
}

Ctrl+Pos1 ist bekannt oder? 😉

 

[bygones]

Ctrl+Pos1 ist bekannt oder? 😉

lol nun doch auf einmal in ner IDE.... entscheide dich (oder hat der vi / xemacs / notpad etc aufeinmal auch das ?)

Das interessiert dahingehend, dass wenn ich Quellcode aus einem src Ordner lese sofort weiß durch welche Unterverzeichnisse ich mich hangeln muss um IrgendeineKlasse.java zu finden!

[c]find src -name 'IrgendeineKlasse*'[/c] ;-)

wie man sieht - unsinnige Diskussion weil es scheinbar immer eine Ausnahme gibt die ja sooo oft auftritt...

in meinem Fall arbeite ich meist mit Eclipse und lade mir lieber schnell ein solches Projekt in Eclipse als mich ueber verzeichnisse mit deren Struktur auseinanderzusetzen...

ich halte die von euch aufgefuehrten Besonderheiten fuer eben dieso und nicht wirklich erwaehnenswert - und somit ist fuer mich nix zu sehen was einzel imports rechtfertigt ;-)


bygones !

 

[Saxony]

Na ich bleibe dabei EinzelImports sind Gold wert.

Ich hatte erst letztens zu einer ThirdPartyLib eine samples Verzeichnis mit 98743975 Beispielen. Alles .java Files in zig Ordnern verteilt. Keines davon ein EclipseProjekt. Und jetzt 98743975 Eclipse Projekte anlegen, nur um mich mit F3 durchzuhangeln zu können, wollt ich ne. Zum Glück hatten die Beispiele EinzelImport -> Tag gerettet.

just my 2 cents

 

[musiKk]

Nun, wenn man privat oder in einem eigenen Projekt Quelltext schreibt, kann man das ja machen wie man will und in Firmen sollte das ja sowieso in Coding-Standards festgehalten sein. Insofern genauso wie Konventionen zu Klammern, Bezeichnern, Einrückungen, ...
Was mir grad noch einfiel: Die Sun Code Conventions erwähnen das übrigens nicht.

Aber ich finds immer wieder interessant, wie die Leute sich oft extrem in eine Ecke stellen. Jemand, der z. B. Tabs verwendet, wird bis aufs Blut verteidigen, warum das multiplen Leerzeichen überlegen ist und umgekehrt (können wir ja in einem neuen Thread machen 😉). Geht mir aber natürlich genauso.

 

[Saxony]

\t = 1 Byte
____ = 4 Byte

😀

 

[Saxony]

lol nun doch auf einmal in ner IDE.... entscheide dich (oder hat der vi / xemacs / notpad etc aufeinmal auch das ?)

Ähm das haben Notepad, PSPad, UltraEdit und so gut wie alle fensterbasierenden Texteditoren standardmäßig...

 

[FatFire]

zwei versch. meinungen und keiner wird den anderen "ueberzeugen"

Belassen wir es daher doch einfach dabei. Jeder hat seine Argumente gebracht und nun soll der geneigte Leser eben für sich selbst entscheiden, ob er eine Einzelmeinung bevorzugt oder das macht, was offensichtlich auch von denen bevorzugt wird, die des öfteren mal Code anderer Programmierer anschauen oder in großen Projekten arbeiten müssen.

Gruß FatFire

PS: Manchmal rücken ja Menschen auch nicht von ihrer Position ab, einfach nur weil Sie nicht zugeben möchten, bisher eventuell nicht optimal gearbeitet zu haben. Ich kann das auch manchmal ganz gut.

 

[Marco13]

Selbst wenn man bei sowas wie
new IrgendeineKlasse().macheAuchEtwas();
oben einen import
com.thirdparty.runtime.IrgendeineKlasse;
sehe ich nicht, was das bringt. Websuche nach "IrgendeineKlasse" führt schnell zur JavaDoc, wenn es durch den Tooltip oder Strg+Klick nicht sowieso gefunden wird.

Ich habe den Threshold für den *-Import bei mir jedenfalls auf 2 Klassen eingestellt. So. Steinigt mich dafür 😀

 

[musiKk]

Wieso denn? Deinen Code muss ich ja nicht lesen. 😛