The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#1
|
|||
|
|||
To enforce a valid coding style in the community!
I have noticed that most of the coders @ vBulletin.org do not follow vBulletin coding standards and / or make a code unnecessarily long with extra queries and other unnecessary stuff like creating code / variables that are already present on a certain vBulletin page... There are only about 4 or 5 coders who follow those standards..
While most of the hacks themselves are great, these coding faults pose security and stability errors, making server load higher than it could be if the code would be optimized. Plus, poorly written code might take more space than an optimized version of the same code. What I suggest is making a system where we would help people perfect their hacks after which it would be marke as PHP Valid. It should be no problem for the forum administrators to add a field "QA Verified", editable only by the QA team and the administrators. Once the field is created, allow users to choose from displaying all hacks or only the ones marked as "Containing an optimized PHP". This way, while the coding style will not be enforced, vB hackers will be encouraged to code properly in order to rate higher and display their hacks better. The best part is, this system is easy to implement (I could help making it), and it would not require immediate validation, which is a plus from the QA team's point of view. What do ya'll think? If this works out, I could help creating that system and later be a member of the verification team. |
#2
|
|||
|
|||
We already tried this (in a way) with the QA team and it failed. There just aren't enough experanced people with the time to do something like this.
BTW we can't enforce people to code to standard anyway. Take a look at some of the 'experanced' coder's early hacks and you'll see what I mean, everyones ability to code develops over time with the help of others. Enforcing people to code to standard would deny people that option. |
#3
|
||||
|
||||
I offer my services as a member of the verification team as well. You remember from the Hack Manual Gen thread that I'm a perfectionist, so I would be one of those 4 or 5 I strive to achieve the standards in terms of coding style, but also actual coding (such as escaping DB values the vB way), templates, phrasing, etc
[/advertising to blag his way into the team] I would applaud such a change, phpBB does it and it works for them, so why shouldn't it work for us? Coupled with the Hack Database, this would IMO definetely be a huge step towards a better vBulletin coding community as a whole. The sceptics might say "we can't force people to code a certain way", and while this is true, I fail to see why us hack installers should be forced to either clean up the code, or slowly watch our vBulletin installation buckle from poorly written hacks just because we desire/require the functionality it provides. The vBulletin Coding Standards not only produce clean, easy to read/customise coding, it makes debugging easier. Imagine a script where an entire foreach() iteration is written on a single line, cramped together, then a parse error occurs. The line # would be the same, yet users (without syntax highlighting editors) would have to break up the line in order to pinpoint the error. I fail to see a single good reason why these coding standards should continue being as undervalued as they are. EDIT: Quote:
First of all, the vBulletin Coding Standards are mainly about code formatting. The ability to proper indent code, writing clean code, etc has nothing to do with someone's ability to code. I'm not saying we should get a bunch of Coding Nazis to fine coam each hack making sure they spaced their function arguments properly OR ELSE!!!, but there's a difference between that and some of the manure that Ive seen when looking at hacks. Oh and just because you tried it before, doesn't mean you don't have new talent to help carry this out NOW. The hack database, as I understand it, was present before. Why not bring back this QA team, at least for a trial run? The worst thing that can happen is the team being so totally backlogged that they have to give up, at which point the admins can simply disband the team and disable the Moderation (or whatever youll use to delay hack releases), and all is well |
#4
|
||||
|
||||
It's not just a case of having the people willing to do it - If I want to code something that doesn't conform to standards, I will - Whether you choose to use it, or modify it to your own standards is up to you
Enforcing anything regarding code standards etc is wrong and shouldn't become part of vB.org Satan |
#5
|
||||
|
||||
It's a good idea in theory, but in practice, the problems I foresee are:
1. Discourages beginner hackers from releasing hacks. 2. Delays the release of hacks as presumably hacks won't show up until they are approved. 3. Also, what happens if a hack does not pass? Do you remove it, recode it for them, force the author to recode it? What if the author refuses to recode it and wants to have his own style? Do you basically then disallow the release of the hack? These are things to consider. |
#6
|
||||
|
||||
Step 1) Rate the Thread
Step 2) Don't install modifications with low ratings. |
#7
|
||||
|
||||
I see valid points on both sides.
IMHO we can't enforce ppl to stick to certain coding styles, but we can try to encourage them. Experience seens to be one important thing, so we should try to give newbies as much knowledge as possible. Maybe smth. like a "quality lable" issued after a Hack has been reviewed would be nice. This does not have to be mandatory, and thus would not slow down releases etc. But I think it would encourage ppl. to write well-coded Hacks. Thread Rating is anonymous and doesn't mean much. There are Hacks with high ratings which are IMHO terrible (code wise). |
#8
|
||||
|
||||
dark visor, you could start with my code, id love to hear some feedback, or with a style guide.
|
#9
|
||||
|
||||
But then a Quality Label can be seen as saying that some hacks are better than others, not that their code style is just more in-line with what a group of people think it should be...
Honestly - If a hack is that important to me as it is so good, and the code is poorly done, I re-code it myself - The only people I can see complaining about coding standards are standard fanatics... I'd say over half the people who visit vBulletin.org and install hacks from here rarely care if the code is sloppy - As long as it doesn't bring their site to a halt and does the job they want, they're happy... It brings into mind the whole catering to the masses arguement - Not many people will care, and those that do take it too far... While it is good that you are concerned about how code standards drift, merely advising people that their code is sloppy and showing/guiding them how to make it not sloppy will help them become better coders - Slapping a sticker saying "Poor" will defeat the purpose - It will discourage newbies from posting hacks as their coding standards 9 times out of 10 will not be how you fanatics think it should be, and it will also not help them learn - Being told your code sucks and not being told how to make it better is worse than moaning about the code not being up to your standards... Honestly, all I can see this doing is creating bad feeling, a "division" between coders and eventually tearing a rift in the community... A few "How-to" guides, helpful suggestions in hack threads and generally aiding the newer (and older) coders (as not everyone is perfect ) on how to make their code better would be the only sensible course of action... Satan |
#10
|
|||
|
|||
What does "QA" stand for? Quality Assurance?.. I dislike the abbreviation.
Quote:
However, this is not likely to work out for the following reasons:
Quote:
Based on above + plus KirbyDE's post, I am rethinking the effectiveness of the above method... However, I'd like to propose another plan, which I am sure can act as a compromisse between the two sides: On vBulletin.org, hacks have many custom fields ("Installer Included", "Support Provided", etc). It should be no problem for the forum administrators to add a field "QA Verified", editable only by the QA team and the administrators. Once the field is created, make the board display only the Verified hacks by default, with an option to display a complete list of hacks (both verified and non-verified). The option should be visualized as a link in every forum, and it should create a session variable (not a cookie), that would keep the setting as is until the user leaves the forum. Once he\she comes back, it will once again set to only display Verified hacks. This way, it will feel like that the Verified hacks are positioned above non-verified hacks. While the coding style will not be enforced, vB hackers will be encouraged to code properly in order to rate higher and display their hacks better. The best part is, this system is easy to implement (I could help making it), and it would not require immediate validation, which is a plus from the QA team's point of view. Let's have a trial run of this sytem! |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|