Ankündigung

Einklappen
Keine Ankündigung bisher.

Weniger schlecht PHP programmieren

Einklappen

Neue Werbung 2019

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

  • Weniger schlecht PHP programmieren

    Hi, habe in den letzen Tagen nachfolgenden Blog-Post zusammengeschrieben, in welchem ich versucht habe einige PHP-Standards für Variablennamen, Namespaces, git-commits, etc. zusammenzutragen.

    Wenn jemand diesbezüglich weitere Anregungen, Verbesserungen oder Korrekturen hätte, wäre ich sehr dankbar!

    suckup.de/howto/php-howto/weniger-schlecht-php-programmieren/

    Mfg Lars


  • #2
    Da fehlt soweit ich das sehe PSR-4.
    [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


    • #3
      Zitat von tr0y Beitrag anzeigen
      Da fehlt soweit ich das sehe PSR-4.
      Jup, war auch enttäuscht darüber.

      Ansonsten sieht es beim drüberfliegen ganz in Ordnung aus.
      Zitat von nikosch
      Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

      Kommentar


      • #4
        Ich tendiere aktuell eher zum tl;dr-Status. Vielleicht sollte man überlegen das ganze nicht in mehrere Teile zu splitten.
        [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


        • #5
          Zitat von tr0y Beitrag anzeigen
          Ich tendiere aktuell eher zum tl;dr-Status. Vielleicht sollte man überlegen das ganze nicht in mehrere Teile zu splitten.
          Das hatte ich mir gestern Nacht auch schon gedacht ... und ggf. wären die einzelnen Teile in einem Wiki besser aufgehoben?! Hat jemand eine Empfehlungen zur Wiki-Software?

          Kommentar


          • #6
            Zitat von tr0y Beitrag anzeigen
            Da fehlt soweit ich das sehe PSR-4.
            Werde ich noch ergänzen ... zudem ist mir aufgefallen, dass es momentan noch keine deutsch Übersetzung auf github gibt -> https://github.com/php-fig/fig-stand...aster/accepted <- ggf. könnte man diese beiden Aufgaben miteinander verbinden

            Kommentar


            • #7
              Theoretisch könntest du das auch da rein setzen: http://php-de.github.io/
              [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


              • #8
                FALSCH RICHTIG Erklärung
                Cui bono? Vielleicht sollte unter „Erklärung“ auch ne Erklärung stehen, keine Beschreibung des Offensichtlichen.

                Einige Punkte sind arg pauschal, obwohl sie von den Gegebenheiten abhängen. Anderen würde ich direkt widersprechen:
                keine Verneinung verwenden!!!
                Vielleicht meinst Du das richtige, das Beispiel ist aber falsch. FALSE kann durchaus ein sinnvoller Defaultwert sein, weil eine nicht gesetzte Variable hier mit Notice zum Default evaluiert.

                wenn möglich kein Plural für Variablen verwenden ;
                Warum? Warum sollte ich eine Liste von Kunden „Customer“ nennen. Gerade wenn ich nicht erkenne, ob das ein Array ist?! Btw., weiter unten:
                foreach ($pages as $pageID => $page)
                length_in_mm,delay_seconds
                naviPageEdit
                Sorry, aber man sollte sich schon für einen Schreibstil entscheiden.

                Der Sinn der Variable ist es, die Navigation oder den Inhalt zu beinhalten.
                Und wenn der Inhalt dynamisch verwaltet und zugeordnet wird? Und warum eigentlich benennen und nicht durchnumerieren?

                setHeadlineFontColorToRed() highlightHeadline(‘red’) Wir beschreiben im Funktionsnamen nicht wie wir die Überschrift hervorheben, sondern dass wir dies überhaupt machen.
                Nee, das machen wir nicht. Das eine tut das Eine und das andere das Andere und erlaubt sogar einen Parameter. Äpfel und Birnen.

                - 1 Wort für Zustands- / Schleifenvariablen (z.B.: $active, $hidden, $boolean)
                Ehrlich jetzt?
                - 1-3 Wörter für lokale Variablen in Methoden / Funktionen (z.B.: $string, $linkText, $teaserTextType)
                - 1-2 Wörter für Methoden (z.B.: isActive(), isHidden(), isTrue(), send())
                gintKundenID $customer->getID() global Integer “KundenID”
                Achte Du doch bitte erst mal um eine konsistente Verwendung von Variablen vs. Methoden

                Zuerst sollte geklärt werden, was Global heißt. Innerhalb von PHP kann jede Variable welche nicht innerhalb einer Funktion oder Klasse ausgelagert ist „global“ gesetzt / genutzt werden. Benötigt man diese Variablen in einem anderen Kontext (z.B. innerhalb einer Methode) kann man (sollte man jedoch nicht machen) dies mit dem Befehl „global $lall“ zugänglich machen. In den meisten Fällen tut man sich damit jedoch keinen Gefallen, da jemand anderes (oder man selbst) ggf. nicht weiß dass die Variable „$lall“ nun nicht mehr verwendet werden darf, da man diese nun in irgendeiner Methode global setzt hat.
                Mit Verlaub - da hast Du ein Verständnisproblem.


                .
                .
                .
                --

                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                --

                Kommentar


                • #9
                  Zitat von nikosch Beitrag anzeigen
                  Cui bono?
                  Cum hoc ergo propter hoc!

                  Zitat von nikosch Beitrag anzeigen
                  Vielleicht sollte unter „Erklärung“ auch ne Erklärung stehen, keine Beschreibung des Offensichtlichen.
                  Ggf. hilft es jemandem jedoch weiter, wenn man Ihn auf das Offensichtliche aufmerksam macht ...

                  Zitat von nikosch Beitrag anzeigen
                  Einige Punkte sind arg pauschal, obwohl sie von den Gegebenheiten abhängen.
                  ... da gebe ich dir Recht, jedoch sind dies auch nur Beispiele, welche komplett aus dem Kontext gerissen sind. Wie man die Benennung von Variablen letztendlich genau vornimmt muss jeder selbst entscheiden, aber ich glaube die Intension ("Gute Namen beschreiben was der Sinn dieser Variable ist und Funktionen sollten beschreiben was diese tun und nicht wie dies programmiert sind.") wird deutlich.

                  Zitat von nikosch Beitrag anzeigen
                  Anderen würde ich direkt widersprechen:
                  Vielleicht meinst Du das richtige, das Beispiel ist aber falsch. FALSE kann durchaus ein sinnvoller Defaultwert sein, weil eine nicht gesetzte Variable hier mit Notice zum Default evaluiert.
                  Text wurde angepasst -> "keine Verneinung in Variablennamen verwenden!!!"

                  Zitat von nikosch Beitrag anzeigen
                  Warum? Warum sollte ich eine Liste von Kunden „Customer“ nennen. Gerade wenn ich nicht erkenne, ob das ein Array ist?! Btw., weiter unten:
                  Warum, sollte ich nicht erkennen, ob es sich um ein Array handelt? Ich bin davon ausgegangen, dass man erkennt, dass es sich bei "Customer" [$customer = new Customer()] um ein Objekt handelt, welches wiederum entsprechende Methoden implementiert hat, um z.B. die Kunden-ID [$customer->getID()] zu erhalten.

                  Zitat von nikosch Beitrag anzeigen
                  Sorry, aber man sollte sich schon für einen Schreibstil entscheiden.
                  ?

                  Zitat von nikosch Beitrag anzeigen
                  Und wenn der Inhalt dynamisch verwaltet und zugeordnet wird? Und warum eigentlich benennen und nicht durchnumerieren?
                  Dann würde ich ebenfalls via Integer iterieren ... aber ich habe dies Beispiel gewählt, damit man direkt sieht, wie es das lesen des Quelltextes verbessert, wenn man die Variablen entsprechend benennt, daher glaube ich das auch hier die Intension ("Variablen müssen immer Aussagekräftig sein!") ankommt.

                  Zitat von nikosch Beitrag anzeigen
                  Nee, das machen wir nicht. Das eine tut das Eine und das andere das Andere und erlaubt sogar einen Parameter. Äpfel und Birnen.
                  sprichst du von folgendem Beispiel: "setHeadlineFontColorToRed()" vs "highlightHeadline('red')" ? -> wenn dem so ist, warum Äpfel und Birnen? Die eine Funktion setzt die H1-Font-Color und die zweite Funktion tut genau das selbe!?

                  Zitat von nikosch Beitrag anzeigen
                  Ehrlich jetzt?
                  Nein?

                  Zitat von nikosch Beitrag anzeigen
                  Achte Du doch bitte erst mal um eine konsistente Verwendung von Variablen vs. Methoden
                  Habe den Text soeben noch einmal überflogen, konnte jedoch die Stellen, wo ich "Variablen" und "Methoden" verwechselt habe nicht finden, kannst du mir bitte die entsprechenden Stellen nennen, damit ich diese beheben kann, danke!

                  Zitat von nikosch Beitrag anzeigen
                  Mit Verlaub - da hast Du ein Verständnisproblem.
                  Ggf. habe ich mich hier nicht deutlich ausgedrückt, jede Variable kann in PHP "global" gesetzt werden, so dass man diese ohne Übergabeparameter oder Rückgabewert in oder aus einer Funktion (Methode) bekommt ... man sollte dies jedoch nicht tun, da jemand anderes diese entsprechende Variabel nicht mehr nutzen sollte (kann), man diese jedoch nicht als solche (global) Variable erkennt.

                  Code:
                  //inc_global.php
                  
                  [...]
                  $pageID = filter_input(INPUT_POST, 'pageID', FILTER_SANITIZE_NUMBER_INT);
                  [...]
                  
                  //inc_function.php
                  
                  [...]
                  checkPageID() {
                    global $pageID;
                  
                    if ($pageID <= 0) {
                      $pageID = 1;
                    }
                  }
                  [...]
                  
                  //article_template.php
                  
                  require_once inc_global.php;
                  require_once inc_function.php;
                  
                  foreach ($page->getSubPages() as $subPage) {
                    foreach ($subPage as $pageID => $page) {
                      [...]
                    }
                  }
                  Die Variable "$pageID" dürfte man in diesem Fall nicht mehr verwenden ... oder sehe ich da irgendwas falsch?

                  Mfg Lars

                  Kommentar


                  • #10
                    Vom Inhalt mal ganz abgesehen: Warum titelt man mit "weniger schlecht"? "besser" ist kürzer, klingt besser und ist auch motivierender. Der logische Schluss bei deinem Titel ist, das man danach zwar weniger schlecht, aber immer noch schlecht programmiert.

                    Kommentar


                    • #11
                      Zitat von Tropi Beitrag anzeigen
                      Vom Inhalt mal ganz abgesehen: Warum titelt man mit "weniger schlecht"? "besser" ist kürzer, klingt besser und ist auch motivierender. Der logische Schluss bei deinem Titel ist, das man danach zwar weniger schlecht, aber immer noch schlecht programmiert.
                      Habe den Titel angelehnt an meine Buch Empfehlung "Weniger schlecht programmieren" gewählt ...

                      Kommentar


                      • #12
                        Warum, sollte ich nicht erkennen, ob es sich um ein Array handelt? Ich bin davon ausgegangen, dass man erkennt, dass es sich bei "Customer" [$customer = new Customer()] um ein Objekt handelt, welches wiederum entsprechende Methoden implementiert hat, um z.B. die Kunden-ID [$customer->getID()] zu erhalten.
                        Er meint wohl eher ein Kundenarray. Und wieso du aus einem Array auf einmal ein Objekt machst, verstehe ich auch nicht. Wenn in einem Array oder Objekt mehrere Kunden enthalten sind, würde ich es customers nennen.

                        Worte für Zustands/Schleifenvariablen, Funktionsnamen
                        Dein Beispiel mit $boolean usw. ist nicht so toll. Schau dir mal die ungarische Notation an. Finde ich weit sinnvoller. Da hast du zum einen immer eine Erläuterung welcher Datentyp zu erwarten ist, und zum anderen erklärt die Variable noch Ihre Bestimmung.
                        Ich kenne aber auch viele Php Entwickler, die ungern Großbuchstaben in Variablen verwenden..


                        Ggf. habe ich mich hier nicht deutlich ausgedrückt, jede Variable kann in PHP "global" gesetzt werden, so dass man diese ohne Übergabeparameter oder Rückgabewert in oder aus einer Funktion (Methode) bekommt ... man sollte dies jedoch nicht tun, da jemand anderes diese entsprechende Variabel nicht mehr nutzen sollte (kann), man diese jedoch nicht als
                        Hätte/Könnte/Sollte

                        Grundsätzlich richtig. Manchmal lässt es sich aber nicht vermeiden.. Insbesondere wenn du oft mit Fremdsystemen arbeiten (musst), die schon etwas älter sind. Einfach etwas vorsichtig walten und schalten. In solche. Fällen empfiehlt es sich, Variablen und Funktionen ein eigenes Kürzel voranzustellen. Ich mach das bspw. so: mv_bSet = true;


                        -------------------

                        Und jetzt noch etwas allgemeines:

                        Ist gut das du dir Gedanken zu dem Thema machst. Wenn du in Gruppen arbeitest ( und das ist ja hier deine Itention, sonst könntest du schreiben wie du willst), dann wirst du dich immer der Gruppensyntax anpassen müssen. Bzw. findet die Gruppe einen gemeinsamen Context. Oft stößt man zu gewachsenen Projekten. Da bleibt dann nicht die Zeit, den Quelltext den eigenen Präferenzen anzupassen. Da kann man nur flexibel reagieren und Vorschläge für Quelltextfornatierungen machen, die umgesetzt werden wenn sowieso jemand an einem Stück Code arbeiten muss.

                        Mich regt es immer auf, wenn jemand in if Anweisungen und Schleifen die öffnenden geschweiften Klammern in neue Zeilen schreibt oder die geschweiften Klammern ganz weglässt. Trotzdem habe ich gelernt damit zu Leben. Ich merke es oft an, lasse aber keinen Streit darüber entbrennen.

                        Übrigens arbeite ich von Magento (MVC) über Wordpress bis hin zu XTC und noch älteren Systemen. Jedes davon hat sein eigenes Schema, das ich so gut wie möglich Versuche beizubehalten.

                        Kommentar


                        • #13
                          Ich unterstütze auch größtenteils, was nikosch angesprochen hat.

                          Zitat von voku1987
                          ... da gebe ich dir Recht, jedoch sind dies auch nur Beispiele, welche komplett aus dem Kontext gerissen sind. Wie man die Benennung von Variablen letztendlich genau vornimmt muss jeder selbst entscheiden, aber ich glaube die Intension ("Gute Namen beschreiben was der Sinn dieser Variable ist und Funktionen sollten beschreiben was diese tun und nicht wie dies programmiert sind.") wird deutlich.
                          Du schwächst durch die Beispiele da meines Erachtens schon diese Aussage unnötig ab. Eben auch dadurch, dass der Kontext fehlt. Warum die „richtige“ Variante besser ist, ist nicht immer wirklich nachzuvollziehen.

                          sprichst du von folgendem Beispiel: "setHeadlineFontColorToRed()" vs "highlightHeadline('red')" ? -> wenn dem so ist, warum Äpfel und Birnen? Die eine Funktion setzt die H1-Font-Color und die zweite Funktion tut genau das selbe!?
                          Dass die Schriftfarbe gemeint ist, ist aus dem zweiten Funktionsnamen überhaupt nicht ersichtlich. Zudem haben set und highlight eine unterschiedliche Bedeutung. Bei set erwarte ich, dass eine Instanzvariable auf einen Wert gesetzt wird, bei highlight erwarte ich, eine entsprechend bearbeitete Rückgabe zu erhalten.

                          Die passendere Verbesserung wäre vielleicht setHeadlineFontColor($color) oder setHeadlineFont(Font $font) oder setHeadlineStyle(Style $style) oder ganz anders.

                          Warum, sollte ich nicht erkennen, ob es sich um ein Array handelt?
                          Da bezog sich nikosch auf „wenn möglich kein Plural für Variablen verwenden“. Wenn du eine Liste von Kunden hast, sollte die $customers heißen und nicht $customer. Du schreibst – siehe nikosch – später ja selbst $pages.

                          Zitat von nikosch
                          Ehrlich jetzt?
                          Nein?
                          Gemeint ist etwa die Variable mit dem nichtssagenden Namen $boolean. Und Ja: Nein. Nenn das Ding $flag, wenn es so generisch sein muss. Dann weiß man zumindest, welche Funktion die Variable hat.

                          Die Variable "$pageID" dürfte man in diesem Fall nicht mehr verwenden ... oder sehe ich da irgendwas falsch?
                          Siehst du richtig. Globale Variablen sollten (aus verschiedenen Gründen) optimalerweise gar nicht genutzt werden. Das schreibst du ja glaube ich auch so.

                          * * *

                          Eigene Bemerkungen zum Artikel:

                          Was ist eigentlich ein „lall“?

                          Einige Namen sollte man einfach aus seinem Wortschatz streichen: value, key, equals, data, lall, foo, bar, temp, tmp, x, xx, xxx, variable, var, arr, thing, stuff, bla, this, that, something, whatever, dummy, one, two, tree …
                          value, key, equals, data, temp, tmp, x, var, arr, dummy finde ich akzeptabel, wenn auch teilweise situativ. An this kommt man bei Objekten halt nicht vorbei, aber das meinst du sicher anders.

                          Wenn man länger über den Namen für z.B. eine Methode nachdenken muss, ist dies ein Indiz dafür, dass man den Zweck dieser Methode noch nicht korrekt durchdacht hat und dass man diese Methode ggf. noch weiter aufteilen kann / sollte.
                          Das ist gut. Ich merke aber der Einfachheit halber mal nur die Sachen an, bei denen ich was zu meckern habe.

                          foreach ($pages as $key => $value)
                          Generischen Code im Sinne von foreach ($array as $key => $value) halte ich nicht für undenkbar. Auch hier wieder ein wenig eine Frage des Kontexts.

                          Ausnahmen bei gängigen Abkürzungen:
                          Ich weiß, das läuft jetzt vom Hundertsten zum Tausendsten, aber es kann auch sinnvoll für die Lesbarkeit sein, eine Variable einfach mal $x1 zu nennen statt $outerRectanglePointTopLeftX. Sonst werden vor allem Berechnungen völlig unlesbar, weil du nur noch Latten von Buchstaben siehst.

                          Ich habe auch kein großes Problem mit $em = $obj->getEntityManager() oder $mf = $obj->getMetadataFactory(), auch wenn ich doch eher die Langversion nutze. Wenn $em oder $mf im Kontext missverständlich sein sollten, spricht ohnehin viel dafür, dass die Methode die falsche Aufgabe hat.

                          - 1-2 Wörter für Interface [wenn Namespaces verwendet werden] (iCache, iAdapter)
                          Vorsicht, da könnten Leute Copyrights drauf haben.

                          Auch wenn ich dies irgendwann mal in der Schule gelernt habe, solle man Namen nicht mit Tags / Suffixes versehen.
                          Ja, gut, deine Argumentation dazu ist aber auch wieder etwas Äpfel und Birnen. Ein g-Präfix (für die globale ID eines Kunden oder so) ist nicht deshalb schlechter als $customer->getId(), weil es ein Präfix hat, sondern weil die Kapselung gegenüber einer globalen Variablen sicherlich das bessere Konzept ist.

                          Gegen etwas wie $sTitle = $obj->getTitle() (oder auch $strTitle) spricht eigentlich wenig, denn die Zeile liefert uns mehr Informationen als ein reines $title. (Satzende. ) getTitle() könnte ja theoretisch ein Objekt liefern.

                          Mehr dazu weiter unten zu soundFXon. Deinem Argument mit den IDEs stimme ich zu.

                          [Der gesamte Abschnitt.] […] Zudem sieht man im Quellcode einer Variable nicht an, dass diese global ist und dass man diese nicht einfach verwenden / verändern darf.
                          Eine Empfehlung dazu kann sein, nicht global zu verwenden, sondern immer $GLOBALS. Der beste Rat ist es aber, so was einfach mal komplett zu lassen und nach Möglichkeit auch nicht im globalen Namensraum zu programmieren, sondern Klassen oder zumindest Funktionen zu schreiben.

                          Eigentlich sollte man keine der superglobalen Variablen irgendwo aus der Luft fischen, sondern sie etwa immer schön als Parameter reinreichen. Die Ausnahme sind Klassen, die etwa speziell dafür gedacht sind, einen Request zu kapseln (was ein gutes Konzept ist).

                          Man sollte auch nicht in Superglobals schreiben, zumindest nicht in etwas komplexerem Code.

                          Zudem habe ich bisher keine Anforderung gesehen, welche man nicht ohne Globale-Variablen lösen könnte: z.B. via Übergabeparameter, Vererbung von Klassen, Singleton-Klassen, ausgelagerte „Konfiguration“ in einer separaten Datei und vieles mehr.
                          Zustimmung, wobei Singletons im Grunde auch zu global state zu zählen sind.

                          - http://misko.hevery.com/2008/08/25/r...of-singletons/
                          - http://programmers.stackexchange.com...-state-so-evil (sah auf den ersten Blick auch gut aus, aber nur überflogen)

                          2.) Kommentare
                          Bitte einfach „2) Kommentare“.

                          Kommentare müssen, wie die bisher erwähnten allgemeine Namensgebung in englisch geschrieben werden
                          Dazu ein klares Jain. Deine Argumentation ist nachvollziehbar und ich kenne das Problem. Ich kenne aber auch das Problem, dass es manchmal hemmt, Englisch zu nutzen. Dein Artikel ist zum Beispiel auf Deutsch. Also, ich würde das als Empfehlung formulieren (dein Argument ist stichhaltig), nicht als „Muss“.

                          Falsch
                          // salutation can be Herr/Frau or 1/2

                          Richtig
                          // set the salutation

                          Erklärung
                          (ggf. kann man diesen Kommentar auch ganz entfernen)
                          Äpfel und Birnen again. Bei allen drei Beispielen. Der erste Kommentar beschreibt hier etwa offenbar, welche Werte zulässig sind. Das ist durchaus auch eine wichtige Funktion. Kann aber sein, dass das an der falschen Stelle steht. Auch dort fehlt sicherlich wieder etwas der Kontext.

                          „TODO“-Kommentare sollten immer mit „TODO“ anfangen und vor dem Nächten Release beseitigt werden.
                          Dein Wort in…

                          Quellcode sollte nicht einfach nur auskommentiert werden, wenn dieser nicht mehr benötigt wird, sondern direkt gelöscht werden, da das Versionskontrollsystem sowieso jeder Version des Projektes beinhaltet und der Quellcode somit nicht verloren gehen kann.
                          Da kommst du jetzt vom Hundertsten zum Tausendsten.

                          Einerseits hat jeder seine Vorlieben, andererseits muss man sich auf einen Standard einigen, da man ansonsten z.B. ständig Merge-Konflikte hervorruft und das Refactoring unmöglich gemacht wird.
                          Hihi. Reformatierungskriege.

                          Nachdem man sich auf einen Standard geeinigt hat sollte man die Änderungen der Formatierung automatisch per IDE ausführen lassen.
                          Das funktioniert meiner Erfahrung nach theoretisch besser als praktisch. Whitespace am Zeilenende (den sollte man entfernen lassen) und Tabs/Spaces am Zeilenanfang kriegt man damit sicherlich aufgelöst, aber diese Coding-Standards und dazugehörige Algorithmen machen aus

                          PHP-Code:
                          $mask = [
                              
                          1111,
                              
                          1001,
                              
                          1001,
                              
                          1111
                          ]; 
                          zu gerne irgendeinen Unsinn.

                          Bei komplexeren Problemen ist es immer hilfreich, dass Problem im kleinen Nachzustellen.
                          Auch wenn sich das Buch an vielen Stellen direkt an Programmieranfänger richtet, findend man doch einige Beispiele welche man direkt in der täglichen Arbeit umsetzten kann.
                          Du hast in deinem Text noch etliche Tipp- und Grammatikfehler. Ist vielleicht müßig, das zu sagen (sorry), aber da würde ich noch mal drübergehen.

                          PS: Am besten kauft man solche Bücher direkt beim Verlag und nicht bei z.B. Amazon.
                          Daumen hoch, auch wegen Monopolstellung.

                          Das waren jetzt so einige Anmerkungen, aber insgesamt enthält dein Artikel viele richtige Dinge und bietet vor allem auch einen guten Überblick zu „Toolchain“-Aspekten (git, xdebug). Das finde ich in jedem Fall positiv hervorzuheben. Auch die Links und Quellen finde ich prima, auch wenn ich die jetzt nicht durchgeklickt habe.

                          (Weil ich gerade noch dran denke: Ob man die Inhalte von PSRs und dergleichen in einem ohnehin schon langen Artikel noch mal reproduzieren muss, wäre vielleicht noch eine Frage. Pragmatisch gesagt: Wer den langen Artikel komplett liest, klickt im Zweifel sicher auch Verlinkungen an. Da kann man vielleicht inhaltlich noch etwas raffen, wenn ich jetzt aber spontan auch nicht weiß, wie das geschickt zu machen wäre. Eine kurze Zusammenfassung der Inhalte ist ja auch nicht schlecht.)

                          * * *

                          Zitat von soundFXon
                          Schau dir mal die ungarische Notation an. Finde ich weit sinnvoller. Da hast du zum einen immer eine Erläuterung welcher Datentyp zu erwarten ist, und zum anderen erklärt die Variable noch Ihre Bestimmung.
                          Ich kenne aber auch viele Php Entwickler, die ungern Großbuchstaben in Variablen verwenden..
                          Das ist halt Konvention/Geschmackssache. Ich persönlich habe nichts gegen ungarische Notation, aber halte sie für übertrieben – vor allem dann, wenn auch noch DocBlocks genutzt werden.

                          Und jetzt noch etwas allgemeines:
                          +1, schreibt voku1987 auch nicht anders.

                          Kommentar


                          • #14
                            Wie ich schon oben anführte, hätte der ganze Blog-Post potential ( nach Verbesserung und Gliederung in einzelne eigene Code Quality Themen ) unsere Wissensbibliothek zu bereichern. Dort findest du vielleicht auch schon den ein oder anderen Beitrag der deinem jetzigen Content als Inspiration dienen könnte.

                            Vom Stand der Dinge her bin ich voll und ganz bei nikosch und mermshaus.
                            [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


                            • #15
                              Da hier nun viel geschrieben wurde weiß ich nicht ob es schon aufgegriffen wurde, aber hier noch eine Kleinigkeit: Statt startTimerGlobal schlägst du GLOBALS['startTimerGlobal'] vor, dann wäre GLOBALS['startTimer'] aber konsequent.

                              Kommentar

                              Lädt...
                              X