Standardize

Posted: Wed Mar 04, 2009 10:37 am

Perhaps its time to standardize some of the coding and using best practices as well. Using freeresults, counting and array before a for loop, using a while loop to fetch row data, are some examples. I am sure there are many more.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

I think we've been down this path a few times in the past. It always ends up the same. In principle - yes; in practice - that's where it dies <sigh>

Posted: Sun Mar 08, 2009 12:04 pm

Well the use of the $db standard made things easier for developper didn't it?

And me being a standard nuke user and a newbie developper coulnd't think of using the standard coding.

I think me among plenty of others is a good example of what "some" developper do.
Like fetch code on the net , see what it does and hooray it works with nuke and it doesn't break my other modules Razz

Just an idea for you Raven : WIKI.

Posted: Tue Mar 10, 2009 9:28 am

We made a wiki for PE and once people learned to use it (the hardest part) they loved it and it help ALOT with standardizing things.

If this isn't working in practice then twist their arm. Don't certify them until they are brought up to snuff. Much like phpBB does with their mods. The cert process for them is a major pain.

Posted: Tue Mar 10, 2009 9:57 am

I am in agreement with Technocrat all the way with this one Wink

Posted: Tue Mar 10, 2009 3:16 pm

On second thought the wiki would be a bad idea , the forums are better for this.
And I do agree with you technocrat , phpbb cert is such a pain you can't even pass stage 1 if you are not a pro dev. Razz

(hate them)

Involved Joined: Apr 06, 2008 Posts: 484

eldorado wrote:

On second thought the wiki would be a bad idea , the forums are better for this.
And I do agree with you technocrat , phpbb cert is such a pain you can't even pass stage 1 if you are not a pro dev. Razz

(hate them)

But this is why nuke is such a mess Smile

I have always been a big fan of standardization, you could even build a script that people could put there code into and it would format it according to RN standards.Obviously this would rely on the dev team agreeing on a layout Smile

, and we all know, we have our own ways of doing things.

Posted: Tue Mar 10, 2009 5:36 pm

Doing things our own way is what has led to many of the problems

Posted: Tue Mar 10, 2009 6:28 pm

technocrat wrote:

Doing things our own way is what has led to many of the problems

Not really code layout is not as big an issue as the way the code is written.Most code that is poorly formated is because it has not been formated at all.for example I prefer

Code:







} else {

buy some people prefer

Code:







} 


else 


{

I also prefer to start the scripts 2 initial spaces (not tabs) and format it at 2 spaces also.

There are many different ways to format code, none of which are wrong.

But the way the code is written could be standardised.for example
[ Only registered users can see links on this board! Get registered or login! ]

We (we, like Im running shizzle around here Razz

) could have a document like above that helps new coders identify where things should be/shouldn't be and how to blah blah blah you get the point

It smoko so Im in a hurry Smile

Posted: Wed Mar 11, 2009 9:25 am

Code layout isn't really what I am referring to as much. Layout doesn't have as many consequences as poor coding. Everything from speed to security can be affected.

What I am talking about is more like:

Code:

$foo = array_fill(0, 1000000, 'bar');


for ($i = 0; $i < count($foo); $i++) {


    echo $foo[$i];


}

Which is a bad way to do it vs:

Code:

$foo = array_fill(0, 1000000, 'bar');


$count = count($foo)


for ($i = 0; $i < $count; $i++) {


    echo $foo[$i];


}

Or how about:

Code:

$result = $db->sql_query("SELECT * FROM TABE");


$num_rows = $db->sql_numrows($result);


for ($i = 0; $i < $num_rows; $i++) {


    $row = $db->sql_fetchrow($result);


    ....


}

VS

Code:

$result = $db->sql_query("SELECT * FROM TABE");


for ($row = $db->sql_fetchrow($result);) {


    ....


}

How about not using $db->sql_freeresult($result); or using the mysql functions.

Or worse not initializing arrays or validating input.

I could go on and on and on with things people use (dont use) that are not standards. Which is mostly due to there hasn't been one.

But if you guys want to try and enforce formatting then that's your decision to make, but I think should be secondary.

Two spaces? I never understood the two spaces format. It isn't standard in any PHP format standard. Plus some IDE's can't change from tabs to spaces like that. So your going to tell them that they have to hit space twice all the time vs tab Confused

Tab is always the standard and I would have a tough time understanding the reasoning of not using that as a standard.

But I will probably not be participating other than maybe giving some feedback and input. So what ever is decided is up to Raven and the community. I am just pointing out for the good of everyone that someone should step up and correct this oversight.

Posted: Wed Mar 11, 2009 4:02 pm

yes definately, code layout was just a secondary thought as a lot of code I see is beyond a mess Smile

Most good editors will alllow you to format code anyway you like.

But those improvement's above can make a big difference as I recenlty found out.

e.g.

Code:




$count = count($foo)


for ($i = 0; $i < $count; $i++) {

I was seeing gains of upto 90% speed increase doing it this way.

Posted: Wed Mar 11, 2009 6:45 pm

I'm kind of surprise the PHP compiler doesn't optimize that for us. Oh well

Posted: Thu Mar 12, 2009 6:47 am

I have read that even the following is better:

Code:




$count = count($foo)


for ($i = 0; $i < $count; ++$i) {

Pre-Increment/decrement is supposed to be faster (fewer op-codes) than post-increment/decrement.

Posted: Thu Mar 12, 2009 7:07 am

It is, I just didn't think of it while making the example. Good reason for a wiki and lots of input. Wink

[ Only registered users can see links on this board! Get registered or login! ] [ Only registered users can see links on this board! Get registered or login! ]

Posted: Thu Mar 12, 2009 7:17 am

technocrat wrote:

Good reason for a wiki and lots of input. Wink

Absolutely!

BTW, we have one, but just not officially released yet.

Posted: Thu Mar 12, 2009 4:07 pm

I would sure go on this one Wink

I wanted to start one myself with the help of the platinum community but it's a waste of time now Very Happy

Posted: Thu Mar 12, 2009 6:07 pm

another interesting read
[ Only registered users can see links on this board! Get registered or login! ]

Posted: Thu Mar 12, 2009 8:40 pm

testy1 wrote:

another interesting read
[ Only registered users can see links on this board! Get registered or login! ]

Not according to the php development team Smile

[ Only registered users can see links on this board! Get registered or login! ]

====================================================
Notes
Tip

Do not use preg_match() if you only want to check if one string is contained in another string. Use strpos() or strstr() instead as they will be faster.
====================================================

Posted: Fri Mar 13, 2009 12:18 am

to be honest I could spend all day testing functionoidals and objectorzoidals for speed Smile

Posted: Fri Mar 13, 2009 1:03 am

mmmmmm

realtime benchmarking
[ Only registered users can see links on this board! Get registered or login! ]

Posted: Fri Mar 13, 2009 7:52 am

rofl....says it needs to be refreshed several time... Razz

Posted: Thu Apr 23, 2009 8:08 pm

Here's a few issues I've come across that are specific to standardization for Ravennuke:

Posted: Sun Apr 26, 2009 3:55 am

Nice list fkelly.

7. use DB instead of DBI
8. stripslashes on every form to prevent sql injection.
9. Using css's style instead of hardcoding.Accessibility must be the main concern.

6 is probably the most important standard.Helps a lot for security audits. and simplify the approver's job.

Posted: Sun Apr 26, 2009 4:21 am

Quote:

8. stripslashes on every form to prevent sql injection.

Actually no. addslashes is what you want to prevent sql injections. Better, use mysql_real_escape_string (only if using MySQL databases)

Posted: Sun Apr 26, 2009 9:28 am

Re. forms, it is not a matter of stripslashes or addslashes or mysql_real_escape_string per se, though Evaders is correct. Every form field should be filtered by the receiving program. The filter should be as specific to the field as possible. In other words, if the field should be an integer then your filter should do a intval() on it. If you do an intval there is no need to do other "more expensive" filters like check_html. If the input should be an integer between 1 and 10 you should filter for that. If it should be a date you should check to see that it's a valid date. If it should be a floating point number you should check for that. If it should be text you should check that the input doesn't exceed the max length and if the text shouldn't have html, in a RN context you can use check_html() with the no html parameter. If it can have html you should still use check_html which will clean up any "bad" html and prevent most exploits (and NS will act as a "double" filter). If you have radio buttons and checkboxes they should be filtered to assure there is no numeric input or text in them.

This is where the form designer and the filter writer really need to work together and the form designer and programmer should specify his intent for each field. Some fields such as radio buttons are obvious but there are others where it would be helpful to know (and not necessarily intuitive to someone coming from outside) what the range of values a field can have.