Diskussion:Quelltextformatierung

Ich denke nicht, dass die Beispiele irgendwie ungewöhnlich sein sollten. Die Schreibeweise i++ ist wesentlich häufiger anzutreffen als ++i:

chris@riedquat:/usr/src/linux> find -name "*.c" | xargs grep "i++" | wc
  13011  114202  851094
chris@riedquat:/usr/src/linux> find -name "*.c" | xargs grep "++i" | wc
   1326   11616   85625
chris@riedquat:/usr/src/linux> find $JAVA_HOME/src -name "*.java" | xargs grep "i++" | wc
   4696   45145  579096
chris@riedquat:/usr/src/linux> find $JAVA_HOME/src -name "*.java" | xargs grep "++i" | wc
    446    3677   56411

Sowohl in den Sourcen des Java API als auch in den Sourcen des Linux-Kernels (2.4.20) kommt i++ also 10 Mal so häufig vor wie ++i.

Das gilt insbesondere für das Auftreten in for-Statements:

chris@riedquat:/usr/src/linux> find -name "*.c" | xargs grep -E '; ?i\+\+ ?\)' | wc
  11089  100573  726206
chris@riedquat:/usr/src/linux> find -name "*.c" | xargs grep -E '; ?\+\+i ?\)' | wc
    878    8377   57286
chris@riedquat:/usr/src/linux> find $JAVA_HOME/src -name "*.java" | xargs grep -E '; ?i\+\+ ?\)' | wc
   4302   42962  534350
chris@riedquat:/usr/src/linux> find $JAVA_HOME/src -name "*.java" | xargs grep -E '; ?\+\+i ?\)' | wc
    255    2654   32130

Im Iterationsteil von for-Statements kommt i++ also zwischen 10 und 20 Mal häufiger vor als ++i, zumindest in den untersuchten Sourcen, die aber wohl als repräsentativ gelten dürften. Ich habe deshalb ++i wieder in i++ zurückgeändert. --ChristianHujer 20:52, 3. Apr 2005 (CEST)

An diesem Fall sieht man gut, dass Menge nicht über Qualität entscheidet. i++ kommt also 10 Mal so häufig vor, wie ++i. Dabei sollte es umgekehrt sein, denn ++i erzeugt gleichen oder effizienteren Code als i++. Deshalb sollte man sich angewöhnen, wann immer möglich ++i zu schreiben. Es kann sein, dass die Mehrheit der Programmierer das nicht weiß. Wikipedia weiß es aber besser. --217.95.168.102 20:13, 5. Apr 2005 (CEST)

Es stimmt schon, dass "++i" effizienteren Code als "i++" erzeugt, sofern der Compiler nicht optimiert. Pseudocode für i++: "Lies I in Register 1. Kopiere Register 1 in Register 2. Erhöhe Register 1. Schreibe Register 1." Pseudocode für ++i: "Lies I in Register 1. Erhöhe Register 1. Schreibe Register 1." Eine Kopie des alten Wertes ist bei ++i eben nicht notwendig. Das zu Schreiben wäre übrigens *DEINE* Aufgabe gewesen, und nicht soetwas wie "Wikipedia weiß es aber besser". Trotz dessen, dass ich weiß, dass ++i unter Umständen bei langsamen CPUs ohne moderne skalierte Pipeline + nicht-optimierendem Compiler je nach CPU einen halben bis 4 ganze Takte (Motorola 68000 von 1979) langsamer ist, verwende ich trotzdem i++ - wie viele andere Programmierer auch, inklusive Assembler- und Maschinenprogrammierung-erfahrene Linux-Kernel-Hacker. Zum anderen: Nur weil etwas eventuell einen Maschinenzyklus effizienter sein könnte, ist das kein Grund, in der Wikipedia einfach eine Schreibeweise für Code zu verwenden, die im Vergleich zur gebräuchlichen ungewöhnlich ist. Hier bei Beautifier kann ich's noch akzeptieren. Zu Einrückung siehe bei Einrückung.--ChristianHujer 00:36, 7. Apr 2005 (CEST)

lint ist ein Werkzeug zur Code-Analyse, nicht zur Quelltextformatierung. 193.109.238.110 11:47, 5. Jun. 2007 (CEST)

Beispiel

"Sämtliche modifizierenden Anweisungen (Anweisungen von for, if etc.) wurden in Blöcke gefasst. Das vermeidet Fehler beim späteren Hinzufügen weiterer Anweisungen."

Ich kann diese Aussage im Beispiel nicht nachvollziehen. Im Quelltext vor der Quelltextformatierung sind die modifizierenden Anweisungen auch in Blöcke gefasst. Es gibt hier lediglich eine Änderung bzgl. der Position der geschweiften Klammern. --MonaLuna 14:54, 7. Dez. 2009 (CET)

Genau! Ist mir auch gerade aufgefallen. Ich würde am liebsten auch die fragwürdigen Bezeichnung modifizierende Anweisung rausnehmen. Ob nun Modifizierungen vorgenommen werden oder nicht, hat mit den Blöcken nicht viel zu tun. Den augenscheinlichsten Fehler aus dem Beispiel nehme ich aber gleich mal raus. Grüße --Uncopy 12:03, 13. Apr. 2010 (CEST)

Break in "for"-Schleifen

.. ich möchte nicht besserwisserhaft klingen, aber ein "break" in einer for-Schleife wird bei "uns" (großer Entwicklungbereich in einem multinationalen Großkonzern) von vorgeschalteten Tools (z.B. QAC) als Coding-Policy-Verletzung gemeldet ==> Code bekommt keine Serienfreigabe. Die Gründe sind vielfach. Einer ist: Der Austrittspfad aus einer Funktion muss eindeutig sein. Ein break führt einen zusätzlichen Pfad ein. Zusätzliche Pfade werden in Reviews nur bedingt erfasst (Lessons Learned). Dadurch steigt die Fehlerwahrscheinlichkeit pro Funktionsblock. Demgegenüber steht, dass etwaige Performance-Vorteile durch ein break heutzutage eher theoretisch Natur sind (zumindest bei den von uns verwendeten Industrie-Compilern). Um unnötige Diskussionen zu vermeiden daher die Bitte: im gegebenen Beispiel kein break in der For-Schleife verwenden => hält den Fokus auf dem Thema "Quelltextformatierung".

Schönen Gruß, M. S. (nicht signierter Beitrag von 2003:6A:6C3E:A611:41AF:FECE:1EFF:2B16 (Diskussion | Beiträge) 22:33, 14. Sep. 2013 (CEST))

unpräzise Definition

In der Einleitung wird mit 'Quelltextformatierung' nur das 'Umformatieren' von Quelltext bezeichnet. Der dann folgende Text bezieht sich aber u.a. auch auf das Anwenden von Formatierungsregeln im Allgemeinen. So wird das auch im Englischen WP-Artikel definiert "(...the application of any of ... stylistic formatting conventions"). Man sollte deshalb HIER ändern in: "... das Anwenden definierter Formatierungsregeln ...". Alternativ könnte in der Einleitung der Hinweis erscheinen, dass darunter sowohl die Maßnahme zum 'Umformatieren' bestehenden Textes als auch die Formatregelanwendung bei der Erstellung von Neutexten verstanden wird. --VÖRBY (Diskussion) 15:29, 9. Nov. 2013 (CET)

kein Feedback, ich mache das also dann in Kürze. --VÖRBY (Diskussion) 17:59, 19. Nov. 2013 (CET)

Hab mir den englischen Text nochmal angesehen. Neben dem ersten Satz dort (der sich auch auf neue Texte beziehen könnte) ergibt sich aus dem zweiten Satz "... usually consist of changes in positioning, ...", dass auch in der enWP - zumindest 'usually' - das Umformatieren gemeint ist. Ich ziehe deshalb meinen Änderungsvorschlag zurück, bin aber der Meinung, dass der Titel des Lemmas dann eigentlich "Quelltextumformatierung" lauten müsste - was natürlich ein Wortungetüm wäre.

Allerdings beschreiben die weiteren Absätze der Einleitung (IDE, Syntaxelement bei Python/Occam) ebenfalls Situationen, in denen nicht 'um-Formatiert' wird, sondern einfach Formatregeln angewendet werden. Insofern wäre der erste Satz doch änderungswürdig (ohne 'Um'). Ggf. wäre der Hinweis nützlich, das man das Anwenden von Formatregeln bei der Erzeugung und das nachträgliche Umgestalten (mit Code 'Beautifiern') unterscheiden kann. --VÖRBY (Diskussion) 17:00, 21. Nov. 2013 (CET);
ergänzt: --VÖRBY (Diskussion) 17:13, 21. Nov. 2013 (CET)

Also ich verstand unter "Um"formatieren, dass der Quelltext ggf. bereits schon (nach irgendwelchen Regeln) formatiert sein kann.

Möchtest du nun noch etwas ergänzen/"um"formulieren :) ?--Plankton314 (Diskussion) 18:29, 21. Nov. 2013 (CET)

Zum 'Um-formatieren' passen die Aussagen zu IDE und Python ... nicht. Insofern würde ich zumindest das 'Um' wegnehmen wollen; dann passt der Text wenigstens zum Lemma. Um wirkliche Klarheit zu schaffen wäre der o.a. Hinweis zu den beiden Varianten nützlich. Der en-Link passt nur zum 'Um-Formatieren', der Zielartikel dort heißt schließlich 'Prettyprint', was eine Art von 'beautifying' ist. Deine Meinung? --VÖRBY (Diskussion) 09:57, 22. Nov. 2013 (CET)

Auch wenn die englischsprachigen Artikel immer mal wieder eine gute Orientierung abgeben, ist nicht alles was dort steht unbedingt eine gute Richtschnur.

Nach dem überwältigenden Feedback hier und dem Umstand, dass es wahrscheinlich keine 100 %-ig exakte Definition des Begriffs geben wird --> WP:SM. Ich habe spontan auch keine genau(ere) Vorstellung.--Plankton314 (Diskussion) 10:16, 22. Nov. 2013 (CET)