News Code-Review bescheinigt Python hohe Qualität

[macos]

Das senkt die Übersichtlichkeit eher. Ein solches Konzept hab ich bei VB erleben dürfen, FURCHTBAR...
Gerade falls du mal einen längeren String zusammenstellst, z.B. eine SQL Query, ist es sehr von Vorteil, das Ding untereinander zu schachteln.

Das ist auch in Ruby kein Problem. Ruby ist so schlau das es ein zusammenhängendes Literal erkennt wenn es über mehrer Zeilen geht, auch ohne ein kryptisches ";" am Ende wie man es in PHP kennt...

 

[Yuuri]

auch ohne ein kryptisches ";" am Ende wie man es in PHP jeder C-syntax ähnlichen Sprache kennt...

%{


}

ist weniger kryptisch?

 

[Daaron]

Du musst macos verstehen... Er hat Haufenweise Zeit und Mühe investiert um RoR zu lernen und jetzt hat er damit im DACH-Raum keine Jobchancen. Also muss er seine Entscheidung irgendwie rechtfertigen... und was ist leichter, als blöde Flames über PHP abzulassen?

Jeder, der mit C zu tun hatte, kennt das Semikolon als Abschluss eines Statements. Auch Java schließt Statements mit ; ab, genauso JavaScript. Nur so n paar bekloppte Hipster-Sprachen denken, es neuerdings besser machen zu können.

 

[Yuuri]

Nur so n paar bekloppte Hipster-Sprachen denken, es neuerdings besser machen zu können müssen.

Ich hab dich mal berichtigt.

 

[character]

Das Problem von PHP ist nicht dessen Syntax. Bei weitem nicht.

Python ist übrigens von 1991 und braucht keine Semikola. C ist zwar deutlich älter, aber "Hipster-Sprache" ist Python nun wirklich nicht, im Gegenteil. Python ist heutzutage gerade im Linux-Umfeld eine der wichtigsten Sprachen überhaupt. Ruby ist auch schon fast 20 Jahre alt.

Das ist genauso wie wenn ein Pascal-Programmierer C als Hipster-Sprache bezeichnen würde, weil C Braces verwendet und Pascal älter ist: Lächerlich.

 

[albarracuda]

Du musst macos verstehen... Er hat Haufenweise Zeit und Mühe investiert um RoR zu lernen und jetzt hat er damit im DACH-Raum keine Jobchancen. Also muss er seine Entscheidung irgendwie rechtfertigen... und was ist leichter, als blöde Flames über PHP abzulassen?

Jeder, der mit C zu tun hatte, kennt das Semikolon als Abschluss eines Statements. Auch Java schließt Statements mit ; ab, genauso JavaScript. Nur so n paar bekloppte Hipster-Sprachen denken, es neuerdings besser machen zu können.

Über den Tellerrand hinaus zu blicken und RoR zu lernen ist besser, als sich auf ewig mit PHP zu begnügen, auch wenn das kurzfristig einfacher ist. Was "Hipster"-Sprachen angeht: Lisp, Fortran, etc. waren vor C da und nicht auf Semikolons am Zeilenende angewiesen. Mir fallen Semikolons zwar auch nicht negativ beim Programmieren auf, aber wenn ich eine Sprache entwickeln würde, würden die da ganz bestimmt nicht an jedem Zeilenende rumbaumeln müssen (ja, das ist möglich!).

Eine Sprache nur wegen syntaktischen Abwandlungen zu verurteilen, ist Blödsinn. Mich wundert nur, dass noch keiner auf Python rumgehackt hat. Ich hau mal einen raus: WTF?? Warum Einrückung statt {}?

 

[macos]

%{


}

ist weniger kryptisch?

Ich dachte eher an dieses:

   sql = "SELECT ...
          FROM ....
          WHERE ...."

Über den Tellerrand hinaus zu blicken und RoR zu lernen ist besser, als sich auf ewig mit PHP zu begnügen, auch wenn das kurzfristig einfacher ist.

Word!

 

[MrTengu]

Ich dachte eher an dieses:

   sql = "SELECT ...
          FROM ....
          WHERE ...."

Sieht nach PHP aus, wenn du statt "sql" noch "$sql" schreibst.

 

[antred]

Jeder, der mit C zu tun hatte, kennt das Semikolon als Abschluss eines Statements. Auch Java schließt Statements mit ; ab, genauso JavaScript. Nur so n paar bekloppte Hipster-Sprachen denken, es neuerdings besser machen zu können.

Häh? Ich verstehe ich, was so blöd daran ist, daß einige Sprachen kein Semikolon zum Abschluss eines Statements brauchen. Manche machen es so, andere halt anders. An solchen Trivialitäten sollte man sich echt nicht stören.

Genaus so wenig verstehe ich, wieso einige Leute meinen, Python unbedingt meiden zu müssen, weil es whitespace statt braces als syntaktisches Element einsetzt. Mein Gott, es gibt bestimmt Gründe, Sprache xyz zu meiden, aber solche Kinkerlitzchen zählen da echt nicht dazu.

 

[riDDi]

Was willst du in Python kompilieren? Das ist ja eines der schönen Sachen du brauchst kein Compiler es läuft alles direkt.

http://pypy.org/
Funktioniert nur leider nicht mit ein paar wichtigen Libs. Allen voran z.B. Numpy.

 

[macos]

Sieht nach PHP aus, wenn du statt "sql" noch "$sql" schreibst.

In PHP brauchst du noch ein ";" am Ende, aber sonst ists PHP ähnlich, also kann Daaron jetzt unbesorgt Ruby lernen..

Du musst macos verstehen... Er hat Haufenweise Zeit und Mühe investiert um RoR zu lernen und jetzt hat er damit im DACH-Raum keine Jobchancen.

Kann mich eigtl nicht beklagen, viele Jobs, kaum konkurrenz, im PHP Lager unterbieten sich ja die kiddies gegenseitig...

 

[albarracuda]

http://pypy.org/
Funktioniert nur leider nicht mit ein paar wichtigen Libs. Allen voran z.B. Numpy.

https://code.google.com/p/shedskin/

 

[Blutschlumpf]

Um mal zum Thema zurückzukommen:
Welchen Sinn erfüllt dieser "Scan" ?

Die wirklich interessanten Fehler sind doch die logischen, die nur unter selten auftretenden Bedingungen auftreten und deshalb nicht auffallen.
Und die wird er nicht erkennen weil er vielleicht Synatxprobleme checkt oder unglücklich benutzte Variablen, aber nichts inhaltliches.

Ergo sagt der absolut nichts über die Qualität des Programms aus.

 

[character]

Lies dir das verlinkte PDF durch. Keiner sagt, dass diese Tests der heilige Gral sind, aber sinnlos sind sie bei weitem nicht. Statische Analyse ist ein wichtiges Werkzeug in der Qualitätssicherung.

Jeder behobene Fehler ist ein guter Fehler.

 

[Zeboo]

Wer das ernst nimmt... dem ist dann auch nicht wirklich zu helfen.

 

[antred]

Wer das ernst nimmt... dem ist dann auch nicht wirklich zu helfen.

Wieso das denn bitte? Statische Codeanalysen sind natürlich nicht das Ende der Geschichte, aber nutzlos sind sie ja wohl keineswegs!

 

[Blutschlumpf]

Aber es sagt absolut nichts über die Qualität des Programms oder des Codes aus.

Faktisch läuft das doch so ab:
Du lässt den Checker laufen und korrigierst dann das was der ausgibt.
So kommt man dann in nem Jahr von knapp 1000 auf um die 100 Fehler.

Projekte mit ner guten Quote haben schlichtweg die Probleme "behoben", die hier gefunden wurden, sonst nichts.
Wenn Python neben den Fehlern hier noch 5 weitere dicke Patzer pro 1000 Zeilen Code hat und ein anderes Projekt quasi fehlerfrei, gut durchdacht, logisch und super kommentiert ist, aber alle 1000 Zeilen nen belanglosen Fehler in dem Tool erzeugt (weil das Tool nicht benutzt wurde), was kommt dann raus ?
Richtig: Totaler Unsinn.

 

[riDDi]

https://code.google.com/p/shedskin/

Shed Skin is an experimental compiler, that can translate pure, but implicitly statically typed Python (2.4-2.6) programs into optimized C++. It can generate stand-alone programs or extension modules that can be imported and used in larger Python programs. Besides the typing restriction, programs cannot freely use the Python standard library (although about 25 common modules, such as random and re, are currently supported). Also, not all Python features, such as nested functions and variable numbers of arguments, are supported (see the documentation for details).

LOL nope.

 

[antred]

Projekte mit ner guten Quote haben schlichtweg die Probleme "behoben", die hier gefunden wurden, sonst nichts.

In der Realität ist es manchmal so, daß wenn du einen wirklich pingeligen Codechecker über eine miese Codebasis laufen läßt, der Tausende von Mißständen ausspuckt. Viele davon kannst du dann nicht in dem Sinne beheben, daß du einfach ein paar Zeichen in einer Zeile ersetzt und fertig, sondern es ist häufig Umschreiben im großen Stil angesagt, und das tun sich dann viele Projekte gar nicht erst an. Also wird priorisiert, und eine gigantische Masse der gemeldeten Fehler wird letztendlich einfach für alle Zeit in Kauf genommen.

Deshalb hat eine sehr gute Quote meiner Meinung nach schon eine gewisse Aussagekraft, da ein solches Projekt gar nicht erst in so eine verzwickte Situation gekommen ist. Und klar kann man laut statischer Analyse 100% im grünen Bereich sein und trotzdem den größten Müll verzapfen, aber ich denke es ist keine unvernünftige Annahme, daß jemand der so sehr auf Qualität bedacht ist, daß ein guter Codechecker kaum was zu bemängeln hat, auch auf solides Design geachtet hat.

 

[haze4real]

Wat? Programme die Fehler im Code suchen (e.g. Anwendungslogik), Compiler welche Programme ausführen, wasn hier los?