Single quotes vs. double quotes: no noticable speed differences...
As PHP 4.3.0 is now the minimum version, the speed issue of single quotes vs. double quotes is negligible. See http://phplens.com/lens/php-book/optimizing-debugging-php.php, under "Useless Optimizations". There might be other reasons, however. I like to use "". ' is more convinient if a string has a lot of "s it it, like 'I have no "issues" with the "quotations"'. --Samuli Karevaara 04:26, 10 October 2006 (CDT)
- I see that Martin changed the rationale, so single quotes should be used with strings that have parsed variables in them. However, Tim changed the example back to use double quotes :-) --Samuli Karevaara 00:13, 17 March 2008 (CDT)
Unless I'm mistaken, there are some cases where we should use Moodle's full_clone() method. Maybe someone could clarify this...
- Probably this bit under the item 9: "If the thing you want to copy is not an object, but may contain objects (eg an array of objects) then use fullclone() instead." --Samuli Karevaara 00:18, 17 March 2008 (CDT)
Single vs Double quotes
According to the PHP.net manual page referenced, the memory usage issue for strings is not with single v double quotes, but with parsed variables in strings vs concatenated variables in strings.
As a PHP developer, I find it is overall much better to use double quotes for strings if for no other reason than that you can stick newlines (\n) in. Putting newlines in makes HTML debugging MUCH easier.
Just my $0.02.
(...some time later...) One more bit about quotes and parsed variables and speed optimizations.
Benchmarks have shown that
- there is no noticeable difference between single and double quotes for plain strings
- There is no noticable difference between single and double quotes with concatenated vars (e.g. "string".$num vs 'string'.$num)
- There IS, however, a performance penalty when double-quoted strings have a variable in them that needs to be parsed (e.g. "string$num")
I noticed this problem as I was persusing some parts of Moodle 1.8 (the gradebook). Now, I know gradebook has been rewritten for 1.9, but it seems to me that all the occurrences of things like this:
$thing = $preferences["$CFG->blah"];
Should have the double quotes removed! Having quotes in situations like that is ONLY adding a performance penalty, with no coding, readability, or other benefit at all.
hmm... Mayhap this has been addressed already? I don't know. But I thought I would mention it. Also, this last bit might not have anything to do with the "coding style" guidlines, but I was already talking about single v double quotes so I thought I would add this also.
Classes and their methods
There is nothing regarding classes and methods naming style. Is there an agreement on how to name classes and methods? I mean should I use "class lower_case_name" or "class CamelCaseName". And similar to methods - shall I type "function say_hello()" or "function sayHello()" if the function is a method of a class? --David Mudrak 17:30, 10 May 2008 (CDT)
- After a skype chat with Eloy and Petr, I added info about using lowercase in this case. --David Mudrak 14:30, 11 May 2008 (CDT)
No Camel Case. classes and methods should follow the same rules as functions: words_separated_by_underscores.--Tim Hunt 03:13, 12 May 2008 (CDT)
General Layout thoughts
These rules are essential, so I was experimenting with emphasizing the most important parts, but doesn't look so good. Each main rule should be 5-7 words long so people can remember them easier. More explanation should follow the initial rule. Anyone want to take on the task of rewriting these for simpler understanding? --Jeremy Rogers 16:45, 2 July 2008 (CDT)