Archiv verlassen und diese Seite im Standarddesign anzeigen : Feedback zu den vBGo Add-on Standards
Queenie_Pie
02.05.2008, 21:32
Hallo zusammen.
Meinen größten Respekt vor den Machern dieses Entwurfes!
Da ich selber leider nicht der große Programmierer bin kann ich die einzelnen Punkte auch nicht bewerten. Allerdings sehe ich trotzdem die Arbeit die hinter so einer Veröffentlichung steht. Alle Achtung.
Zusätzlich sehe ich auch noch den Vorteil bald geprüfte und ausgezeichnete Addons hier zu finden. Ein Aspekt der in Hinsicht auf die Sicherheit der eingebauten Erweiterungen gar nicht hoch genug gewertet werden kann.
Vielen Dank an alle Beteiligten.
Dem kann ich mich nur anschließen.
Finde ich sehr gut. Da weiß man doch, was man an vB hat und dass man sich für die richtige Forensoftware entschieden hat. :)
Danke an das ganze Team, für diesen Einsatz.
Ist das eigentlich nur eine Initiative auf vBGo, oder wird es auch bei vb.org möglich sein, seine Hacks entsprechend "zertifizieren" zu lassen ?
Gruß
Jörg
Wulfnoth
03.05.2008, 09:36
Normalerweise sind dumme Fragen ja nicht so mein Ding (außer eben manchmal :D ) aber ich verstehe die Ankündigung nicht so ganz. (Liegt vielleicht an der nachtragenden Kombination von 1.Mai und Vatertag :p )
Werden hier irgendwann auf einer extra Seite Addon-Standards aufgelistet?
Normalerweise sind dumme Fragen ja nicht so mein Ding (außer eben manchmal :D ) aber ich verstehe die Ankündigung nicht so ganz. (Liegt vielleicht an der nachtragenden Kombination von 1.Mai und Vatertag :p )
Werden hier irgendwann auf einer extra Seite Addon-Standards aufgelistet?
Eher der Standard wie man AddOns machen sollte :)
http://www.vbulletin-germany.org/showthread.php?t=3567
@Andreas, ist das nicht auch schon darauf bezogen?
http://www.vbulletin-germany.org/showthread.php?t=8
Das ist für mich persönlich zu aufgebläht. Ein paar Punkte wie bsp. Hacks auszusehen haben und wie man vBulletin besser ausnutzt (GPC) sind einleuchtend.
Aber wenn man mir hier Regeln vorschreibt ob ich eine Klammer in einer neuen Zeile reinmache oder nicht dann bin ich weg.
Ja, ich weiss, es sind nur Richtlinien. Nur wenn ich schon wieder das Wort "Zertifizierung" in diesem Zusammenhang lese...
Speedy1505
04.05.2008, 09:29
es geht sicher nicht um "Zensur" -- sondern vielmehr um Lesbarkeit und damit auch Sicherheit von Hacks ....
Wie bitte kommst Du auf Zensur?
@Phalynx:
Das sind aber nun einmal die vBulletin Code Standards :-)
http://www.vbulletin.com/docs/html/
Niemand wird gezwungen sich daran zu halten, aber jeder sollte das tun.
MrZeropage
04.05.2008, 13:10
Sicherlich ist es schön, wenn der Code insgesamt auch für Dritte leicht lesbar ist, indem man sich an gewisse Standards hält. Andererseits halte ich es für einen absoluten Witz, sowas zur Vorschrift zu machen oder das dies in irgendeiner Weise Einfluss auf die Produktqualität haben soll.
Wir haben damals auf vBH auch über eine "Qualitätssicherung" nachgedacht, und ich meine nach wie vor, dass man gute Modifikationen durchaus hervorheben sollte, indem man gewisse Qualitäts-Siegel vergibt, z.B.:
1) Sicherheit geprüft (alle eingehenden Variablen nutzen GPC, Queries sind sauber usw.)
2) Eigenständigkeit (Verknüpfung oder Backlinking zum Author ?)
3) Update-Freundlichkeit (konsequente Nutzung von PlugIns und ggf. TMS)
4) Support (wird das Produkt weiterentwickelt, gibt es aktiven Support)
5) Resourcen (Aspekt von Queries, speicherintensiven Schleifen/Berechnungen usw.)
DAS sind entscheidende Kriterien für einen Endanwender, die Struktur des Codes (Gross-/Kleinschreibung) ist dem doch völlig wurscht erstmal.
Und wenn der Endanwender sieht, dass das AddOn auf Sicherheit geprüft wurde und hierfür "ein Sternchen" bekommen hat, dann kann dies bedenkenlos eingesetzt werden.
Grundidee damals waren verschiedene Qualitätslevel, z.B.:
Bronze : geprüfter Code, keine Sicherheitslücke, saubere Datenverarbeitung und DB-Queries
Silber : wie Bronze, zusätzlich Update-Freundlichkeit
Gold: wie Silber, mit aktivem Support und ggf. Weiterentwicklung (sowie Version verfügbar oder kompatibel mit aktueller vB-Version)
Platin : wie Gold, zusätzlich Resourcenoptimiert und konsequente Nutzung von Phrasen und Templates, ohne jegliche Vermischung von Code und Inhalt
Premium : wie Platin, zusätzlich optimierter Code in Sachen Richtlinien, Lesbarkeit, kommentierter Code, englische Variablenbezeichnungen usw.
Ach ja, im übrigen könnte man dann hier auf vbGO auch mal die Auszeichnungen "Mod of the Month" hier zumindest darstellen (als kleine Auszeichnung) oder parallel selbst solche Auszeichnungen als Wettbewerb anbieten
Die Grundidee dieses von Andreas angestoßenen Projektes ist doch eine Sammlung an Leitlinien, die für Entwickler von Erweiterungen hilfreich sein sollen. Andreas hat doch mit keinem Wort gesagt, dass die Einhaltung des Styleguides zur Code-Formatierung Pflicht wäre. Dennoch finde ich es sinnvoll, dass das vBulletin so einen Styleguide hat, damit insbesondere diejenigen, die eben noch nicht genau wissen, wie sie die Formatierung handhaben sollen, einen durchaus sinnvollen Weg vorgezeichnet bekommen.
Und ganz irrelevant ist die Formatierung keineswegs: Hübsch strukturierter Code alleine ist zwar noch kein "guter" Code, aber er lässt sich deutlich leichter auf seine Qualitätsmerkmale hin prüfen. Und darum geht es doch im Endeffekt für uns alle.
Eventuell sollten wir uns nicht in der Diskussion um die Einzelheiten der Formatierung verlieren. Ebenso wichtig ist es, die Grundlagen zu vermitteln und bei den Entwicklern von Erweiterungen beispielsweise das Bewusstsein zu wecken, dass Eingaben von Benutzern grundsätzlich zu misstrauen ist, dass etwa zehn zusätzliche Queries pro Seite die Gesamtperformance drastisch nach unten ziehen können, dass viele Informationen gar nicht ermittelt werden müssen, weil sie durch das vBulletin bereits zu Verfügung gestellt werden etc. etc.
Hinsichtlich des Umfangs sehe ich da weniger Probleme, da ich dieses Dokument als Nachschlagewerk auffasse. Solange es ein brauchbares Inhaltsverzeichnis hat, kann es meinetwegen praktisch beliebig wachsen und dabei an Wert nur gewinnen. Dennoch sollte man von Zeit zu Zeit die wichtigsten Informationen herauskristallisieren, damit man sich als Entwickler an einer Art Checkliste längshangeln kann, die wenigstens grob abprüft, ob man sich an die wichtigsten Dinge gehalten hat.
Ich würde mir einen Abschnitt "best practices" wünschen, der - fast wie eine Art Wiki - kontinuierlich erweitert werden könnte. Gerade gestern überlegte ich mir, wie ich an eine Auflistung der Foren herankomme. In "$vbulletin->forumcache" stehen sie alle drin, doch kann ich mich immer darauf verlassen, dass dieses Array vorhanden und aktuell ist? Die Antworten auf solche Fragen könnte man dann beispielsweise in so einem Abschnitt finden. Ähnlich ergeht es mir mit dem Datenbank-Geraffel, das Andreas ja bereits erklärt hat: "query_read()", "query_first_slave()", "query_first()" ... hallo ...? Was nimmt man denn da und welche Konseuqnzen hat das jeweils? Auch durch das Thema habe ich mich kürzlich durchgelesen - könnte man beispielsweise auch in so einem Guide unterbringen.
Eine Gold-, Silber- oder Bronze-Bewertung von Mods halte ich für problematisch, da hiermit das Urteil "gute Erweiterung", "schlechte Erweiterung" auf eine mit Werten behaftete Farbe reduziert wird - tatsächlich spielen aber sehr viel mehr Faktoren in diese Beurteilung hinein und pauschal läst sich da schon gar kein Urteil fällen. Da halte ich die sachliche Auflistung der Tatsache ("Support ja/nein", "benötigt Dateizugriff ja/nein" etc.) für sehr viel hilfreicher.
Grüße,
Gérome
Andererseits halte ich es für einen absoluten Witz, sowas zur Vorschrift zu machen oder das dies in irgendeiner Weise Einfluss auf die Produktqualität haben soll.
Es hat aber Einfluss auf die Produktqualität.
Wenn man sich konsequent an die Code-Standards hält sind z.B. SQL Injection Leaks schon prinzipiell recht unwahrscheinlich.
Andere Dinge (wie z.B. AND anstatt &&) helfen Flüchtigkeitsfehler zu vermeiden.
Die korrekte Verwendung von quotes dient der Minimierung von Fehlern (undefined index z.B.), usw.
DAS sind entscheidende Kriterien für einen Endanwender, die Struktur des Codes (Gross-/Kleinschreibung) ist dem doch völlig wurscht erstmal.
Das ist richtig. Aber dadurch dass sich der Entwickler an die Standards hält wird es automatisch leichter die für den Endanwnder wichtigen Kriterien zu erfüllen.
Wie gesagt, das ganze ist erst einmal nur ein Entwurf/Vorschlag, ich denke aber dass die Einhaltung der Code Standards schon die Grundlage sein sollte.
Denn IMHO macht erst das eine vergleichbare Beurteilung praktikabel.
Ich persönlich halte es für sinnvoll, dass der vB-Standard im Code benutzt wird. Ich habe während der Entwicklung der vB-Membermap nun ja auch so einiges an meinem 'Stil' geändert und habe einige Vorgehensweisen natürlich auch in Frage gestellt. Bei genauerer Betrachtung kam ich aber immer wieder zum Ergebnis, dass der Einsatz des vB-Standards die Produktqualität entsprechend hebt, viele Sicherheitslücken per se überhaupt nicht erst auftreten können und das vB wesentlich mehr potential hat als erwartet.
Die von Andreas in mühevoller Kleinarbeit erstellte Leitlinie kann ich von daher nur befürworten. Vor allem erleichtert es den Codern den schnellen Überblick bzgl. der oben von mir aufgezählten Dinge.
Nachdem ich mich nun mehr und mehr mit vB-Coding beschäftigt habe sehe ich erst, wieviel Mist doch manchmal fabriziert und veröffentlicht wird. Viele AddOns sind 'irgendwie' aus x anderen AddOns zusammengebastelt worden oder jeder versucht mit irgendwelchen Standard-Routinen das Rad neu zu erfinden. Leider tangieren solche Vorgehensweisen die Sicherheit eines AddOns. Aber wie gesagt; es ist meine persönliche Meinung und ich habe dazugelernt. :o
Surviver
06.05.2008, 14:24
Ich persönlich halte es für sinnvoll, dass der vB-Standard im Code benutzt wird. Ich habe während der Entwicklung der vB-Membermap nun ja auch so einiges an meinem 'Stil' geändert und habe einige Vorgehensweisen natürlich auch in Frage gestellt. Bei genauerer Betrachtung kam ich aber immer wieder zum Ergebnis, dass der Einsatz des vB-Standards die Produktqualität entsprechend hebt, viele Sicherheitslücken per se überhaupt nicht erst auftreten können und das vB wesentlich mehr potential hat als erwartet.
Die von Andreas in mühevoller Kleinarbeit erstellte Leitlinie kann ich von daher nur befürworten. Vor allem erleichtert es den Codern den schnellen Überblick bzgl. der oben von mir aufgezählten Dinge.
Nachdem ich mich nun mehr und mehr mit vB-Coding beschäftigt habe sehe ich erst, wieviel Mist doch manchmal fabriziert und veröffentlicht wird. Viele AddOns sind 'irgendwie' aus x anderen AddOns zusammengebastelt worden oder jeder versucht mit irgendwelchen Standard-Routinen das Rad neu zu erfinden. Leider tangieren solche Vorgehensweisen die Sicherheit eines AddOns. Aber wie gesagt; es ist meine persönliche Meinung und ich habe dazugelernt. :o
Besser hätte ich es nicht sagen können.
Ich versuche schon seit ich angefangen habe "wirklich" zu coden, mich an diese Standards zu halten, und es klappt immer besser ;)
Mittlerweile ist es mein Coding-Stil geworden, und ich schreibe den code meistens schon ohne darüber nachzudenken so.
Auch ich bedanke mich für die Aufstellung der Standards. Ich hoffe, dass da von Andreas noch ein nettes Tool kommen wird ;););)
Viele Grüße
Julian
Ich denke mal, dass die Sicherheit und Bugfreiheit von Add-ons an oberster Stelle stehen muß. Das wird aber im Moment in soweit geprüft, als dass sicherheitskritische Add-ons solange "vom Markt" genommen werden bis die Mängel behoben wurden. Weiterhin bin ich der Meinung, dass man sich bei Software mit offenen Quellcode nach Möglichkeit an den Vorgaben der Entwickler halten sollte. Das kann manchmal recht schwierig werden, insbesondere wenn man seinen eigenen Programmierstil pflegt. Letztendlich überwiegt aber der Vorteil für sich und andere, die mit diesem Code weiterarbeiten wollen.
Ein weiterer wichtiger Aspekt kommt der Effizienz und Schonung von Recourcen zu. Aber dazu hat Andreas bereits einiges angeführt.
Dass man Code nach der Einleitung neuer Blöcke einrückt, sollte selbstverständlich sein. Aber es soll ja Leute geben, die sich das Leben selbst gerne schwer machen. Ob jetzt && oder AND (Javascript z.B. verwendet nur && und nicht AND) das ist imho Geschmackssache. Und doppelte und einfache Quotes verteile ich auch eher nach praktischen Erwägungen, als mich nach einem starren Schema zu richten.
Was im Artikel noch ergänzt werden sollte, dass Add-ons die gleichen Minimal-Voraussetzungen wie vBulletin selbst erfüllen. Des weiteren sollten bei der Verwendung von PHP-Funktionen nur solche Verwendung finden, die im PHP-Core drin sind und nicht irgendwelche extensions voraussetzen. Auch haben die exec-Funktionen nichts in Add-ons zu suchen. Nicht jeder hat einen eigenen Server. Zur Not sind kompatible Ersatzmöglichkeiten mit anzubieten. Typisches Beispiel, was ich schon des öfteren sah, ist cURL (http://de.php.net/manual/de/book.curl.php).
Erwähnenswert ist auch, dass möglichst vB-eigene Funktionen und bereits bestehende Konstanten bzw. Variablen verwendet werden. Auch hier als Bsp. TIMENOW anstelle time() verwenden.
Ich weiß jetzt nicht, ob das es in diesen Artikel gehört oder hierfür ein gesonderter Artikel verfasst werden sollte, aber ich denke, wir sollten auch einige Worte zu den Übersetzungen verlieren, die hier für engl.-sprachige Add-ons veröffentlicht werden.
Surviver
06.05.2008, 19:07
Zu cURL: Dafür bietet vBulletin die Klasse vUrl an. Falls cURL nicht installiert ist, wird fsockopen genutzt.
Gruß Julian
Danke für den Hinweis. Das bestätigt meinen vorletzten Absatz. ;)
vBulletin® v3.7.4, Copyright ©2000-2008, Jelsoft Enterprises Ltd.