Talk:Coding - Revision history

Dougiamas: Replacing page with '~~~~ I rebooted the comments page because the main page has changed so much'

2009-05-01T08:50:57Z

Replacing page with '~~~~ I rebooted the comments page because the main page has changed so much'

← Older revision		Revision as of 08:50, 1 May 2009
Line 1:		Line 1:
	~~== Single quotes vs. double quotes: no noticable speed differences... ==~~		[[User:Martin Dougiamas\|Martin Dougiamas]] 08:50, 1 May 2009 (UTC) I rebooted the comments page because the main page has changed so much

	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"'. --[[User:~~Samuli Karevaara~~\|~~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 :-) --[[User:Samuli Karevaara\|Samuli Karevaara]] 00:13, ~~17 March 2008 (CDT)~~

	~~== Using clone() ==~~

	~~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." --[[User:Samuli Karevaara\|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.~~

	~~Thanks!~~

	~~(...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:~~

	~~<pre>$thing = $preferences["$CFG->blah"];</pre>~~

	~~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? --[[User:David Mudrak\|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. --[[User:David Mudrak\|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.--[[User:Tim Hunt\|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? --[[User:Jeremy Rogers\|Jeremy Rogers]] 16:45, 2 July 2008 (CDT)

	~~== Page too long? ==~~

	~~I would suggest splitting up this~~ page~~. The sections on database structure and security issues deserve their one pages. --[[User:Frank Ralf\|Frank Ralf]] 14:15, 2 April 2009 (UTC)~~

	~~:Martin is planning to rewrite and split this page when he~~ has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)

	:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 "What should Moodle's coding guidelines be like?"] in the General Developer forum. --[[User:Frank Ralf\|Frank Ralf]] 10:41, 5 April 2009 (UTC)

Nakohdo: /* Page too long? */

2009-04-05T10:42:53Z

Page too long?

← Older revision		Revision as of 10:42, 5 April 2009
Line 48:		Line 48:
	== Page too long? ==		== Page too long? ==

	I would suggest splitting up this page. The sections on database structure and security issues ~~deserver~~ their one pages. --[[User:Frank Ralf\|Frank Ralf]] 14:15, 2 April 2009 (UTC)		I would suggest splitting up this page. The sections on database structure and security issues deserve their one pages. --[[User:Frank Ralf\|Frank Ralf]] 14:15, 2 April 2009 (UTC)

	:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)		:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)

	:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 "What should Moodle's coding guidelines be like?"] in the General Developer forum. --[[User:Frank Ralf\|Frank Ralf]] 10:41, 5 April 2009 (UTC)		:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 "What should Moodle's coding guidelines be like?"] in the General Developer forum. --[[User:Frank Ralf\|Frank Ralf]] 10:41, 5 April 2009 (UTC)

Nakohdo: /* Page too long? */

2009-04-05T10:42:32Z

Page too long?

← Older revision		Revision as of 10:42, 5 April 2009
Line 52:		Line 52:
	:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)		:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)

	:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 What should Moodle's coding guidelines be like?] --[[User:Frank Ralf\|Frank Ralf]] 10:41, 5 April 2009 (UTC)		:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 "What should Moodle's coding guidelines be like?"] in the General Developer forum. --[[User:Frank Ralf\|Frank Ralf]] 10:41, 5 April 2009 (UTC)

Nakohdo: /* Page too long? */

2009-04-05T10:41:51Z

Page too long?

← Older revision		Revision as of 10:41, 5 April 2009
Line 52:		Line 52:
	:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)		:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)

	:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 What should Moodle's coding guidelines be like?]		:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 What should Moodle's coding guidelines be like?] --[[User:Frank Ralf\|Frank Ralf]] 10:41, 5 April 2009 (UTC)

Nakohdo: /* Page too long? */ link to Tim's current proposal

2009-04-05T10:41:27Z

Page too long?: link to Tim's current proposal

← Older revision		Revision as of 10:41, 5 April 2009
Line 51:		Line 51:

	:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)		:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)

			:: See the current proposal by Tim [http://moodle.org/mod/forum/post.php?reply=528567 What should Moodle's coding guidelines be like?]

TimHunt at 14:48, 2 April 2009

2009-04-02T14:48:44Z

← Older revision		Revision as of 14:48, 2 April 2009
Line 49:		Line 49:

	I would suggest splitting up this page. The sections on database structure and security issues deserver their one pages. --[[User:Frank Ralf\|Frank Ralf]] 14:15, 2 April 2009 (UTC)		I would suggest splitting up this page. The sections on database structure and security issues deserver their one pages. --[[User:Frank Ralf\|Frank Ralf]] 14:15, 2 April 2009 (UTC)

			:Martin is planning to rewrite and split this page when he has a moment. I the mean time, since this is an important reference document, it would be better to leave it alone. I just reverted your changes. Sorry about that.--[[User:Tim Hunt\|Tim Hunt]] 14:48, 2 April 2009 (UTC)

Nakohdo: /* Page too long? */ new section

2009-04-02T14:15:17Z

Page too long?: new section

← Older revision		Revision as of 14:15, 2 April 2009
Line 45:		Line 45:

	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? --[[User:Jeremy Rogers\|Jeremy Rogers]] 16:45, 2 July 2008 (CDT)		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? --[[User:Jeremy Rogers\|Jeremy Rogers]] 16:45, 2 July 2008 (CDT)

			== Page too long? ==

			I would suggest splitting up this page. The sections on database structure and security issues deserver their one pages. --[[User:Frank Ralf\|Frank Ralf]] 14:15, 2 April 2009 (UTC)

Jrogerswti: New section: General Layout thoughts

2008-07-02T21:45:27Z

New section: General Layout thoughts

← Older revision		Revision as of 21:45, 2 July 2008
Line 41:		Line 41:

	No Camel Case. classes and methods should follow the same rules as functions: words_separated_by_underscores.--[[User:Tim Hunt\|Tim Hunt]] 03:13, 12 May 2008 (CDT)		No Camel Case. classes and methods should follow the same rules as functions: words_separated_by_underscores.--[[User:Tim Hunt\|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? --[[User:Jeremy Rogers\|Jeremy Rogers]] 16:45, 2 July 2008 (CDT)

Jsilve1: /* Single vs Double quotes */

2008-05-29T17:25:21Z

Single vs Double quotes

← Older revision		Revision as of 17:25, 29 May 2008
Line 28:		Line 28:
	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:		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"];		<pre>$thing = $preferences["$CFG->blah"];</pre>

	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.		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.

Jsilve1: /* Single vs Double quotes */

2008-05-29T17:24:43Z

Single vs Double quotes

← Older revision		Revision as of 17:24, 29 May 2008
Line 18:		Line 18:

	Thanks!		Thanks!

			(...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 ==		== Classes and their methods ==