MODx 0.9.7 Coding Standards

The set of standards for MODx 0.9.7 development has been posted at:

http://docs.modxcms.com/modext/

along with the other tutorials on 097 development. These standards are for PHP development as well as CSS/JS.

This section will expand as we write more for it, so check back periodically. Also if there are questions, feel free to post and we’ll add clarifications and decisions on the discussions made here to the site asap.

Many thanks! splittingred :-] A well written, descriptive & short documentation that deserves a plane full of a chocolate(i liked it so i said!) to the group or individuals who worked on it, keep up a good work.

one more thing... what do you guys suggest me to chose ModExt or EXT2 essentials directly to apply an RTL functionalities there?

Any comments are welcome :-]

I might be the only one who uses Vim, but here’s what users can do in their [tt]~/.vimrc[/tt] file to adhere to the standards:You can type [tt]:help expandtab[/tt] to learn how to type a real tab character when [tt]expandtab[/tt] is enabled.

Nice write-up.
I’ve read some comments on string concatenation in the forums - should any thoughts about that be made official?
ie. "like {$this}" or ’like ’ . $this
.. or leave it up to the discretion of the coder?

Quote from: netProphET at Feb 01, 2008, 12:45 AM

Nice write-up.
I’ve read some comments on string concatenation in the forums - should any thoughts about that be made official?
ie. "like {$this}" or ’like ’ . $this
.. or leave it up to the discretion of the coder?

I should have said something on that - will add tomorrow...but definitely, if at all possible, my opinion is:



It’s must easier to read where variables are placed, it avoids the performance hit of double quotes, and keeps string use standardized to single quotes.

Quote from: netProphET at Feb 01, 2008, 12:45 AM

Nice write-up.
I’ve read some comments on string concatenation in the forums - should any thoughts about that be made official?
ie. "like {$this}" or ’like ’ . $this
.. or leave it up to the discretion of the coder?

I say discretion of the coder, or ultimately, consensus of those involved in contributing, on this one.

I don’t mind a few simple guidelines and principles under the guise of "Coding Standards", but I’d like to shy away from any inclusion of general PHP coding issues. 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.

Saying that all array indexes should be defined with single-quotes (one of the standards currently included in this list) is another example of this. There are simply times it’s more important to make code readable vs. optimize it for speed, times when it’s appropriate to use "like {$this} or ’like ’ . $that, etc. It’s a matter of context and I believe we should treat such matters on a case-by-case basis based on measurable evidence. I’m not necessarily arguing against or for this specific issue mind you (though I personally think "like {$this}" is much more readable in most situations), just don’t think we should worry ourselves with defining and maintaining standards for the numerous issues like this one, or the string concatenation one, that we could include.

But discussing these kinds of PHP coding tips, as well as tips specific to working with xPDO/MODx code, here in the forums will be a wonderful way to start hashing out content that can fill core committer and add-on developer guides based on the appropriate consensus in each culture. Working on making it much easier to contribute so this knowledge doesn’t get lost here either...

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

Saying that all array indexes should be defined with single-quotes (one of the standards currently included in this list) is another example of this.

Actually, I’ll disagree here....performance tests show that concatenation with single-quotes run twice as fast benchmarked than interpolation with double-quotes. And if we’re going to do so with strings with vars inside, might as well keep it standard and do so with those without.

Point:
If you have tens of thousands of instances on a page, I’d say it might make a difference, but even your benchmark proves that a single instance is only 0.00000723 faster. I’m thinking that just might not be all that noticeable when it’d take almost 14,000 repetitions to reach a whole tenth of a second. I’m guessing there’s much bigger fish to fry when it comes to areas of performance to worry about! Then again, if you’re talking about the core like in the parser, every iota could make a difference on busy sites with millions or more requests daily.

Counter-point:
2 million daily monthly page views * average of 25 occurrences per page (? completely grabbed out of the air ?) = 50,000,000 occurrences/daily or about 6 minutes of processing overhead in a given day month ...

6 min/day * 365 days / 60 min/hour / 24 hours/day ... it really adds up

You could save over 1.5 days per year just from using single quote concatenation on a busy site.

update: then when you realize it’s more conceivable to think about 2 million page views a month (instead of days) that’s 6-minutes a month ... you get back about 1.5 hours, not days, in a year.

Oh, this is fun...now for mine with {$variable} substitution in double-quotes vs concatenation with single quotes:


But all fun aside, my point was that you should test it yourself, in context, and choose the best path based on all the factors, including how many times it’s going to be executed.

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

I personally think "like {$this}" is much more readable in most situations . . .

Funny, I was just thinking exactly the opposite. Whenever I see {$that}, my first thought is that it’s a chunk. Mentally, I have to do an extra level of processing to "unquote" the variable.

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

Bob