Zu einem guten Codierstyleguide geh\u00f6rt immer auch eine Formatierungsansage. Es ist deutlich einfacher, fremde Quelltexte zu lesen, wenn diese gleichf\u00f6rmig formatiert sind. Unsch\u00f6n formatierte Sourcecodes gibt es zuhauf. Auch man selber ist nicht immer gefeit, die eigenen Stilvorgaben und Vorlieben auch einzuhalten. Auch wenn man in einem Team gemeinsam Sourcen bearbeitet, kann ein solcher Styleguide helfen. Beim Hatari Projekt ist das z.B. recht uneinheitlich.<\/p>\n
Wie genau ein Quellcode nun einzur\u00fccken und zu formatieren ist, das bleibt immer eine pers\u00f6nliche Frage, z.B. wie geschweifte Klammern zu setzen sind. Hauptsache, der Stil ist einheitlich.<\/p>\n
Dabei helfen nat\u00fcrlich kleine Tools, bessere IDEs wie Code::Blocks oder Eclipse bieten gleich entsprechende Plugins. H\u00e4ufig rufen diese aber auch nur fertige Tools f\u00fcr die Kommandozeile auf.<\/p>\n
Unter Linux kommen direkt 2 Kandidaten infrage:<\/p>\n
Ich habe mich f\u00fcr Artistic Style<\/strong> entschieden, da es die von mir genutzten Optionen auf Anhieb anbietet. Ich habe nur ein wenig experimentiert und meine Vorlieben sehen wie folgt aus:<\/p>\n # main style: # indentation with TABS (4 spaces per TAB): # contents of switch case statements are indented, including the break: # preprocessor statements that are split are indented: # loops and if statements are seperated by empty lines: # parenthesis are padded with spaces: # unnecessary empty lines are deleted: Das Ganze kann man nach $HOME\/.astylerc speichern und schon braucht man das Tool nicht mehr mit Kommandozeilenparametern zu f\u00fcttern.<\/p>\n
\n#
\n# astylerc for Matthias Arndt
\n#
\n# history:
\n# 2011-05-26 initial version
\n#<\/p>\n
\nstyle=bsd<\/p>\n
\nindent=tab<\/p>\n
\nindent-cases<\/p>\n
\nindent-preprocessor<\/p>\n
\n# (associated block comments are kept)
\nbreak-blocks<\/p>\n
\npad-paren<\/p>\n
\ndelete-empty-lines
\n<\/code><\/p>\n