Ankündigung

Einklappen
Keine Ankündigung bisher.

Mein Micro-FW und der nächste Schritt

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von ParseError Beitrag anzeigen
    Kommentare sind notwendig, aber während man einen Kommentar schreibt, sollte man sich überlegen ob man nicht besser den Code leserlich umschreibt (um den Kommentar kurz zu halten).
    Sehe ich auch so, aber...
    Zitat von ParseError Beitrag anzeigen
    Man sollte den Code möglichst leserlich gestalten und die Kommentare so gering wie möglich halten.
    ... das nicht uneingeschränkt. Wenn man seine Kommentare ordentlich in den Code einfügt, dann wird die Lesbarkeit dadurch nicht verringert. Hier mal ein Extrembeispiel: https://github.com/laravel/laravel/b...trap/start.php Sehr viele Kommentarzeilen aber ästhetisch auf Perfektion getrimmt. Man achte auf die Zeilenlängen. Und ja, das Muster wir über das gesamte(!) Framework hinweg eingehalten.

    Kommentar


    • #17
      Ist jetzt allerdings kein sehr stichhaltiges Beispiel. Weil das quasi nur noch Boilerplate ist und die gesamte Anwendung hinter den Methoden gekapselt 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


      • #18
        Also im Bezug auf Dokumentation würde ich mich da ein wenig der Argumentation von ParseError anschließen. Ich denke, dass man nur das dokumentieren sollte, was der Code selbst nicht erklärt. Dokumentation sollte nie eine schlechte Architektur fixen (benutzbar machen), sondern Konzepte und Entscheidungen beschreiben, die sich mindestens in der Ebene überhalb des Programmcodes befinden. Dokumentation sollte eine "Vogelperspektive" schaffen.

        Kommentar


        • #19
          aktuell bin ich mir nicht mal sicher ob Tr0y die "dokumentation" die auch ihr meint, gemeint hat

          also klar, besser liesbarer code ist besser als veraltete kommentare, aber es interessiert ja auch viele garnicht was in einer methode passiert, eine gute dokumentation ist für mich sowas wie jQuery API, Symfony API, Doctrine API und ich meine nicht die autogenerierten, sondern die mit Texten und beispielcodes.

          oder meinte Tr0y doch die quellcode doku? die sollte lieber nicht zu viele kommentare haben, wenn man dann irgendwann was wichtiges da einträgt

          //DO NOT MODIFY ESLESE EVERYTHING WILL NOT WORK ANYMORE!!1
          $someFlag = 1;

          dann übersieht man es eventuell wegen den anderen kommentaren wie

          //constructor
          public function __construct()
          apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

          Kommentar


          • #20
            PHP-Code:
            /**
             * Tr0y meint das hier
             */
            $canBeEnabled true
            [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


            • #21
              Ich finde den treffendsten Tipp, den man befolgen sollte ist:

              Don't comment what happens, comment why it happens.
              Daran halten und man ist eigentlich immer fein raus. (Abgesehen natürlich von obligatorisch nützlichen Kommentaren wie Rückgabewerte etc.)

              Denn sowas:

              Code:
              // Increase value by 1
              $value++;
              ist einfach hirnrissig, nutzlos, und fördert die Code-qualität absolut garnicht. Besser:

              Code:
              // Increase value to skip the next loop step
              $value++;
              [URL="http://goo.gl/6Biyf"]Lerne Grundlagen[/URL] | [URL="http://sscce.org/"]Schreibe gute Beispiele[/URL] | [URL="http://goo.gl/f2jR7"]PDO > mysqli > mysql[/URL] | [URL="http://goo.gl/jvfSZ"]Versuch nicht, das Rad neu zu erfinden[/URL] | [URL="http://goo.gl/T2PU5"]Warum $foo[bar] böse ist[/URL] | [URL="http://goo.gl/rrfzO"]SQL Injections[/URL] | [URL="http://goo.gl/Q81WJ"]Hashes sind keine Verschlüsselungen![/URL] | [URL="http://goo.gl/2x0e2"]Dein E-Mail Regex ist falsch[/URL]

              Kommentar


              • #22
                Zitat von ApoY2k Beitrag anzeigen
                Code:
                // Increase value to skip the next loop step
                $value++;
                PHP-Code:
                /** continue to next loop step */
                $value++; # ToDo: for -> foreach | $value++ continue 
                [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


                • #23
                  Das wäre dann wieder ein Negativbeispiel. Das würde ich lieber etwa so schreiben:

                  PHP-Code:
                  // Increase value to skip the next loop step
                  $value++; 

                  Kommentar


                  • #24
                    Ich habe Kommentare standardisiert

                    PHP-Code:
                    /** ... */ 
                    Verbleiben im Source
                    PHP-Code:
                    # ... 
                    sind temporär ( und fast ausschließlich ToDo-Hints für die IDE )

                    Ich würde auch kein increase "begründen" sondern per Kommentar nur eine Gruppe von Anweisungen beschreiben in diesem Konkreten Fall.
                    [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