MODx 0.9.7 Coding Standards

So, if we were to get really granular with the guidelines (oxymoron?), I’d see something like this:

• Pure Strings must use single quotes ([tt]$lang[’static_string’] = ’This string has no variables’;[/tt])
• Concatenation inside any loop must not use the bracket syntax ([tt]$lang[’another’] = "This string is: {$lang[’static_string’]}";[/tt])
• Avoid using double quotes when possible

As Ryan, pointed out, speed is a big factor on high traffic sites. I think speed should be a very high priority for MODx and optimizations made anywhere possible. Of course caching kind of relieves much of the processing required, but it only goes so far; also consider scenarios where a website might use many un-cached elements on a single page. Comments should explain code that might be hard to read (but let’s not get into argument about performance of comments ).

Quote from: sirlancelot at Feb 01, 2008, 06:58 AM

So, if we were to get really granular with the guidelines (oxymoron?), I’d see something like this:

Exactly, it is an oxymoron to get this granular with "Coding Standards". We’re now talking about implementation and optimization details. But some great stuff is being revealed here, regardless of what you call it. Just don’t call it coding standards.

Quote from: BobRay at Feb 01, 2008, 05:58 AM

I certainly can’t justify it logically, but it makes me uneasy to have variable names inside of quotation marks. I imagine it’s my background in other languages that makes me want to use quotation marks strictly for "string literals."

I concur...

Don’t know how much people have looked these "guidelines", but the single quotes for literals and single quote concatenation has been there all along.. but of course those guidelines in wiki have not been very official..

Quote from: OpenGeek at Feb 01, 2008, 03:39 AM

Too many formal rules limits creativity, and IMHO, how one builds a string with variable replacements is an issue that really should be decided by based on the problem being solved.

I think this is a fantastic point. And with the coming changes wrt patch contribution and peer review, we can hope for an ecosystem where the community can more easily hash out performance and readability issues after the initial contribution is made, the important part being the developer inspired by an idea and freely creating and sharing it.

Tangentially related to not stifling creativity over nitpicking the small stuff: I participated in my first Crucible review last night and I can say they’re insanely cool indeed, and will be a huge boon to taking patches from anyone.