Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Coding Guidelines

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Das Argument kann ich aus praktischer Sicht nachvollziehen, aber nicht teilen; wie so oft, sitzt das Problem demnach vor dem Bildschirm.

    Zitat von fab Beitrag anzeigen
    Nebenbei, inwiefern Leerzeichen in diesem Kontext mehr Semantik haben als Tabs musst du mir mal erklären.

    Ein Tabulator ist ein Abstandshalter und in der Breite frei konfigurierbar; ein Leerzeichen ist ein Satzzeichen. Denke, man kann das ganz gut mit margin in CSS vs.   in HTML vergleichen.

    @mermshaus: den Zusammenhang versteh' ich nicht.

    ned

    Nachtrag: versteh' ich immer noch nicht.

    Kommentar


    • #17
      Denke ich nicht. Im Code ist beides einfach nur ein Whitespace, der Compiler/Interpreter kennt keine Satzzeichen.
      [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
      [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

      Kommentar


      • #18
        Zitat von fab Beitrag anzeigen
        [...] der Compiler/Interpreter kennt keine Satzzeichen.
        Das ist mir schnuppe. Mir geht's um anständig formatierten Code (das war auch das Thema) und nicht, was der Compiler / Interpreter sieht.

        ned

        Kommentar


        • #19
          Stimmt. Dann war das Semantik-Argument aber daneben, Formatierung ist eine reine Syntax-Frage.
          [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
          [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

          Kommentar


          • #20
            Stimmt - aus Sicht des Interpreters. Ansonsten siehe zuvor - ein Leerzeichen hat nunmal eine andere Semantik als ein Abstandshalter. Das zu bezweifeln, heisst... ach ja, die Sache mir   hatten wir ja schon .-)

            ned

            Kommentar


            • #21
              Sorry, aber der Vergleich hinkt. Wenn, dann wäre Tab ebenfalls ein   und echtes Indenting würde sich als automatische Einrückung an der Syntax orientieren, wie es ein margin/padding eben auch an der Dokumentstruktur tut. Wie schon gesagt wurde, nutzen Editoren Festbreitenschriften, da hat eine dynamische Komponente nichts drin verloren.
              Untereinanderliegende Statements kann Tab nur in bestimmten Positionen einrücken, was einigermaßen hahnebüchen ist (und völlig schief geht, wenn die Tabbreite umgestellt wird). Wieso nicht einfach pragmatisch sein? Space sieht immer gleich aus.
              [COLOR="#F5F5FF"]--[/COLOR]
              [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
              [COLOR="#F5F5FF"]
              --[/COLOR]

              Kommentar


              • #22
                Halleluja, hört sich ja an, als würden sich da Softwareentwickler über Logik streiten?

                Space als Indent...funktioniert (Hörensagen) halt gut in einigen 80-Zeichen-Commandline-Editoren, welche sich mit Tabs dabei schwer tun (auch Hörensagen) sollen. ("Hörensagen", da ich das zwar aus meiner Jugend kenne, aber seit 20 Jahren da keinen wirklichen Zeugen mehr abgeben kann)

                Tab als Indent...ist in "modernen" (zeitgemäßen?) Editoren halt beliebig einstellbar. Da kann jeder die Einrückung einstellen die er gewohnt ist, resp. die er am liebsten mag.

                Geht aber doch nicht ums Mögen, wenn grad wir uns über Vor- und Nachteile austauschen, oder?

                Ge tab te Grüße!

                Kommentar


                • #23
                  Zitat von Wolfsblut Beitrag anzeigen
                  Tab als Indent...ist in "modernen" (zeitgemäßen?) Editoren halt beliebig einstellbar. Da kann jeder die Einrückung einstellen die er gewohnt ist, resp. die er am liebsten mag.
                  Der Eine mag das Tab als 6 Spaces interpretiert, der Andere als 4.
                  Muss der Eine zwei Tabs einfügen, um eine 12 Char-Einrückung zu erreichen, verhaut's das Ganze beim Anderen, weil's da plötzlich nur 8 ergibt.
                  Ergo: persönliche Einstellbarkeit schön und gut, für Team-Entwicklung sind Tabs aber einfach nur Sch^^rott.
                  VokeIT GmbH & Co. KG - VokeIT-oss @ github

                  Kommentar


                  • #24
                    Die Sache ist eingentlich Simpel. In Coding-Standards wird "x Leerzeichen" als Standard definiert, weil dieser egal wo ( Editor ) und egal wie ( Übersetzer / Parser / Documentor ) immer gleich interpretiert wird. Tab kann in jedwegen Zwischenstationen andere (Einrückungs-)Nebeneffekte haben.

                    Es gibt auch einige Komponenten in Coding Standards die Tabs garnicht erst implementierten können: 80 Signs per Line !

                    Technisch ist ein Tabulator 1 Zeichen. "Shifting"-Berechnungen ersparen sich die die Standards einfach, indem sie Tabulatoren aussperren und dessen "Standardgröße" garnicht erst festlegen.

                    Man könnte auch strikter sagen: source code is plain text without viewing effects
                    [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                    Kommentar


                    • #25
                      Verzeit mir, dass ist jetzt wirklich nicht persönlich - sondern ein allgemeines (aber doch passendes) Luftmachen.

                      Wir - im Gegensatz zu so vielen in anderen Berufen - zeichnen uns besonders dadurch aus besonders "beweglich" zu sein. Wir machen Dinge normalerweise nicht "weil man es immer so gemacht hat" und können Neues extrem gut akzeptieren, annehmen und es sozusagen relativ schnell assimilieren, wenn nicht sogar die Entwicklung aus uns selbst immer weiter voran treiben.

                      Es sei denn es kommt zu Einrückungen - und da, lest mal selbst die Argumentationen, sieht es genau umgekehrt aus.

                      Der Eine mag das Tab als 6 Spaces interpretiert, der Andere als 4.
                      Muss der Eine zwei Tabs einfügen, um eine 12 Char-Einrückung zu erreichen, verhaut's das Ganze beim Anderen, weil's da plötzlich nur 8 ergibt.
                      Editoren machen genau das Erste möglich, ohne dass das Zweite als Nachteil eintritt. Jeder rückt ein, wie er mag - in dem er seine Einrückung eben einstellt. ein Tab = x spaces.

                      Ja, dazu ist auch eine einfache Konvention nötig, auf die man sich im Team einigen muss - wobei jeder "glücklich" werden könnte. Der eine mit 2 Spaces Einrückung, der andere mit 3, ein weitere mit 4...

                      Das nenne ich einen technisch geschickten Kompromiss zwischen den Verschiedenen Vorlieben - was für eine kleine technische Entwicklung - was für ein großer Schritt...286er zu Pentium.

                      Ihr könntet einfach sagen, die Konvention ist: wir rücken mit 2 Spaces ein Punkt

                      Denn, eine Konvention ist nicht mehr zu diskutieren.

                      Wenn es aber um Vor- oder Nachteile geht, wie etwas sein sollte (Zukunft?), sollten wir etwas "offener" sein, oder?

                      80-Zeichen-Argument...ja, ich schwelge oft in Erinnerungen, wenn ich so einen Quelltext auf meinem 32-Zöller ansehe.

                      Klar, das ist noch etwas zu breit für unsere Zeit...aber 80 Zeichen???

                      Bitte, habt Ihr Eure Grafikkarten noch auf 256 Farben eingestellt, nur weil es einige Puristen geben könnte, die..die..mag man ja gar nicht aussprechen...

                      Wenn, dann Kompromiss, ooooder? Immer hart an der Grenze zur letzen noch behandelbaren vergangen Realität, oder wie ist unser Wahlspruch?

                      ....

                      Ich lasse das Argument, dass einige Editoren (die irgendwie in der Entwicklung, den möglichen Optionen hinterher geblieben sind) ja zu. (oder das jemand dringend Quelltext auf der Kommandozeilen editieren möchte/muss - soll es geben!?) Aber sich dann, wenn man damit schon unbedingt arbeiten muss/möchte, mal an deren Entwickler zu wenden mal Vorsichtig mit der Realität zu winken - das wäre doch mal ein Schritt, als so..so...so..komisch konservativ?

                      Mir fehlen da manchmal die Worte...na, nur ein klein wenig *fggg
                      ...

                      Das ist ähnlich wie mit Javascript-deaktivieren....ich habs mal versucht zu verstehen. Wollte mir zum Testen mal den Motor aus meinem Auto ausbauen lassen, weil damit das Fahren viel sicherer wäre. Mein kleiner Bruder meinte ich sei wohl total bekloppt - vorsichtigeres Fahren wäre wohl sinnvoller...da ja ein Auto ohne Motor...Pferdegespann...man, hat der sich aufgeregt.

                      Manchmal finde ich das ja zum Lachen...manchmal

                      Wir tauschen uns doch nur aus, oder?

                      Verdammt...jetzt erwisch ich mich glatt dabei auch total konservativ zu reagieren...und zwar darin, dass ich schon immer alles in Frage stellte, egal was mal war, mit dem Ziel etwas in Zukunft besser zu machen...

                      So, lasst's raus - mir tat's grad gut

                      Kommentar


                      • #26
                        Was auch immer jetzt Dein Argument ist, Wolfsblut?! „Alle anderen doof“ oder so ähnlich?

                        80 Zeilen-Code macht nicht nur wegen kleinen Bildschirmen SInn, sondern auch, weil Code dadurch übersichtlich bleibt. Auch in Lesetext gibt es optimale Zeichenbreiten, für die nicht grundlos ziemlich ähnliche Werte empfohlen werden.
                        Ich jedenfalls will meinen Qielltext schnell scannen können und dazu gehören zwingend
                        a) überschaubare Zeilenbreiten
                        b) Einrücken gleicher Element: Variablendeklarationen, Funktionsparameter, die nicht mehr auf eine Zeile passen, Sonderzeichen wie Kommas in Arrayanweisungen.

                        Und genau dafür kommst Du nur mit Space als Einrückung weiter. Weil ein Tab eben je nach Einstellung eine andere Breite hat, aber die Breite des Quelltextes nicht dynamisch ist.
                        [COLOR="#F5F5FF"]--[/COLOR]
                        [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                        [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                        [COLOR="#F5F5FF"]
                        --[/COLOR]

                        Kommentar


                        • #27
                          Zitat von Wolfsblut Beitrag anzeigen
                          Editoren machen genau das Erste möglich, ohne dass das Zweite als Nachteil eintritt. Jeder rückt ein, wie er mag - in dem er seine Einrückung eben einstellt. ein Tab = x spaces.

                          Ja, dazu ist auch eine einfache Konvention nötig, auf die man sich im Team einigen muss - wobei jeder "glücklich" werden könnte. Der eine mit 2 Spaces Einrückung, der andere mit 3, ein weitere mit 4...

                          Das nenne ich einen technisch geschickten Kompromiss zwischen den Verschiedenen Vorlieben - was für eine kleine technische Entwicklung - was für ein großer Schritt...286er zu Pentium.
                          Du scheinst mein Argument absolut nicht verstanden zu haben.
                          Öffne mal einen Source mit deinem präferiert eingestellten Editor, der unter ganz anderen Voraussetzungen erstellt wurde.
                          Das sieht nacher aus wie Kraut und Rüben, mit dem keiner arbeiten kann, schließlich wurde der Code für z.B. 4 Spaces formatiert, plötzlich aber mit 6 Spaces dargestellt - da stimmt hinten und vorne keine Formattierung mehr.
                          Aber wozu das diskutieren, soll jeder mit dem glücklich werden, was er hat, ich bleib bei Spaces.
                          VokeIT GmbH & Co. KG - VokeIT-oss @ github

                          Kommentar


                          • #28
                            Zitat von nikosch Beitrag anzeigen
                            Was auch immer jetzt Dein Argument ist, Wolfsblut?! „Alle anderen doof“ oder so ähnlich?
                            Ich hoffe Du löst Dich irgendwann wieder davon. Das bin nicht ich. *liebguck*

                            80 Zeilen-Code macht nicht nur wegen kleinen Bildschirmen SInn, sondern auch, weil Code dadurch übersichtlich bleibt. Auch in Lesetext gibt es optimale Zeichenbreiten, für die nicht grundlos ziemlich ähnliche Werte empfohlen werden.
                            Ich jedenfalls will meinen Qielltext schnell scannen können und dazu gehören zwingend
                            Was "zwingend" bei Quelltext notwendig ist: diesen inhaltlilch zu erfassen. Auf einen Blick - wobei da der Bildschirm in der horizontalen, wie auch der vertikalen die Einschränkung ist.

                            Was gar nicht geht ist: Scrollen; um eine Struktur logisch zu erfassen. Weder h noch v, klar.

                            Da ist ein "zu breit" nur zweitrangig - grad wenn deshalb die hälfte der Logik nach unten aus dem Blickfeld verschwindet.
                            Woher kommt das "zu breit"? Aus dem Druck und Lesegewohnheiten von Usern/Lesern? Entwickler waren da kaum Gegenstand der Untersuchungen, oder?

                            Man kann auch die Struktur unnötig nach nach unten aus dem Blickfeld/Bildschirm schieben...

                            Code:
                            if ()
                            {
                            ..
                            }
                            else
                            {
                            ..
                            }
                            und auch das müsste in diesem Zusammenhang auf den Prüfstand kommen.

                            Lösung: eh alles in Blockelementen schreiben.
                            Ist zusätzlich auch noch ein ähnlicher "Schutz", wie das von dir wirklich gut dargelegte "false == irgendwas".

                            Zu was das "mal Block, mal nicht" so führt, konnte man grad vor ein paar Tagen in dem Anfängerforum lesen.

                            80 Zeichen und wenig Zeilen das ist sicher so oder so nicht etwas, das wir als optimal zum Erfassen von Strukturen bezeichnen würden. 32# und übertrieben lange Zeilen natürlich auch nicht.

                            Sprechende Bezeichner stehen dem aber wieder entgegen.

                            Kompromiss, nicht?

                            a) überschaubare Zeilenbreiten
                            b) Einrücken gleicher Element: Variablendeklarationen, Funktionsparameter, die nicht mehr auf eine Zeile passen, Sonderzeichen wie Kommas in Arrayanweisungen.

                            Und genau dafür kommst Du nur mit Space als Einrückung weiter. Weil ein Tab eben je nach Einstellung eine andere Breite hat, aber die Breite des Quelltextes nicht dynamisch ist.
                            Ich weiß Du schaffst das und werde meinen Irrtum dann peinlich berührt zugeben: Magst Du mir mal ein Beispiel geben, dass ich mit Tabs eingerückt nicht nachbilden kann?

                            Gruß!

                            Kommentar


                            • #29
                              Zitat von G.Schuster Beitrag anzeigen
                              Öffne mal einen Source mit deinem präferiert eingestellten Editor, der unter ganz anderen Voraussetzungen erstellt wurde.
                              Das sieht nacher aus wie Kraut und Rüben, mit dem keiner arbeiten kann, schließlich wurde der Code für z.B. 4 Spaces formatiert, plötzlich aber mit 6 Spaces dargestellt - da stimmt hinten und vorne keine Formattierung mehr.
                              Ich mach das seit...peinlich...seit...rechne....31 Jahren *aua*

                              Und ich hab noch nie einen (projektfremden) Quelltext geöffnet, ohne ihn zu formatieren. Ob da nun Tabs oder Spaces waren, ist mir ziemlich schnuppe - wobei (komm, dass ist wie bei den ersten Videorekordern: wer brauchts), ich das mal eben formatieren mit Tabs ziemlich easy finde.

                              Aber wozu das diskutieren, soll jeder mit dem glücklich werden, was er hat, ich bleib bei Spaces.
                              Ja, so können wir das halten. Zur Not stellt man halt im Editor ein was gewünscht ist.

                              Blöd wird es ja immer nur, wenn wir darüber reden.

                              Gruß!

                              Kommentar


                              • #30
                                Es gibt keinen Grund Tabulatoren zu nutzen, aber es reicht wenn du die Tabulator-Taste zum Einrücken nutzt und deinem Editor deiner Wahl sagst das er statt Tabulator Symbole dort eine Standartisierte Menge an Leerzeichen einparken soll. Danach muss niemals wieder irgend jemand den Sourcecode formatieren.

                                Grundlegend tust du das ganze ja nicht nur für dich, sondern für die Jungs die nach dir dran arbeiten. Wenn du eine Vorliebe zur Code-Einrückung hast und dein Source in Fort Knox gehostet wird wo nie wieder einer dran arbeitet außer dir, gut. Sonst eher: Fail. Sourcecode should be easy to read and at most easy to maintain.
                                [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                                Kommentar

                                Lädt...
                                X