Hallo, gibt es ein schönes Tool, um alle //.. Kommentare meines C-Quellcodes auf eine bestimmte Zeichenposition zu verschieben - aus allen meinen Quellen? Danke für eure Hilfe :)
Angehängte Dateien:
-
Leertaste.jpg
360 KB
:D Meinst du denn ein Tool was Dateien stappelweiße abarbeitet und dabei die Kommentare auf z.b. Satzzeichen 10 setzt?! Ich stelle mir das halt mit den Kommentaren hinter Quelltext schwer vor, sowas zu realisieren. :/
Draco schrieb: > :D > > Meinst du denn ein Tool was Dateien stappelweiße abarbeitet und dabei > die Kommentare auf z.b. Satzzeichen 10 setzt?! > > Ich stelle mir das halt mit den Kommentaren hinter Quelltext schwer vor, > sowas zu realisieren. :/ Natürlich. Wenn ich z.B. 20 Quelldateien mit 10.000 Zeilen habe, sollen hier alle Kommentare auf Position 81 verschoben werden. ALs Beispiel :).
Klaus W. schrieb: > awk Der reguläre Asudruck, der die // in einem Stringliteral oder einem /* */ Kommentar nicht erkennt, würde mich interessieren.
Du könntest dir mal Uncrustify (http://uncrustify.sourceforge.net/) ansehen. Das macht natürlich noch etwas mehr als Kommentare richtig einzurücken, aber vielleicht hilft es ja.
DirkB schrieb: > Der reguläre Asudruck, der die // in einem Stringliteral oder einem /* > */ Kommentar nicht erkennt, würde mich interessieren. Man kann auch in awk die Zeile entlanglaufen und muß nicht alles mit einem RE erschlagen.
Ich frage mich schon, wieso jemand mit C hantiert, wenn er nicht in der Lage ist, sich ein Programm zu bauen, das so etwas macht. Wenn man fit ist, würde man hier nicht fragen, sondern es machen. Wenn nicht, ist es eine schöne Übung...
Und ich frage mich, warum jemand das Rad neu erfinden sollte, ohne vorher zu fragen, ob das nicht schon fix und fertig zu haben ist. Diese Frage nach einem Tool ist doch vollkommen Ok!
Stefan U. schrieb: > Und ich frage mich, warum jemand das Rad neu erfinden sollte, ohne > vorher zu fragen, ob das nicht schon fix und fertig zu haben ist. Bingo. Für sowas nimmt man awk oder sed.
Klaus W. schrieb: > Ich frage mich schon, wieso jemand mit C hantiert, wenn er nicht > in der > Lage ist, sich ein Programm zu bauen, das so etwas macht. > Wenn man fit ist, würde man hier nicht fragen, sondern es machen. > Wenn nicht, ist es eine schöne Übung... Wenn der Einäugige versucht den Blinden anzumachen ... Bei solchen Antworten frage ich mich, wo die Helden der C-Programmierung ihr Handwerk, und dazu gehören Werkzeuge, gelernt haben. In Kurzform, die korrekte Antwort ist indent Die klassische, launige Version der Antwort: man indent Die langhaarige Späthippie Antwort: https://www.gnu.org/software/indent/manual/indent.html#SEC8 Die was bin ich heute nett Antwort mit Zitat: > Comments to the right of code will appear by default in column 33. > This may be changed with one of three options. ‘-c’ will specify the > column for comments following code, ‘-cd’ specifies the column for > comments following declarations, and ‘-cp’ specifies the column for > comments following preprocessor directives #else and #endif. > ‘-dj’ together with ‘-cd0’ can be used to suppress alignment of > comments to the right of declarations, causing the comment to follow > one tabstop from the end of the declaration. Normally ‘-cd0’ causes > ‘-c’ to become effective. > > If the code to the left of the comment exceeds the beginning column, > the comment column will be extended to the next tabstop column past the > end of the code, or in the case of preprocessor directives, to one space > past the end of the directive. This extension lasts only for the output > of that particular comment.
Jay schrieb: > In Kurzform, die korrekte Antwort ist > > *indent* Jein. indent ist halt nur für Spezialfälle gedacht. Tools wie awk und/oder sed sind viel allgemeiner einsetzbar. Daher sind sie weitaus nützlicher. Und somit lohnt es sich mehr, sich mit diesen zu beschäftigen :-)
sed und awk unter Unix. Auf welchem Betriebssystem möchtest Du das machen? Grüsse, René
Jay schrieb: > In Kurzform, die korrekte Antwort ist > > indent Aber nur, wenn du damit leben kannst, dass dir alles umformatiert wird.
Jörg W. schrieb: > Jay schrieb: >> In Kurzform, die korrekte Antwort ist >> >> indent > > Aber nur, wenn du damit leben kannst, dass dir alles umformatiert > wird. Was ist gegen Code durchgehend nach einem gängigen Standard zu formatiert einzuwenden? Wenn dir dabei die Versionskontrolle um die Ohren fliegt hast du indent nicht früh und nicht konsequent verwendet. indent formatiert nur dort um, wo der Code nicht dem gewählten Standard entspricht. Wenn kein gängiger Formatier-Standard mundet, indent hat über 80 Parameter die man einzeln einstellen kann um sich sein persönliches Orchideen-Format zu generieren. Ein indent-Target ins Makefile gepackt und immer wenn nötig aufgerufen und der Code bleibt schön einheitlich. Warum soll ich mir für so eine Aufgabe ein eigenes Programm schreiben, egal ob in C, sed oder awk? Akademisch vielleicht interessant wenn man sich langweilt und man mit dem Schreiben des eigentlichen Programms nicht schon genug zutun hat.
Jay schrieb: > Warum soll ich mir für so eine Aufgabe ein eigenes Programm schreiben, > egal ob in C, sed oder awk? awk mit ein paar Parametern aufzurufen würde ich jetzt nicht als "eigenes Programm schreiben" bezeichnen.
Jay schrieb: > Was ist gegen Code durchgehend nach einem gängigen Standard zu > formatiert einzuwenden? Dass du hernach sackweise Diffs in der Versionsverwaltung siehst, die eigentlich gar keine sind. Das tut man sich nicht freiwillig an. (In der Anfangszeit von FreeBSD gab's mal eine Aktion “remove trailing whitespace”; das Fazit der Aktion war, dass es ein Fehler war, der sich halt nur nicht mehr rückgängig machen ließ. Zurückrollen des VCS war schließlich auch keine sinnvolle Option.) Es ist nichts dagegen einzuwenden, sowas von vornherein anzuwenden (wobei wir statt indent lieber astyle nehmen), aber nachträglich auf ein Projekt würde ich es nur draufpacken, wenn die bisherige Formatierung wirklich so scheußlich ist, dass man ohne die Umformatierung gar nicht mehr durchblickt.
Mich würden Lösungen mit awk oder sed interessieren. Ich bin diesbezüglich etwas skeptisch.
Jörg W. schrieb: > wenn die bisherige > Formatierung wirklich so scheußlich ist, dass man ohne die > Umformatierung gar nicht mehr durchblickt. Ach Jörg, jaja - aber das ist ein bissel zu kurz gesprungen. Normalerweise ist es ja so, daß jeder, der eine Quelle schreibt und nicht ganz und gar blöd ist, selbige von Hand so setzt, daß sie sich möglichst gut lesen läßt. Das ist immer viel qualifizierter, als irgend ein "mechanisches" Tool drüberlaufen zu lassen, was eben nur nach sturen Formalien arbeiten kann und keinen Sinn in der zu bearbeitenden Quelle sehen kann. Ebenso können solche Tools nicht im mindesten das visuelle Erscheinungsbild begreifen, was WIR als Menschen zu sehen imstande sind. OK, es gibt auch Schweineigel, die visuellen Bockmist zusammenschreiben. Dort hilft leider garnichts. Naja, außer per Dienstbefugnis diese Leute das Umformatieren ins Leserliche selber und von Hand durchführen zu lassen. Ist so etwa wie "jetzt schreiben Sie 100x "ich soll nicht ...". Die normale Reaktion ist abgrundtiefes Beleidigtsein, aber wer kennt nen besseren Weg? Kurzum, ich habe ganz strikt etwas gegen jedes maschinelle Herumformatieren an Quelltexten. Das sieht eigentlich immer mehr oder weniger unleserlich aus und ist mickrig im Vergleich zu einer von Menschenhand leserlich geschriebenen Quelle. Insofern ist das mit dem Layouten von Leiterplatten durchaus vergleichbar. Die Nichtkönner machen einen Drahtverhau draus. W.S.
Jörg W. schrieb: > Dass du hernach sackweise Diffs in der Versionsverwaltung siehst, die > eigentlich gar keine sind. Wo sollen die herkommen, wenn der Code entsprechend dem Standard formatiert war? Man muss so ein Tool nur rechtzeitig und konsequent einsetzen.
W.A. schrieb: > Man muss so ein Tool nur rechtzeitig und konsequent einsetzen. Darum ging es aber in diesem Thread einfach mal nicht. Die Frage war nicht nach den besten Empfehlungen zu Formatierung von Sourcecode, sondern nach einem Tool, das Kommentare auf eine bestimmte Spalte verschiebt.
W.S. schrieb: > > Kurzum, ich habe ganz strikt etwas gegen jedes maschinelle > Herumformatieren an Quelltexten. Das sieht eigentlich immer mehr oder > weniger unleserlich aus und ist mickrig im Vergleich zu einer von > Menschenhand leserlich geschriebenen Quelle. Im Laufe der Jahre habe ich einigen Code von Programmierern gereviewt. Nur sehr wenige haben es geschafft einen vorgegebenen Style konsequent zu nutzen. Meine Erfahrung: Formatierter wie Astyle sind besser als Programmierer weil sie die Ausreden * Vergessen * Keine Zeit * Wir haben einen Styleguide...? Nicht kennen...
Marc schrieb: > Im Laufe der Jahre habe ich einigen Code von Programmierern gereviewt. > Nur sehr wenige haben es geschafft einen vorgegebenen Style konsequent > zu nutzen. Das deckt sich zu 100% mit meinen Erfahrungen.
Marc schrieb: > Nur sehr wenige haben es geschafft einen vorgegebenen Style konsequent > zu nutzen. Meine Erfahrung: Formatierter wie Astyle sind besser als > Programmierer weil sie die Ausreden... Es kommt auf die Leserlichkeit an, also auf das, was wir Menschen optisch gut erfassen können - und nicht darauf, auf irgendwelchen "vorgegebenen Style(s)" dogmatisch herumzupochen. Und da sind Programme eben stur und doof und können es eben doch nicht so wie ein (zugegebenermaßen verständiger) Mensch. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.