Diskussion:Quelltextformatierung

message: 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)
replies: text: 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)
replies: text: 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)

message: "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)
replies: text: 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)
thread_title:  Beispiel 

message: .. 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)
thread_title:  Break in "for"-Schleifen