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. ~~~cpp 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: > > ~~~php > //Diese Variable beinhaltet... > public $test; > > //Diese Variable beinhaltet... > public $nochntest; > ~~~ ... dann ist es sofort schlechter lesbar: ~~~cpp 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. ~~~cpp 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: 1. bereiten _mehrzeilige_ kommentare weniger probleme und werden haeufig vom IDE supportet. 2. 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). 3. 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.

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. ~~~cpp 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: > > ~~~php > //Diese Variable beinhaltet... > public $test; > > //Diese Variable beinhaltet... > public $nochntest; > ~~~ ... dann ist es sofort schlechter lesbar: ~~~cpp 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. ~~~cpp 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: 1. bereiten _mehrzeilige_ kommentare weniger probleme und werden haeufig vom IDE supportet. 2. 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). 3. 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.

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. ~~~cpp 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: > > ~~~php > //Diese Variable beinhaltet... > public $test; > > //Diese Variable beinhaltet... > public $nochntest; > ~~~ ... dann ist es sofort schlechter lesbar: ~~~cpp 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. ~~~cpp 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: 1. bereiten _mehrzeilige_ kommentare weniger probleme und werden haeufig vom IDE supportet. 2. 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). 3. 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.