nicht angemeldet
Eclipse löscht Whitespaces
sethHallo,
kennt sich jemand mit dem Codeformatter in Eclipse aus? Ich kann alles dort einstellen, soweit ok.
Aber ich kriegs nicht hin, dass mir der Code-Formatter aus:
public $test; // Diese Variable beinhaltet...
public $nochntest; // Diese Variable beinhaltet...
das hier macht:
public $test;//Diese Variable beinhaltet...
public $nochntest;//Diese Variable beinhaltet...
Wo ist hierfür die Einstellungsmöglichkeit?
Jonny
-
Aber ich kriegs nicht hin, dass mir der Code-Formatter aus:
public $test; // Diese Variable beinhaltet... public $nochntest; // Diese Variable beinhaltet...das hier macht:
public $test;//Diese Variable beinhaltet... public $nochntest;//Diese Variable beinhaltet...Ich meinte natürlich das genaue Gegenteil!
Eclipse macht mir genau das, dass es nämlich die Whitespaces löscht und ich möchte das verhindern.
Jonny
-
gudn tach!
kennt sich jemand mit dem Codeformatter in Eclipse aus? Ich kann alles dort einstellen, soweit ok.
Aber ich kriegs nicht hin, dass mir der Code-Formatter aus:
ich nutze eclipse nur fuer c++, da geht es so:
Window -> Preferences -> C/C++ -> Code Style -> Formatter -> Edit... -> Comments ->
[x] Preserve white space between code and line comments if possible
prost
seth
-
Hallo,
ich nutze eclipse nur fuer c++, da geht es so:
Window -> Preferences -> C/C++ -> Code Style -> Formatter -> Edit... -> Comments ->
[x] Preserve white space between code and line comments if possible
Ja, genau das würde ich gesucht haben, aaaber: In php-eclipse gibts das nicht. Ich habs mal kontrolliert, in Java ist die Option auch vorhanden, in php aber nicht.
Ist ein eher schwacher Trost für mich, dass ich das dann auch nicht finden konnte :-(
Und nun? Hat einer eine Idee?
Gruß, Jonny
-
Tach!
Und nun? Hat einer eine Idee?
Schreib den Kommentar über die Variable/Eigenschaft/wasauchimmer. So ein Kommentar, der weitab von dem zu kommentierenden Objekt steht, ist schwerer zuzuordnen als einer, der direkt darüber oder darunter steht.
Die Form, so wie du sie anstrebst, bildet optisch gesehen links einen Block und rechts einen. Die Zugehörigkeiten sind stattdessen aber zeilenweise. Wenn du das hingegen so formatierst:
//Diese Variable beinhaltet... public $test; //Diese Variable beinhaltet... public $nochntest;bilden sich Blöcke, die die Zugehörigkeiten besser zeigen. Und noch besser wäre, wenn du die PHPDoc-Syntax verwenden würdest, dann können IDEs, die diese verstehen (Eclipse gehört dazu), direkt beim Tippen helfen, indem sie die Kommentare als Tooltip einblenden. Ansonsten musst du, um selbige lesen zu können erst zur Definitionsstelle springen.
/** * @var string Diese Variable beinhaltet... */ public $test; /** * @var int Diese Variable beinhaltet... */ public $nochntest;dedlfix.
-
Hallo dedlfix,
Schreib den Kommentar über die Variable/Eigenschaft/wasauchimmer. So ein Kommentar, der weitab von dem zu kommentierenden Objekt steht, ist schwerer zuzuordnen als einer, der direkt darüber oder darunter steht.
Das mache ich auch normalerweise so, aber in diesem Fall nimmt mir das zuviel Platz weg. Ich wollte die Variablen innerhalb eines Bildschirms behalten. Zudem ging es nicht nur um diese Zeilen, sondern auch um einen internen Kommentarblock, der in den Scripten immer gleich aussieht und unschön zerissen wird. Ich habe mir jetzt damit beholfen, dass in php-eclipse die on-off-tags des Formatters funktionieren und ich diese beiden Blöcke dann eben aus der Formatierung heraus nehmen kann.
Und noch besser wäre, wenn du die PHPDoc-Syntax verwenden würdest, dann können IDEs, die diese verstehen (Eclipse gehört dazu), direkt beim Tippen helfen, indem sie die Kommentare als Tooltip einblenden. Ansonsten musst du, um selbige lesen zu können erst zur Definitionsstelle springen.
Damit kenne ich mich nicht gut genug aus. Sollte ich vielleicht mal einen Blick rein riskieren... Bleibt aber (sogar noch mehr als bei obiger Lösung), daß meine Variablendeklaration mir dann zu sehr auseinander gerissen werden würde.
Gruß, Jonny
-
Tach!
Und noch besser wäre, wenn du die PHPDoc-Syntax verwenden würdest, dann können IDEs, die diese verstehen (Eclipse gehört dazu), direkt beim Tippen helfen, indem sie die Kommentare als Tooltip einblenden. Ansonsten musst du, um selbige lesen zu können erst zur Definitionsstelle springen.
Damit kenne ich mich nicht gut genug aus. Sollte ich vielleicht mal einen Blick rein riskieren... Bleibt aber (sogar noch mehr als bei obiger Lösung), daß meine Variablendeklaration mir dann zu sehr auseinander gerissen werden würde.
Die liest man eigentlich nur einmal am Stück, wenn man sich einen ersten Überblick über den Code verschaffen möchte. Die Übersichtlichkeit braucht man dann nur noch selten wieder. Besonders dann nicht, wenn die IDE die konkreten Kommentare an der Stelle ihrer Verwendung einblenden kann. Man muss also nicht immer wieder zum Nachlesen an die Stelle der Deklaration gehen.
Konkretes Beispiel: Ich tippe einen Variablennamen $foo und dann das ->. Die IDE weiß nun bereits, welchen Typ die Variable im Normalfall hat. Das Wissen hat sie, weil sämtlicher Code mit PHPDoc kommentiert ist. Wurde der Variablen das Ergebnis einer Funktion zugewiesen, dann gab es zu dieser Funktion einen PHPDoc-Block, der den Rückgabetyp dokumentiert hat. Das hat die IDE gelesen und weiß nun was $foo enthält. Oder aber es fand ein $foo = new Something() statt, dann weiß die IDE, dass der Typ Something ist. In besonders zweifelhaften Fällen kann ich auch mit einem Zeilenkommentar nachhelfen.
$foo = zweifelhaft; /** @var $foo konkreterTyp */Ich hab da also $foo-> zu stehen und nun springt die AUtovervollständigung an und präsentiert mir alle Fortsetzungsmöglichkeiten. Wenn ich durch die Liste gehe, kommen dann auch die Kommentare der einzelnen Mitglieder als Tooltip auf den Schirm.
dedlfix.
-
Hi dedlfix,
Die liest man eigentlich nur einmal am Stück, wenn man sich einen ersten Überblick über den Code verschaffen möchte. Die Übersichtlichkeit braucht man dann nur noch selten wieder.
Korrekt. Ich sollte vielleicht dazu sagen, dass ich meine erste Klasse in php schreibe, daher war mir das ziemlich wichtig.
Ich hab da also $foo-> zu stehen und nun springt die AUtovervollständigung an und präsentiert mir alle Fortsetzungsmöglichkeiten. Wenn ich durch die Liste gehe, kommen dann auch die Kommentare der einzelnen Mitglieder als Tooltip auf den Schirm.
Nagut. Ich probiere das morgen aus. Hört sich wirklich nach "Mehrwert" an!
Ich schreib' dann hier zurück, ob es mir gelungen ist bzw. ob es mir nützt.
Danke, Jonny
-
-
-
gudn tach!
Und nun? Hat einer eine Idee?
Schreib den Kommentar über die Variable/Eigenschaft/wasauchimmer. So ein Kommentar, der weitab von dem zu kommentierenden Objekt steht, ist schwerer zuzuordnen als einer, der direkt darüber oder darunter steht.
Die Form, so wie du sie anstrebst, bildet optisch gesehen links einen Block und rechts einen. Die Zugehörigkeiten sind stattdessen aber zeilenweise.
da ich in letzter zeit nix mehr mit php gemacht hab, hole ich mal ein beispiel aus der c++-welt, das man aehnlich sicherlich auch in der php-welt findet.
enum FileFormat{ JPG = -2, /**< indicates a bitmap */ DEIMUDDA = 1, /**< file format of your mother */ HUDELSPRUDEL = 2, /**< you'll never guess, what that means */ }Wenn du das hingegen so formatierst:
//Diese Variable beinhaltet... public $test; //Diese Variable beinhaltet... public $nochntest;... dann ist es sofort schlechter lesbar:
enum FileFormat{ /** indicates a bitmap */ JPG = -2, /** file format of your mother */ DEIMUDDA = 1, /** you'll never guess, what that means */ HUDELSPRUDEL = 2, }bilden sich Blöcke, die die Zugehörigkeiten besser zeigen.
tun sie hier nicht. klar, man koennte noch leerzeilen einfuegen, z.b.
enum FileFormat{ /** indicates a bitmap */ JPG = -2, /** file format of your mother */ DEIMUDDA = 1, /** you'll never guess, what that means */ HUDELSPRUDEL = 2, }das waere nicht mehr ganz so schlimm fuer die lesbarkeit, aber immer noch nicht so gut lesbar, wie die erste variante. zudem hat man bei einer liste mit mehr elemten (als nur 3) den vorteil, nur ein drittel so viel zeilen zu benoetigen, sodass man weniger scrollen muss, um einen ueberblick zu bekommen.
grundsaetzlich gebe ich dir, dedlfix, zwar recht, dass man es moeglichst so machen sollte, wie du vorgeschlagen hast. ich nenne auch noch zwei weitere vorteile davon: wenn man kommentare nicht rechts hinter den code schreibt, sondern drueber, dann:
- bereiten mehrzeilige kommentare weniger probleme und werden haeufig vom IDE supportet.
- kann man besser die zeilenlaenge kleinhalten (ueber die meinungen einer vernuenftigen zeilenlaenge gehen die meinungen ja auch auseinander, aber meines wissens haben coding style guides groesserer projekte quasi immer eine maximale zeilenlaenge, und die wird dann nicht so schnell erreicht).
- ist das einruecken (wichtig: wenn non-whitespace davorsteht, dann nur mit leerzeichen, nicht mit tabs) etwas weniger aufwendig.
aaaber: gerade bei listenhaften aufzaehlungen gleichartiger (zusammengehoerender) entitaeten halte ich die links-rechts-blockbildung fuer die elegantere alternative, wenn man die listenelemente nur kurz erklaeren moechte. haeufig moechte man ja den kommentar gar nicht lesen, wenn man ihn schon kennt (oder umgekehrt sogar erst mal nur die kommentare). dann ist die links-rechts-blockbildung von vorteil.
lange rede, kurzer sinn: ich nutze auch fuer c++ den code-formatter von eclipse nicht, weil er zwar gut ist, aber nicht sehr gut, und teilweise sogar buggy (zumindest in der von mir benutzten version 'juno').
wenn das nicht-benutzen keine akzeptable problem-loesung ist, dann kann vielleicht eine loesung sein, den white-space hinter das kommentar-zeichen anstatt davor zu setzen. wie gesagt, nur in ausnahmefaellen; grundsaetzlich eher so, wie dedlfix bereits sagte.
prost
seth
ps: oben hab ich doxygen-kommentare verwendet. bei normalen c++-kommentaren wuerde sich die syntax in bezug auf das hier diskutierte thema vernachlaessigbar geringfuegig aendern.
-
-
-