Ankündigung

Einklappen
Keine Ankündigung bisher.

Wie wichtig ist schoen bzw elegant?

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von Arne Drews Beitrag anzeigen
    Man sollte sich aber nicht alles vorschreiben lassen, sondern aus den verschiedenen Definitionen für sich und sein Team sinnvolles rausziehen oder eigene Definitionen vorgeben.
    Folgendes einfaches Statement führt schon zu vielen unterschiedlichen Fragen:
    [...]
    So wie es oben steht, schreibe ich das und finde das sehr übersichtlich. Das mögen andere anders sehen, ist aber genau deswegen ein schönes Beispiel dafür, dass man sich nicht verrückt machen soll.
    Die Standards kann man sich ja anschauen, sollte aber selber für sich schauen, was sinnvoll erscheint oder nicht.
    Ein "eigener" Codingstyle ist überflüssig. Der Codingstyle hat letztendlich weder auf die Produktivität noch Lesbarkeit ein Einfluss. Ob da eine Leertaste oder Zeilenumbuch mehr oder weniger drin ist, ist völlig Latte. Das ist alles nur Gewöhnungsache. Nimm PSR 1,2, 12 oder was auch immer grade hip ist und fertig. Mit PSR hast du:
    -eine (fast) fertige Dokumentation
    -fertige Regeln für alle Tools (teilweise leider etwas inkonsistent)
    -quasi alles was du mit Composer einbindest sieht so aus
    -andere Entwickler haben den Codestyle ggf. schon intus und wenn nicht siehe 1.
    -das nächste PHP Projekt mit bestehenden Code was du auf den Tisch bekommst, sieht vielleicht auch schon so aus

    Auch wenn der PSR Codingestyle aus dem Würfelbecher kommt und das teilweise erkennbar ist. Und Leertasten statt Tabs zum Einrücken verwendet werden. (furchtbar!) Es spielt letztendlich keine Rolle. Ein einheitlicher Codestyle bringt handfeste Vorteile. Zum Preis von 2, 3 Wochen umgewöhnen und eine "Stunde" um bestehende Projekte zu konvertieren.

    Zitat von hellbringer Beitrag anzeigen
    Ist die Funktion genial? Ziemlich sicher. Aber ist sie elegant? Wäre sie überhaupt elegant umsetzbar?
    Mit einem WTF als Kommentar disqualifiziert sich der Code aber auf jedenfall für "elegant". Die Funktion ist aber nicht ohne Grund so bekannt. Ein Teil der Funktionalität versteckt sich hinter der Konstanten. Das ist eine Blackbox. Um zu verstehen wie die Funktion arbeitet, musst du wissen wie du auf die Konstante kommst.

    Kommentar


    • #17
      Zitat von erc
      Ein "eigener" Codingstyle ist überflüssig. Der Codingstyle hat letztendlich weder auf die Produktivität noch Lesbarkeit ein Einfluss. Ob da eine Leertaste oder Zeilenumbuch mehr oder weniger drin ist, ist völlig Latte. Das ist alles nur Gewöhnungsache.
      Klar ist das Gewöhnungssache. Aber Einrückung & Co. haben nichts mit Lesbarkeit zu tun?! Willst Du die Aussage vielleicht nochmal überdenken?

      Zitat von erc
      Nimm PSR 1,2, 12 oder was auch immer grade hip ist und fertig.
      ...und schon sind wir wieder dabei, jeden in eine Schublade stecken zu wollen.
      Nichts gegen die PSRs, die machen durchaus Sinn, aber zwingend notwendig sind sie nicht. Wenn man sich bemüht, seinen Code anständig aufzubauen, wundert man sich, wie dicht man am Ende eh an diesen PSRs liegt
      Aber 100% übernehmen muss ich die nicht.
      Competence-Center -> Enjoy the Informatrix
      PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

      Kommentar


      • #18
        Zitat von Arne Drews Beitrag anzeigen
        Klar ist das Gewöhnungssache. Aber Einrückung & Co. haben nichts mit Lesbarkeit zu tun?! Willst Du die Aussage vielleicht nochmal überdenken?
        Nein. Was für ein Unterschied macht es ob da zwei, vier oder acht Leerzeichen stehen? Was für ein Unterscheid macht es ob { in der selben oder extra Zeilen stehen? Was für ein Unterscheid macht es ob da irgendwo ein Leerzeichen mehr oder weniger steht? Und so weiter... spielt das deiner Meinung nach wirklich eine Rolle für die Lesbarkeit? In meinen Augen hat das keinen Einfluss drauf.

        Ein einheitlicher Code Style für eine Sprache, der von der Masse genutzt wird, bringt handfeste Vorteile. Was bringt dagegen ein eigener Code Style? Die Frage kann jeder für sich selbst beantworten.

        Kommentar


        • #19
          Zitat von erc
          spielt das deiner Meinung nach wirklich eine Rolle für die Lesbarkeit?
          PHP-Code:
          $a = [];
          while(
          $d=$s->fetch()){
          if(
          strlen($d->EmptyReturn)>5){
          $a[]=$d->EmptyReturn;}

          vs.
          PHP-Code:
          $a = [];

          while ( 
          $d $s->fetch() )
          {
              if ( 
          strlen($d->EmptyReturn) > )
              {
                  
          $a[] = $d->EmptyReturn;
              }

          Für mich macht das einen Unterschied in Sachen Lesbarkeit...
          Ob ich mit zwei oder vier Leerstellen einrücke nicht zwingend, da hast Du recht, aber auch nur solange, wie man andere Dinge berücksichtigt.
          Competence-Center -> Enjoy the Informatrix
          PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

          Kommentar


          • #20
            Na ja, das Beispiel wäre eher vielleicht so was wie…

            Code:
            $a = [];
            
            while ($d = $s->fetch()) {
              if (strlen($d->EmptyReturn) > 5) {
                $a[] = $d->EmptyReturn;
              }
            }
            …und so was wie…

            Code:
            $a = [];
            
            while ($d = $s->fetch())
            {
                    if (strlen($d->EmptyReturn) > 5)
                    {
                            $a[] = $d->EmptyReturn;
                    }
            }
            Davon ist jetzt nichts wirklich unlesbar.

            Für mich war in Formatierungsfragen prettier eine echte
            Entdeckung.

            Das wirft (grob gesagt, stimmt in Details nicht ganz) einmal allen Whitespace
            raus und formatiert dann von Grund auf neu, und das, was dabei rauskommt, hat
            man dann halt. Egal, welche IDE oder welchen Editor man nutzt.



            (Edit: Für Markdown→BBCode: Der Converter hier geht halbwegs… https://feralhosting.github.io/)

            Kommentar


            • #21
              Das zeigt aber sehr schön, warum ich der Meinung bin, niemanden in Standards zwängen zu müssen, denn lesbar ist subjektiv!
              Deine zweite Variante ist meiner zweiten sehr ähnlich und ich finde sowas sehr gut lesbar.
              Competence-Center -> Enjoy the Informatrix
              PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

              Kommentar


              • #22
                So wirklich zu ner Issue wird so was natürlich auch erst, wenn man mit anderen
                Leuten zusammenarbeitet.

                Wenn du VS Code nutzt und ständig, wenn du deinen Autoformat-Shortcut drückst,
                die Datei vom Kollegen umformatierst. Wenn der Kollege mit PhpStorm sie dann
                wieder bearbeitet und seinen Autoformat-Shortcut drückt, wird wieder alles
                anders. Noch ein Kollege nutzt dann vim und hat wieder andere Settings. Das kann
                im Versionskontrollsystem schon ziemlich nervig werden. Völlig synchron bekommt
                man das editorspezifisch kaum.

                Da hilft ein unabhängiges, globales Tool, das in jedem Editor einbindbar ist, in
                jedem Fall weiter. Das löst auch so Probleme wie: „Du musst Editor XY benutzen,
                weil wir für den die passende Coding-Style-Config hinterlegt haben.“ Gerade bei
                PhpStorm ist das schon ne Form von Lock-in.

                Und prettier unterstützt von Haus aus eine Menge Formate. Ich nutze es
                inzwischen so grob für JSON, Markdown, XML, YAML, JavaScript, TypeScript, PHP
                und habe Integrationen für mehrere IDEs und Editoren, die als „External Tool“
                die immer gleiche Executable mit globaler Config aufrufen. Ganz egal, in welchem
                Editor ich das dann auslöse, es führt überall zum identischen Ergebnis.

                Das löst für mich einfach die gesamte Klasse dieser Probleme. Es wird nicht
                alles ideal formatiert (und es kann leider wohl auch noch kein PHP 8 ), aber es
                ist gut genug. Ich muss nicht mehr darüber nachdenken und keine Zeit mehr damit
                verbringen, zu versuchen, meinen Editor korrekt einzustellen.

                Ich kann das nur empfehlen.

                Kommentar


                • #23
                  Da lobe ich mir PEP 8 - bzw. python.
                  soweit ich die frage des TE verstanden habe, geht es hie rnicht um das layout von Code, sondern um die eleganz des Algo.

                  und danke für Prettier mermshaus

                  Kommentar


                  • #24
                    Zitat von Alpha Beitrag anzeigen
                    Das Problem ist eher als Anfänger einen Profi zu erkennen. Ich habe Menschen kennen gelernt die 15 oder 20 Jahre in einer Firma programmieren und nichts dazugelernt haben , absolut fahrlässig und schlampig Programmieren und die Software für völlig überteuerte Preise verkaufen. Also nein, ich kann Dir da keinen Profi empfehlen.
                    Das kann ich so unterschreiben.

                    Die Frage "selber machen oder Profis holen?" würde ich daher so beantworten:
                    Möchte ich selbst als Entwickler an dem Projekt arbeiten + Habe ich genug Zeit um Fehler zu machen und sie wieder auszubügeln + Ist die Entwicklungsarbeit alleine oder im Mini-Team stemmbar?
                    -> Selber machen

                    Ansonsten: Lass es vom Profi machen
                    Achte aber darauf, dass du dir nicht einfach den erstbesten Entwickler auf Ebay holst, geh lieber direkt zu einer Agentur, setzt einen vernünftigen Vertrag auf, lass dir zwischendurch die Spezifikation zeigen yadda yadda.

                    Jetzt meine eigentliche Frage bzw. bitte um eure Meinung. Wie wichtig ist eleganter bzw schoener Code?
                    In der Regel finde ich es albern, wenn Leute von "elegantem" Code sprechen.
                    Schreib Code bei dem Benenner vernünftig benannt sind, der - zum Anfang - schon einigermaßen sinnvoll strukturiert ist. Darauf kann man dann aufbauen.

                    Sieh dir am besten schon Codesmells und Worst-Practices an um zu sehen, was man auf jeden Fall vermeiden sollte. Mir fallen dabei z.B. solche "Factories" ein, die man oft bei Leuten sieht die den Sinn der Factory Method bzw. Abstract Factory nicht verstanden haben. Die sehen in etwa so aus:
                    PHP-Code:
                    class RepositoryFactory {

                        public function 
                    getRepository($name) {    
                            
                    $className $mapper '_Repository';
                            if (
                    class_exists($className)) {
                                return new 
                    $className();
                            }
                        }

                    }
                    $repFactory = new RepositoryFactory();
                    $userRepository $repFactory->getRepository('User'); 
                    An der Stelle kann ich genauso gut $userRepository = new User_Repository(); schreiben, ist für die IDEs sogar leichter zu finden wenn man mal die Initialisierungen vom User_Repository finden muss.


                    Für genauere Hinweise, müsste man zumindest Teile von deinem Code sehen um einschätzen zu können über welches Niveau wir reden.
                    [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
                    [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

                    Kommentar


                    • #25
                      Zitat von Arne Drews Beitrag anzeigen
                      Das zeigt aber sehr schön, warum ich der Meinung bin, niemanden in Standards zwängen zu müssen, denn lesbar ist subjektiv!
                      Ja, und woher denkst du kommt dieser subjektive Eindruck? Hat bestimmt nix damit zu tun, dass du jahrelang auf Code geschaut hast, der so aussieht.

                      Zitat von tomBuilder Beitrag anzeigen
                      soweit ich die frage des TE verstanden habe, geht es hie rnicht um das layout von Code, sondern um die eleganz des Algo.
                      Die Frage liest sich doch eher wie "Kann ich eine Anwendung schreiben ohne vom Tuten und Blasen Ahnung zu haben, oder geht das in die Hose". Das mit dem Tuten und Balsen ist jetzt überspitz. Ich geh davon aus die Grundlagen sind da, es fehlt aber jetzt die Erfahrung/das Wissen um eine Anwendung sauber strukturiert hoch zu zeihen.
                      Was soll man dazu sagen? Ja, kann man machen, so haben viele PHP Projekte angefangen. Ich bin auch fest der Überzeugung, dass Facebook genau so anfangen hat. Fehler in der Struktur, oder das völlige abhanden sein von Struktur, müssen dann mit Fleiß ausgeglichen werden. Die ganzen Fettnäpfchen wollen nebenbei auch noch ausgelöffelt werden. Ich würde hier als Tip mitgeben, gleich ein Web-Framework zu verwenden und feuer frei.





                      Kommentar


                      • #26
                        Zitat von erc Beitrag anzeigen

                        Was für ein Unterschied macht es ob da zwei, vier oder acht Leerzeichen stehen? Was für ein Unterscheid macht es ob { in der selben oder extra Zeilen stehen? Was für ein Unterscheid macht es ob da irgendwo ein Leerzeichen mehr oder weniger steht? Und so weiter... spielt das deiner Meinung nach wirklich eine Rolle für die Lesbarkeit? In meinen Augen hat das keinen Einfluss drauf
                        Spätestens wenn im Team gearbeitet wird, kann das zum Problem werden. Meine Meinung dazu ist, besser den empfohlenen Standards folgen, warum das Rad neu erfinden?

                        PSR: Einrückung

                        Kommentar


                        • #27
                          Ist eine gute Empfehlung, ja.

                          Doch wer sich generell bemüht sinnvolle Einrückungen zu verwenden, hat schon einen großen Teil dazu beigetragen, dass auch andere Entwickler ( mit etwas Skill, keine Script-Kiddies! ) den Code gut lesen können.
                          Im Team sollte man zudem einig sein, welcher Code-Style gemeinsam verwendet wird. Ob man sich da 100% an eine PSR hält oder einen eigenen gemeinsamen Nenner findet, ist vollkommen egal.
                          Wenn 25 Entwickler sagen: So passt das!, spielt es keine Rolle, ob das einem empfohlenen Standard entspricht oder nicht.
                          Competence-Center -> Enjoy the Informatrix
                          PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                          Kommentar


                          • #28
                            Zitat von rammi Beitrag anzeigen
                            Spätestens wenn im Team gearbeitet wird, kann das zum Problem werden. Meine Meinung dazu ist, besser den empfohlenen Standards folgen, warum das Rad neu erfinden?

                            PSR: Einrückung
                            Meine Worte...

                            Zitat von erc Beitrag anzeigen
                            Ein "eigener" Codingstyle ist überflüssig. Der Codingstyle hat letztendlich weder auf die Produktivität noch Lesbarkeit ein Einfluss. Ob da eine Leertaste oder Zeilenumbuch mehr oder weniger drin ist, ist völlig Latte. Das ist alles nur Gewöhnungsache. Nimm PSR 1,2, 12 oder was auch immer grade hip ist und fertig. Mit PSR hast du:
                            -eine (fast) fertige Dokumentation
                            -fertige Regeln für alle Tools (teilweise leider etwas inkonsistent)
                            -quasi alles was du mit Composer einbindest sieht so aus
                            -andere Entwickler haben den Codestyle ggf. schon intus und wenn nicht siehe 1.
                            -das nächste PHP Projekt mit bestehenden Code was du auf den Tisch bekommst, sieht vielleicht auch schon so aus
                            Und ich seh das eher nicht als Problem im Team an. Wenn das zum Problem wird, hat das Team ganz andere Probleme...

                            Kommentar


                            • #29
                              Der Themenersteller ist schon lange ausgestiegen, genau 1 Tag nach dem Posten seines Themas.

                              Meine Erfahrungen sagen: Wenn bei stackoverflow immer nur astreiner Code zu finden ist, dann gibt es keine Probleme, weil die meisten Anfänger von da copy&pasten. is so. Der einzige Hinweis der mir fehlt ist error_reporting() mit ini_set() zu aktivieren. Ansonsten regelt solcherlei Dinge die Welt von ganz alleine. Eine kleine Website, die wenig Besucher hat, interessiert Hacker wenig bis gar nicht. Wenn es mehr werden, dann sind darunter Leute, die die Site checken. Is was faul, raten sie von der Site ab. Im Idealfall geben sie einen Hinweis. Und wenn es mehr Besucher sind, dann ist wohl auch das Geld da für was ordentliches. Hingegen sind diejenigen eine Gefahr, die erfahrene Programmierer sind, Geld fürs coden nehmen und Schrott coden. Was am Ende am effizientesten ist, bzw. schön oder elegant, darüber streiten sich eh alle bis in alle Ewigkeit.

                              Am besten ist es Dsdxb einen Tee zur Beruhigung anzubieten.

                              Kommentar


                              • #30
                                Zitat von psoido Beitrag anzeigen
                                Eine kleine Website, die wenig Besucher hat, interessiert Hacker wenig bis gar nicht.
                                Meiner Erfahrung nach, sind gerade diese Seiten für "Hacker" interessant, da im besten Fall, Jahre lang niemand merkt, dass die Seite als Spam-Schleuder oder Proxy umfunktioniert wurde.

                                Kommentar

                                Lädt...
                                X