[HaBo]

b4ck

Anzeige

Hi,

ich programmiere in PHP hauptsächlich mit dem symfony framework.

Mit Version 2.0 passt sich das Framework an den PEAR Coding standard an.
Somit wechseln sie bei der Einrückung von 2 Spaces auf 4 Spaces / tab.

Gibt es eine einfache Möglichkeit mit Eclipse oder Commandline (ich verwende Opensuse 11.2) alle php-files auf 4 space einrückung zu adaptieren ?

odigo

Suchen/Ersetzen über alle Files von 2 Spaces am Zeilenanfang auf 4.
Der reguläre Ausdruck für die Suche müsste in etwa so aussehen:
^[:blank]{2} (je nach Programm)
Daß das mit Eclipse selbst geht wäre mir nicht bekannt. Ich benutze hierfür immer "InfoRapid Suchen & Ersetzen" (einfach mal danach googlen).

dishix

<OT>
Hallo,

warum versuchen eigentlich immer wieder irgendwelche Leute mit Spaces einzurücken? Diese ganzen Editoren, die aus Tabs Spaces machen und jedem, der das File irgendwann einmal lesen will, die Einrücktiefe des Autors aufzuzwingen, sind echt nervige Datenvernichtungstools. Warum gibt es Menschen, die nicht auf die Idee kommen, dass ein Programm in einem Terminal schlicht unlesbar ist, wenn mit acht (es gibt Leute, die machen sowas!) Spaces eingerückt wird?
Man man man, warum wurden wohl Tabs erfunden?
</OT>

Liebe Gruesse
dishix

__________________
"Wenn A für Erfolg steht, gilt die Formel A=X+Y+Z. X ist Arbeit, Y ist Muße und Z heißt Mundhalten."
Albert Einstein

b4ck

das musst du die Leute von PEAR fragen die ihren coding standard so erstellt haben

des weiteren ist es wenn du mi YAML files arbeitest zwingend nötig mit spaces einzurücken da sonst der YAMLparser ein ziemliches problem kriegt.

Ich editiere meine files auch (selten aber doch) im terminal nur bei Projekten dieser größe macht das in meinen Augen wenig Sinn.

Ich glaube dieser Kampf 2 spaces vs. 4 spaces vs. tabs wird nie enden und jeder soll machen wie er glaubt / muss.

beavisbee

Weil es Leute gibt, die das als Coding-Standard irgendwo festgelegt haben...
Im Coding-Standard des Zend-Framework ist es genauso:

• Einrückung 4 Spaces
• max. Zeilenlänge SOLLTE 80 Zeichen nicht überschreiten (alles was drüber ist, wird bei phpcs mit einer WARNING quitiert)
• absolute Schmerzgrenze, welcher man sich eigentlich nicht unbedingt nähern sollte: 120 Zeichen (alles was drüber ist, wird bei phpcs mit einem ERROR quitiert)

Nicht die Einrücktiefe des Autors... die Einrücktiefe des Coding-Standards!...

Okay, 8 Spaces sind echt böse - aber wer macht das? 2 oder 4 Spaces sind dagegen doch okay.
Wenn man sich nicht nur an die Einrückung, sondern auch an die max. Zeilenlänge eines Coding-Standards hält (eben z.B. bei Zend Framework das SOLL von max. 80 Zeichen), kann man den Code auch im Terminal problemlos lesen.

und wenn jemand kommt "aber da hab ich ja in dem swtich in der for-schleife innerhalb der anderen for-schleife innerhalb des while in meiner Methode gar keinen Platz mehr für Code", dann hat der jenige wohl zu wenig in Unter-Methoden abstrahiert...

somit schützen solche Coding-Standards auch gleichzeitig vor zu komplexen Bauwerken.

wer Teil-Probleme auch in einzelnen kleinen Methoden unterbringen kann, statt alles in einem Mega-Konstrukt zu schreiben, kommt mit 80 Zeichen Zeilenlänge bei 4 Spaces Einrückung ganz gut hin...

xblax

Naja 80 Zeichen Zeilenbreite sind meiner Meinung nach doch etwas antiquitiert.
Das es vielleicht ein allgemeiner Richtwert ist, ist verständlich, aber wenn man Methodenheader oder sowas umbrechen müsste nehme ich lieber eine breitere Zeile in Kauf.
Außerdem finde ich ordentliche Variablennamen wichtiger als alles möglichst kurz zu halten.

Gibt es für PHP in Eclipse keine Autoformat Funktion mit der man alles gerade biegen kann?

Ich rücke übrigens auch gerne mit vier Leerzeichen ein, einfach aus dem Grund, dass dann der Code in allen Editoren gleich aussieht ohne das man was umstellen müsste. In vielen Editoren ist der Tabulator eben wirklich 8 Zeichen breit, ich glaub auch in Webbrowsern.

bitmuncher

Der Linux-Kernel z.B.:

__________________

odigo

Naja, man muss schon auch sagen daß es echt arm ist wenn man Programme im Terminal anschauen muss. Ich würde es nicht freiwillig machen und ich habe kein Problem mit dem Terminal, aber Programme (Sourcecode) haben da nichts mehr suchen

bitmuncher

Du hast offenbar noch nicht viel mit Systemprogrammierung zu tun gehabt. Da hat man zumeist nur ein Terminal zur Verfügung, gerade wenn man an den Basics eines Systems arbeitet.

__________________

xblax

Naja aber den Großteil der Entwicklung wird man ja dann auf einem anderem System vornehmen.

Außerdem gibt es natürlich immer ausnahmen.
Aber wer beispielesweise Java im Terminal programmiert der ist auch selber schuld, denn das ist wirklich nicht nötig. Das gilt auch für sonstige Anwendungsentwicklung.

bitmuncher

Zeig mir eine IDE, die auch nur annähernd so gut wie Emacs ist und ich verzichte gern auf Terminals. Solange code ich aus Prinzip weiter im Terminal, selbst bei der Anwendungsentwicklung. Ich denke es macht da auch wenig Sinn zu behaupten, dass Sourcecode im Terminal nichts mehr zu suchen hat. Es gibt Dinge in Terminal-IDEs, die man einfach mit anderen IDEs nicht machen kann (Eingaben während des Editierens an Terminal-Programme weiterleiten, Skripte für die Konfiguration verwenden um umgebungsabhängige Konfigurationen aufzubauen u.ä.) und es gibt Dinge in grafischen IDEs, die man in Terminals nicht oder nur beschränkt umsetzen kann (Dropdown-Boxen für Code-Complete, kontext-sensitive Hilfe etc.). Beides hat somit seine Berechtigung und es einfach abhängig von den Vorlieben des jeweiligen Entwicklers. Für mich gehört Code jedenfalls in Terminals, genauer gesagt in einen textbasierten Emacs. Und über Geschmack sollte man bekanntlich nicht streiten.

Achja... zum Thema: Mit Emacs oder ViM lassen sich Dateien problemlos und schnell reformatieren. Alternativ kann man auch sed verwenden.

__________________

xblax

Ok das ist sicher der Fall, dass man damit super programmieren kann, allerdings kann man dann auch ein virtuelles Terminal benutzen oder sich nen Framebuffer konfigurieren.

80 Zeichen Zeilenbreite sind für mich einfach noch ein Überbleibsel aus einer art anderem Computerzeitalter.
Klar, wenn man den Kernel einfach so bootet dann hat man erstmal nicht mehr, aber das kann ja nicht das Maß der Dinge sein.

Wenn man 80 Zeichen aus Gründen der Lesbarkeit als Limit nimmt, dann kann man darüber streiten aber es macht evtl. Sinn.
Wenn man für eine normale Anwendung 80 Zeichen als Limit aufgrund technischer beschränkung von Textkonsolen definiert, dann frage ich mich ernsthaft was die letzten 20 Jahre Computerentwicklung gebracht haben. (frage ich mich auch so machnmal)

bitmuncher

Die letzten 20 Jahre Computerentwicklung haben imo auch nicht viel gebracht. Der einzige Fortschritt ist die Verarbeitung von immer größeren Datenmengen in immer kürzerer Zeit. Sonst baut alles noch auf Technologien auf, die sich seit zumindest 10-15 Jahren nicht verändert haben. Gerade im Linux-Umfeld wird das mehr als deutlich (monolitihischer Kernel, oftmals prozedurale Programmierung für Applikationen, händische Speicherverwaltung etc. pp.), aber auch bei anderen Systemen ist das nicht viel anders und die Unterschiede zur ursprünglichen Software ist höchsten marginal. Und schaut man sich die Hardware an, gibt's auch da kaum Verbesserungen. Eher im Gegenteil. Aus 36 Bit wurden 32 Bit, diese wurden dann einfach mal "dupliziert" um 64 Bit zu erreichen. Ein FSB funktioniert wie schon im 286er, nur mit höherer Geschwindigkeit. Die Input-und Output-Peripherie ist die gleiche geblieben (Tastatur, Maus, Monitor). Warum sollte sich also bei der Programmierung was ändern? Nur weil es jetzt GUIs gibt? Die sind ja auch nur ein Stück Software, das irgendwann mal auf einer Terminal-Basis programmiert wurde. Es mutet da fast schon absurd an, wenn jemand darauf pocht, dass etwas in die heutige Computer-Zeit nicht mehr passt, was vor 15-20 Jahren noch total üblich war. Man könnte eher sagen: Es ist heutzutage nicht mehr notwendig im Terminal zu programmieren, aber unzeitgemäß ist es sicherlich nicht.

__________________

beavisbee

zwecks 80 Zeichen und zeitgemäß:

• Gerade im Bereich Web-Development passiert es auch immer mal, dass irgend ein kleiner Fehler, der übersehen wurde, dann mal schnell per SSH live auf dem Server berichtigt wird (im harmlosesten Falle: irgendwelche Debug-Infos vergessen auszukommentieren, etc.)
• Config-Files auf Linux- und Unix-Systemen werden sicherlich auch von den wenigsten Admins in 'ner grafischen Oberfläche editiert.
• wenn man mal wirklich -DIREKT- am Server arbeitet, hat man mit sehr hoher Wahrscheinlichkeit wirklich nur die 80 Zeichen, denn es macht wenig Sinn, auf 'nem Server, der einfach nur paar Dienste zur Verfügung stellen soll, großartig Grafik einzurichten (und sei es nur der Framebuffer in der Konsole)

b4ck

selbst wenn ich am server schnell etwas ausbessern muss über ssh und dann in der shell hab ich mehr als 80 zeichen zur verfügung. ausser ich arbeite DIREKT am server über einen angeschlossenen Monitor.. und nur für diese Fälle extra ein 80 Zeichen Limit einhalten ist etwas.. naja.. overpowered.

Wenn jemand schonmal mit Doctrine gearbeitet hat und dort Magicfinders verwendet

Bsp:
wenn das ganze dann noch in nur 1ner IF drin steht wirds schon etwas knapp mit den 80 Zeichen


ich denke 80 zeichen machen in shell-scripts oder systemprogrammierung anderer art sicher sinn. In größeren projekten die objektorientiert programmiert werden sollte man das nochmal überdenken.

Ab einer gewissen komplexität von programmen mit 80-85+ Databasetables und mind. 2-3mal sovielen Klassen kommt man mit emac/vim nicht mehr weit ohne code completion. oder.. nur deutlich langsamer.