Hello Bertrand,

Thank for this, that's VERY useful !

I'm a bit confused about conding standard on class name. You say that class name are Upper Camel Case with a prefix "ezp". But ezp doesn't begin with a capital so it's not Upper Camel Case ? 

Also you give an exemple "FooProvider::factory()" and it's not prefixed with ezp and is Upper Camel Case. So, is prefixed class with ezp only for internal used in eZSystems ? What should we use in extension ? Is a prefix needed ?

Cheers !

Hello,

Thank you for this big work ! What about //autogentag// in extensions ?

Hello,

Thank you for this big work ! What about //autogentag// in extensions ?

It is valid for extensions built by our build server, but won't be applied to community ones, as they're not built this way. This would require a completely different project I'm afraid

I'm a bit confused about conding standard on class name. You say that class name are Upper Camel Case with a prefix "ezp". But ezp doesn't begin with a capital so it's not Upper Camel Case ? 

Also you give an exemple "FooProvider::factory()" and it's not prefixed with ezp and is Upper Camel Case. So, is prefixed class with ezp only for internal used in eZSystems ? What should we use in extension ? Is a prefix needed ?

About Camel Case, the standard is actually LowerCamelCase due to the prefix. It isn't an easy question, actually, but I would propose the following:

• The class name, prefix ignored, uses UpperCamelCase
• The prefixes for ezpublish are ezp (for ezpublish) and ezx (for ez extensions)
• Community / Market extensions must use their own prefix, either based on the extension name or the provider name

So yes, ezp / ezx are to be reserved to eZ Systems, and a prefix is required for extensions. We will update this when we start using namespaces ourselves (soon !).

I'll update the document accordingly, thanks !

Oh, and the FooProvider class is of course a mistake, it will be fixed to ezpFooProvider

Modified on Friday 27 May 2011 12:08:58 pm by Bertrand Dunogier

Looks good.

"Torough documentation"  should be "Thorough documentation"

No mention of line length?

Looks good.

"Torough documentation"  should be "Thorough documentation"

No mention of line length?

Thank you for highlighting my english mistakes in huge black letters, Bruce, I'll fix this soon

Did I really forget line length ? My god, thanks, todo list as well !

Hey Bertrand

Opps. Sorry about the big back letters - cut n paste from the google doc.  Had assumed that they would be stripped on publishing since headings are not available in the OE toolbar. What else can be pasted into these???

Are there plans to create/release a php CodeSniffer rule set based on the standard?  

Cheers
Bruce 

Bertrand B

Opps. Sorry about the big back letters - cut n paste from the google doc.  Had assumed that they would be stripped on publishing since headings are not available in the OE toolbar.

Hmmm headings ARE available in the OE toolbar, but not when replying in comments... maybe they're just removed from the UI but not from the supported XHTML? This wouldn't be surprising...

No offense taken anyway, it was kinda funny

Are there plans to create/release a php CodeSniffer rule set based on the standard? 

It is part of the plan, yes !

I don`t wanna use xdebug.... I am stuck with Zend Debugger

So the doc should say should use a debugger.

Hi there. Really great work!. 

A question. Are there any plans to apply this standards specially those related with phpdoc things to the actual code? or at least, do you think that contributions related to this (changing doxygen to phpdoc) will be helpful or do you prefer community member take care of other things?

thanks!

Hi Carlos,

The current approach is to change the comments format by small steps when working on a specific file/class/method (see this commit for instance) but as always, you are free (and welcome ) to open some pull requests on this topic (and/or any other )

Cheers

I don`t wanna use xdebug.... I am stuck with Zend Debugger

So the doc should say should use a debugger.

Hehe, okay, I will make the title more generic, but Xdebug will still be recommended, as quite a lof of developers don't use a debugger at all, and we recommend Xdebug. Thanks

Thank's for the standard.

I have a question about the the following convention:

>>

Files

Naming

Files MUST be named in lower-case, and MUST NOT use any separators (dashes, spaces,
underscores). PHP files MUST use the .php extension Template files MUST use the .tpl
extension.

>>

If i understood it right the following naming of a template is not allow anymore

because of "MUST NOT use any separator"

design/standard/override/templates/node/view/full/jac_folder_gallery.tpl

An other example you can see in github of our cjw_newsletter extension:

https://github.com/cjw-network/cjw_newsletter/tree/master/design/admin2/override/templates/node/view/full

or

https://github.com/cjw-network/cj.../tree/master/design/admin2/templates

I don't think that this is a good idea. We heavily use underscores in tpl files to have a better overview / structure over the templates. The templates often have the same name as the related ez content class name s where you can use "underscores". The underscore is also used by ez in some php filenames e.g.

kernel/content/function_definition.php

or in a lot of tpl files

design/standard/templates/popup_pagelayout.tpl

 

My proposal is to change the text to:

"Files

Naming

Files MUST be named in lower-case, and MUST NOT use any separators (dashes, spaces) except
underscores. PHP files MUST use the .php extension Template files MUST use the .tpl
extension."

What do you think?

Hi Bertrand,

what is about the coding standard for ez templates?

I think this should be included in the document, too.

Hi Betrand

it seems to me that the heredoc exmple is misleading, as it WILL expand variables and such.

I don`t wanna use xdebug.... I am stuck with Zend Debugger

So the doc should say should use a debugger.

Made the paragraph more generic, thanks !

Those coding standard are on PHP code only, we should probably add some coding standards for HTML, CSS and above all JavaScript.

Cheers

The reply has been removed because of violation of forum rules.

Those coding standard are on PHP code only, we should probably add some coding standards for HTML, CSS and above all JavaScript.

How about standards for indenting templates?

I find it hard to do, because you may effectively have two levels of indentation, intermingled: the HTML and the template code.  Any suggestions on best practices for that?

As there're a bunch of tools to check html/css/js, I think it's a waste of time to establish standard to write those...