I would suggest following schedule for the coming month:

• Xoops Engine Alpha 3 release: on August 13th
• github repo structure change, github usage guide: D.J., julionc, by July 24th
• ZF upgrade to 1.11.9, change naming conventions to respect ZF strictly: D.J., by July 24th
• Backend product and UE design: ezsky, by July 31st
• Backend design implementation: D.J., by August 7th
• Debug and complete “user” module and ACL: D.J., dongbeta, by July 31st
• Content management app: dongbeta, by August 7th
• Theme and HTML5: voltan, kris_fr, mariane, by August 7th
• Documentation: julionc, dongbeta, by August 13th
• Test: marco, by August 13th

Yes, as you see, we have some people back onboard, like marco!
Anyone else have time on this Alpha 3 release loop?
We need more people on documentation, apps, themes and test.

On twitter: @XoopsProject

APC has been a very favorite recommendation due to its high performance while memcached is also widely adopted for its stable and performance. However when Redis comes up with its simple but very demanded features, it is on top of our list due to its excellent performance which is comparable with memcached (antirez, sys/toilet, Tim), and the most desires feature of supporting advanced data structure in addition to strings:

• Lists of strings
• Sets of strings
• Sorted sets of strings
• Hashes

There have been some clients available for PHP, like Predis in PHP by nrk and PhpRedis in C by nicolasff. The PhpRedis extension has been installed and implemented in Xoops Engine on a ubuntu/nginx/php-fpm stack at Xoops Engine Demo. Thank Nicolas (@yowgi) for his help on serialize option via tweets.

What’s next? We might do a thorough benchmark with Redis and Xoops Engine, probably considering igbinary extension, then adopt PhpRedis into extended ZF2 libary .

Build development environment for developers and designers.

Some of my personal plans related to XE:

• Tutorials for development tools
• Introduction to Zend Framework development
• Unit test investigation considering ZF2
• App/module builder

* Xoops Engine Alpha 2 installation on wamp server
* Xoops Engine Alpha 2 after installation

Although txmodxoops had not so successful experiences, participating and sharing is the first step to improve our new system.

Soon after the two videos, mamba shared his two videos:
* Installing Xoops Engine Alpha 2 on WAMP server
* Installing XOOPS legacy modules in Xoops Engine

For deployment and installation on nix systems please check :
* Xoops Engine Alpha 2 deployment and permission settings
* Xoops Engine Alpha 2 installation on ubuntu/nginx stack

Please share your Xoops Engine experiences on twitter with @XoopsProject casually but quickly.
And report your issues to Github issue tracker

Since the Alpha 1 Release in January 2011, there have been many progresses in Xoops Engine development. XOOPS, or eXtensible Object Oriented Portal System, well known as a leading open source CMS and portal system, now becomes a development engine for web and mobile applications.

XoopsEngine, as the new brand of the XOOPS Project, supports open and extensible engines backboned with its multi-engine architecture. By taking advantages of PHP frameworks like Zend Framework, template engine Smarty and AJAX libraries like jQuery, the Xoops Engine brings the Project to a new generation.

Some selected features that are most wanted by community available in Xoops Engine:
* Built-in cache mechanism for high performance
* Clear M-V-C with AOP and event hook
* Extensible URL rewrite for better SEO
* App/module clone and theme inheritance for application extension
* New model mechanism for easy development with less code
* New layout/block/widget for flexible and better user experience

After Alpha1 release many developers have started to contribute to Xoops Engine development, including well know developers from other open source projects.
Some of the new progresses in Alpha 2:
* Namespace for apps and modules
* WYSIWYG editor factory with CKEditor and jQuery based ClEditor
* Security handler and resource, added XSS filter, IP protection, super global contamination, etc.
* Block and theme mechanism improvement
* Protection for config files
* First Xoops Engine themes by insraq and voltan
Special thank goes to Xoops China Team.

For more details please check:
* Xoops Engine Development: http://www.xoopsengine.org
* Follow us on twitter: http://twitter.com/XoopsProject
* Discussion: http://xoops.org/modules/newbb/index.php?cat=11

Don’t forget to download Xoops Engine Alpha 2:
* The full package
* Only the new engine
And report your issues to: https://github.com/xoops/engine/issues

Taiwen Jiang (aka phppp)
Xoops Engine Development Team
April 30th, 2011

Xoops Engine, the next generation of XOOPS system, is redesigned with brand-new architecture and development standards by adopting cutting-edge libraries like Zend Framework 2 and Smarty 3.

Following the first public press in Nov 2010 in Beijing and Alpha 1 release on January 27th, the Xoops Engine Alpha 2 is coming to us. We are very happy to see more and more contributors joining us. Some of the names might be known or not known to you: designers like insraq and voltan have made new themes for Xoops Engine, Dong Lijun leads a dev team with ezsky on kernel test and app development as well as tech docs, kilica starts working on Xoops Engine and will provide us a most-wanted app, Marcus starts on kernel review and relevant docs … The list is too long to mention here, you will see them very soon. There are some very talented developers from other well-known open source projects starting to work on Xoops Engine kernel and apps, they desire to not disclose their names at this moment but time won’t be long before they introduce themselves with their exciting apps.

The XOOPS 2.* series is being improved continuously. On April 8th 2011, XOOPS 2.5.1 Final was released following its RC on March 17. The 2.5 series has been an community based improvement over 2.3/2.4, some proof-of-concept features are also introduced for a smoothy migration to Xoops Engine.

In the coming months, we will continue the exciting activities to get Xoops Engine ready as early as possible. Meanwhile XOOPS 2.5* series is maintained for bugfixes and security improvements.

Recently Matthew Weier O’Phinney, lead developer for ZF, is working on “Zend Framework 2 Coding Standards” drafts.

At this moment, what I propose for Xoops Engine, in terms of naming conventions:

• for user extensions and third-party contributions, including apps, modules, plugins, themes, etc.,  use lower case for file names and case-insensitive for class names (related to autoloader, this might be changed in the future);
• otherwise, following ZF2 coding standards as proposed by Matthew below.

Zend Framework 2 Coding Standards

Overview

Scope

This document provides guidelines for code formatting and documentation to
individuals and teams contributing to Zend Framework. Many developers using Zend
Framework have also found these coding standards useful because their code’s
style remains consistent with all Zend Framework code. It is also worth noting
that it requires significant effort to fully specify coding standards.

Note: Sometimes developers consider the establishment of a standard more
important than what that standard actually suggests at the most detailed
level of design. The guidelines in Zend Framework’s coding standards capture
practices that have worked well on the Zend Framework project. You may
modify these standards or use them as is in accordance with the terms of our
license.

Topics covered in Zend Framework’s coding standards include:

• PHP File Formatting
• Naming Conventions
• Coding Style
• Inline Documentation

Goals

Coding standards are important in any development project, but they are
particularly important when many developers are working on the same project.
Coding standards help ensure that the code is high quality, has fewer bugs, and
can be easily maintained.

Conventions

This document attempts to follow RFC 2119’s verbiage for indicating requirements.

• MUST and MUST NOT indicate non-optional requirements
• SHOULD and SHOULD NOT indicate recommendations for which exceptions may exist
• MAY indicates truly optional requirements

PHP File Formatting

General

For files that contain only PHP code, the closing tag (?>) MUST NOT be used.
It is not required by PHP, and omitting it prevents the accidental injection of
trailing white space into the response.

Note: Important: Inclusion of arbitrary binary data as permitted by
__HALT_COMPILER() MUST NOT be used in PHP files in the Zend Framework
project or files derived from them. Use of this feature is only permitted
for some installation scripts.

Indentation

Indentation MUST consist of 4 spaces. Tabs MUST NOT be used for indentation.

Maximum Line Length

The target line length is 80 characters. That is to say, Zend Framework
developers SHOULD strive keep each line of their code under 80 characters where
possible and practical. However, longer lines are acceptable in some
circumstances. The maximum length of any line of PHP code is 120 characters.

Line Termination

Line termination follows the Unix text file convention. Lines MUST end with a
single linefeed (LF) character. Linefeed characters are represented as ordinal
10, or hexadecimal 0x0A.

Note: Do not use carriage returns (CR) as is the convention in Apple OS’s
(0x0D) or the carriage return – linefeed combination (CRLF) as is
standard for the Windows OS (0x0D, 0x0A).

Naming Conventions

Zend Framework standardizes on a class naming convention whereby:

• Namespaces have a 1:1 relationship to the filesystem.
• Classes are stored within the directory determined by the namespace.

The root directory of a library contains a directory named after the top-level
namespace; in the case of Zend Framework, the root directory would be
“library/”, as it contains the “Zend/” directory, which corresponds to the
top-level namespace within the Zend Framework distribution.

Namespaces

Namespaces MUST contain only alphanumeric characters, the underscore, and, of
course, the namespace separator (\).

Namespaces SHOULD be MixedCase, and acronyms used in namespaces should as well.
As examples:

• the namespace “Zend\PDF” would not be allowed, while “Zend\Pdf” is
  acceptable.
• the namespace “Zend\XMLRPC” would not be allowed, while “Zend\XmlRpc” is
  acceptable.

Underscores in namespaces have no special meaning, and will not be translated to
the directory separator.

Code deployed alongside Zend Framework libraries but which is not part of the
Zend Framework standard distribution SHOULD utilize separate namespaces.

Classes

Class names MUST contain only alphanumeric characters and the underscore.
Numbers are permitted in class names but are discouraged in most cases.
Underscores are only permitted in place of the path separator; a class named
“Do_Something” would map to the filename “Do/Something.php” (and potentially
under a hierarchy named after any

If a class name is comprised of more than one word, the first letter of each new
word MUST be capitalized. Successive capitalized letters are not allowed, e.g. a
class “Zend_PDF” is not allowed while “Zend_Pdf” is acceptable.

See the class names in the standard and extras libraries for examples of this
classname convention.

Abstract Classes

Abstract classes follow the same conventions as classes, with one additional
rule: abstract class names MUST begin with the term, “Abstract”. As examples,
“AbstractAdapter” and “AbstractWriter” are both considered valid abstract
class names.

Abstract classes SHOULD be in the same namespace as concrete implementations.
The following would be considered invalid usage:

namespace Zend\Log;

abstract class AbstractWriter implements Writer
{
}

namespace Zend\Log\Writer;

use Zend\Log\AbstractWriter;

class StreamWriter extends AbstractWriter
{
}

While the next example displays proper usage:

namespace Zend\Log\Writer;

use Zend\Log\Writer;

abstract class AbstractWriter implements Writer
{
}

class StreamWriter extends AbstractWriter
{
}

Interfaces

Interfaces follow the same conventions as classes, with one additional rule:
interface MUST be nouns or adjectives. As examples, “ServiceLocation”,
“EventCollection”, and “PluginLocator” are all considered appropriate
interface names.

Note: In many cases, it can be difficult to identify a good name for an
interface. As an example, for the EventManager component, the name
“EventManager” seemed like a likely candidate for both the gateway class as
well as the interface. In cases like these, try and identify the behavior
described by the interface; in this particular case, we named the interface
“EventCollection”, as it described a collection of events and handlers, and
the class retained the name of “EventManager” as it was a concrete
implementation with actual behaviors that could be called.

Filenames

All other PHP files MUST only use alphanumeric characters, underscores, and the
dash character (“-”). Spaces are strictly prohibited.

Any file that contains PHP code SHOULD end with the extension “.php”, with the
notable exception of view scripts. The following examples show acceptable
filenames for Zend Framework classes:

Zend/Db.php

Zend/Controller/Front.php

Zend/View/Helper/FormRadio.php

File names MUST map to class names as described above.

Functions and Methods

Function names MUST contain only alphanumeric characters. Underscores are not
permitted. Numbers are permitted in function names but are discouraged.

Function names MUST always start with a lowercase letter. When a function name
consists of more than one word, the first letter of each new word MUST be
capitalized. This is commonly called “camelCase” formatting.

Verbosity is encouraged. Function names should be as verbose as is practical to
fully describe their purpose and behavior.

These are examples of acceptable names for functions:

filterInput()

getElementById()

widgetFactory()

For object-oriented programming, accessors for instance or static variables
SHOULD be prefixed with “get” or “set”. In implementing design patterns, such as
the singleton or factory patterns, the name of the method SHOULD contain the
pattern name where practical to more thoroughly describe behavior.

For methods on objects that are declared with the “private” or “protected”
modifier, the first character of the method name MAY be an underscore. This is
the only acceptable application of an underscore in a method name, and is
discouraged (as it makes refactoring to public visibility more difficult).
Methods declared “public” SHOULD NOT contain an underscore.

Functions in the global scope (a.k.a “floating functions”) MAY be used, but are
discouraged. Consider wrapping these functions in a static class, or within a
specific namespace.

Variables

Variable names MUST contain only alphanumeric characters. Underscores are not
permitted. Numbers are permitted in variable names but are discouraged in most
cases.

For variables that are declared with private or protected visibility, the
first character of the variable name MAY be a single underscore. This is the
only acceptable application of an underscore in a variable name, and is
discouraged (as it makes refactoring to public visibility more difficult).
Member variables declared with public visibility SHOULD NOT start with an
underscore.

As with function names, variable names MUST always start with a lowercase letter
and follow the “camelCaps” capitalization convention.

Verbosity is encouraged. Variables should always be as verbose as practical to
describe the data that the developer intends to store in them. Terse variable
names such as “$i” and “$n” are discouraged for all but the smallest loop
contexts. If a loop contains more than 20 lines of code, the index variables
should have more descriptive names.

Constants

Constant names MAY contain both alphanumeric characters and underscores.

All letters used in a constant name MUST be capitalized, while all words in a
constant name MUST be separated by underscore characters.

For example, EMBED_SUPPRESS_EMBED_EXCEPTION is permitted but
EMBED_SUPPRESSEMBEDEXCEPTION is not.

Constants MUST be defined as class members with the “const” modifier. Constants
MAY be defined in the global scope or within namespaces.

Coding Style

PHP Code Demarcation

PHP code MUST always be delimited by the full-form, standard PHP tags:

<?php

?>

The closing PHP tag (?>) MUST be omitted if no markup or code follows it.

Short tags MUST NOT be used within Zend Framework library code, but MAY be used
within view scripts.

Strings

String Literals

When a string is literal (contains no variable substitutions), the apostrophe or
“single quote” SHOULD be used to demarcate the string:

$a = 'Example String';

String Literals Containing Apostrophes

When a literal string itself contains apostrophes, you MAY demarcate the string
with quotation marks or “double quotes”. This is especially useful for SQL
statements:

$sql = "SELECT `id`, `name` from `people` "
     . "WHERE `name`='Fred' OR `name`='Susan'";

This syntax is preferred over escaping apostrophes as it is much easier to read.

Variable Substitution

Variable substitution SHOULD use either of the folowing forms:

$greeting = "Hello $name, welcome back!";

$greeting = "Hello {$name}, welcome back!";

For consistency, this form SHOULD NOT be used:

$greeting = "Hello ${name}, welcome back!";

String Concatenation

Strings MUST be concatenated using the “.” operator. A space MUST always be
added before and after the “.” operator to improve readability:

$company = 'Zend' . ' ' . 'Technologies';

When concatenating strings with the “.” operator, one SHOULD break the statement
into multiple lines to improve readability. In these cases, each successive line
SHOULD be padded with white space such that the “.”; operator is aligned under
the “=” operator:

$sql = "SELECT `id`, `name` FROM `people` "
     . "WHERE `name` = 'Susan' "
     . "ORDER BY `name` ASC ";

Class Names In Strings

When referencing a class name in a string, the fully qualified class name MUST
be provided, and MUST NOT include a preceding namespace separator. As an
example, if in the namespace “Zend\Log”, and referencing the class
“StreamWriter” in the “Writer” subnamespace, you would use the string
“Zend\Log\Writer\StreamWriter”.

Arrays

Numerically Indexed Arrays

When declaring indexed arrays with the array function, a trailing space MUST
be added after each comma delimiter to improve readability:

$sampleArray = array(1, 2, 3, 'Zend', 'Studio');

It is permitted to declare multi-line indexed arrays using the array
construct. In this case, each successive line MUST be padded with spaces such
that beginning of each line is aligned:

$sampleArray = array(1, 2, 3, 'Zend', 'Studio',
                     $a, $b, $c,
                     56.44, $d, 500);

Alternately, the initial array item MAY begin on the following line. If so, it
MUST be padded at one indentation level greater than the line containing the
array declaration, and all successive lines MUST have the same indentation;
the closing paren MUST be on a line by itself at the same indentation level as
the line containing the array declaration:

$sampleArray = array(
    1, 2, 3, 'Zend', 'Studio',
    $a, $b, $c,
    56.44, $d, 500,
);

When using this latter declaration, you SHOULD use a trailing comma for the
last item in the array; this minimizes the impact of adding new items on
successive lines, and helps to ensure no parse errors occur due to a missing
comma.

Associative Arrays

When declaring associative arrays with the array construct, one SHOULD break
the statement into multiple lines. In this case, each successive line MUST be
padded with white space such that both the keys and the values are aligned:

$sampleArray = array('firstKey'  => 'firstValue',
                     'secondKey' => 'secondValue');

Alternately, the initial array item MAY begin on the following line. If so, it
MUST be padded at one indentation level greater than the line containing the
array declaration, and all successive lines MUST have the same indentation;
the closing paren MUST be on a line by itself at the same indentation level as
the line containing the array declaration. For readability, the various “=>”
assignment operators SHOULD be padded such that they align.

$sampleArray = array(
    'firstKey'  => 'firstValue',
    'secondKey' => 'secondValue',
);

When using this latter declaration, one SHOULD use a trailing comma for the
last item in the array; this minimizes the impact of adding new items on
successive lines, and helps to ensure no parse errors occur due to a missing
comma.

Namespaces

Namespace Declaration

Files SHOULD contain a single namespace; composing multiple namespaces in a
single file is strongly discouraged.

Namespace declarations MUST be the first statement in a file, unless multiple
namespaces are declared; the only code that should precede the declaration
should be a file-level documentation block, with a single empty line between the
docblock and the namespace declaration.

Namespace declarations done according to the above MUST NOT have any
indentation.

In the case that multiple namespace declarations must be placed in the same
file, such declarations MUST utilize blocks and not single-line declarations.
The opening brace MUST be placed on the following line at the same level of
indentation, and all code within the block MUST receive an extra level of
indentation. For example, the following is invalid:

namespace Foo;

// some code...

namespace Bar;

// more code...

But the following is correct:

namespace Foo
{
    // some code ...
}

namespace Bar
{
    // more code ...
}

Import Statements

All explicit dependencies used by a class MUST be imported. These include
classes and interfaces used in method typehints and explicit instanceof type
checks, classes directly instantiated, etc. Exceptions include:

• Code within the current namespace or subnamespaces of the current namespace
• Class names that are dynamically resolved (e.g., from a plugin broker)

Import statements MUST be declared once, at the top of the file, following the
namespace declaration. The use statement SHOULD be issued once, with one
class (and optional alias) per line, separated by commas and terminated on the
last import by a semicolon; class names SHOULD be aligned:

use Zend\Log\Logger,
    Zend\Event\Eventmanager as Events,
    Zend\View\PhpRenderer as View;

Classes

Class Declaration

Classes MUST be named according to Zend Framework’s naming conventions.

The brace MUST be written on the line underneath the class name, at the same
level of indentation as the class declaration.

Every class MUST have a documentation block that conforms to the PHPDocumentor
standard.

All code in a class MUST be indented with four spaces additional to the level of
indentation of the class declaration.

PHP files declaring classes MUST contain a single PHP class only.

Placing additional code in class files MAY be done, but is discouraged. In such
files, two blank lines MUST separate the class from any additional PHP code in
the class file.

The following is an example of an acceptable class declaration:

/**
 * Documentation Block Here
 */
class SampleClass
{
    // all contents of class
    // must be indented four spaces
}

Classes that extend other classes or which implement interfaces SHOULD declare
their dependencies on the same line when possible.

class SampleClass extends FooAbstract implements BarInterface
{
}

If as a result of such declarations, the line length exceeds the maximum line
length, break the line before the extends and/or implements keywords, and
pad those lines by one indentation level.

class SampleClass
    extends FooAbstract
    implements BarInterface
{
}

If the class implements multiple interfaces and the declaration exceeds the
maximum line length, break after each comma separating the interfaces, and
indent the interface names such that they align.

class SampleClass
    implements BarInterface,
               BazInterface
{
}

Class Member Variables

Member variables MUST be named according to Zend Framework’s variable naming
conventions.

Any variables declared in a class MUST be listed at the top of the class, above
the declaration of any methods.

The var construct MUST NOT be used. Member variables MUST declare their
visibility by using one of the private, protected, or public visibility
modifiers. Giving access to member variables directly by declaring them as
public MAY be done, bug is discouraged in favor of accessor methods (set &

get).

Functions and Methods

Function and Method Declaration

Functions MUST be named according to Zend Framework’s function naming
conventions.

Methods inside classes MUST always declare their visibility by using one of the
private, protected, or public visibility modifiers.

As with classes, the brace MUST always be written on the line underneath the
function name. Space MUST NOT be inserted between the function name and the
opening parenthesis for the arguments.

Functions SHOULD NOT be declared in the global scope.

The following is an example of an acceptable function declaration in a class:

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * Documentation Block Here
     */
    public function bar()
    {
        // all contents of function
        // must be indented four spaces
    }
}

In cases where the argument list exceeds the maximum line length, you MAY
introduce line breaks. Additional arguments to the function or method MUST be
indented one additional level beyond the function or method declaration. A line
break MUST occur before the closing argument paren, which MUST be placed on the
same line as the opening brace of the function or method with one space
separating the two, and at the same indentation level as the function or method
declaration. The following is an example of one such situation:

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * Documentation Block Here
     */
    public function bar($arg1, $arg2, $arg3,
        $arg4, $arg5, $arg6
    ) {
        // all contents of function
        // must be indented four spaces
    }
}

Note: Pass-by-reference is the only parameter passing mechanism permitted in
a method declaration.

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * Documentation Block Here
     */
    public function bar(&$baz)
    {}
}

Call-time pass-by-reference MUST NOT be used.

The return value MUST NOT be enclosed in parentheses. This can hinder
readability, in addition to breaking code if a method is later changed to return
by reference.

/**
 * Documentation Block Here
 */
class Foo
{
    /**
     * WRONG
     */
    public function bar()
    {
        return($this->bar);
    }

    /**
     * RIGHT
     */
    public function bar()
    {
        return $this->bar;
    }
}

Function and Method Usage

Function arguments MUST be separated by a single trailing space after the
comma delimiter. The following is an example of an acceptable invocation of a
function that takes three arguments:

threeArguments(1, 2, 3);

Call-time pass-by-reference MUST NOT be used. See the function declarations
section for the proper way to pass function arguments by-reference.

In passing arrays as arguments to a function, the function call MAY include the
array declaration and MAY be split into multiple lines to improve readability.
In such cases, the normal guidelines for writing arrays still apply:

threeArguments(array(1, 2, 3), 2, 3);

threeArguments(array(1, 2, 3, 'Zend', 'Studio',
                     $a, $b, $c,
                     56.44, $d, 500), 2, 3);

threeArguments(array(
    1, 2, 3, 'Zend', 'Studio',
    $a, $b, $c,
    56.44, $d, 500
), 2, 3);

Control Statements

If/Else/Elseif

Control statements based on the if and elseif constructs MUST have a single
space before the opening parenthesis of the conditional and a single space after
the closing parenthesis.

Within the conditional statements between the parentheses, operators MUST be
separated by spaces for readability. Inner parentheses SHOULD be used to improve
logical grouping for larger conditional expressions.

The opening brace MUST be written on the same line as the conditional statement.
The closing brace MUST be written on its own line. Any content within the braces
MUST be indented using four spaces.

if ($a != 2) {
    $a = 2;
}

If the conditional statement causes the line length to exceed the maximum line
length and has several clauses, you MAY break the conditional into multiple
lines. In such a case, break the line prior to a logic operator, and pad the
line such that it aligns under the first character of the conditional clause.
The closing paren in the conditional will then be placed on a line with the
opening brace, with one space separating the two, at an indentation level
equivalent to the opening control statement.

if (($a == $b)
    && ($b == $c)
    || (Foo::CONST == $d)
) {
    $a = $d;
}

The intention of this latter declaration format is to prevent issues when adding
or removing clauses from the conditional during later revisions.

For if statements that include elseif or else, the formatting conventions
are similar to the if construct. The following examples demonstrate proper
formatting for if statements with else and/or elseif constructs:

if ($a != 2) {
    $a = 2;
} else {
    $a = 7;
}

if ($a != 2) {
    $a = 2;
} elseif ($a == 3) {
    $a = 4;
} else {
    $a = 7;
}

if (($a == $b)
    && ($b == $c)
    || (Foo::CONST == $d)
) {
    $a = $d;
} elseif (($a != $b)
          || ($b != $c)
) {
    $a = $c;
} else {
    $a = $b;
}

PHP allows statements to be written without braces in some circumstances. This
coding standard makes no differentiation; all if, elseif or else

statements MUST use braces.

Switch

Control statements written with the switch statement MUST have a single space
before the opening parenthesis of the conditional statement and after the
closing parenthesis.

All content within the switch statement MUST be indented using four spaces.
Content under each case statement MUST be indented using an additional four
spaces.

switch ($numPeople) {
    case 1:
        break;

    case 2:
        break;

    default:
        break;
}

The construct default SHOULD NOT be omitted from a switch statement.

Note: It is sometimes useful to write a case statement which falls through
to the next case by not including a break or return within that case. To
distinguish these cases from bugs, any case statement where break or

return are omitted MUST contain a comment indicating that the break was
intentionally omitted.

Inline Documentation

Documentation Format

All documentation blocks (“docblocks”) MUST be compatible with the phpDocumentor
format. Describing the phpDocumentor format is beyond the scope of this
document. For more information, visit: http://phpdoc.org/

All class files MUST contain a “file-level” docblock at the top of each file and
a “class-level” docblock immediately above each class. Examples of such
docblocks can be found below.

General Notes

Classes and interfaces referenced by annotations MUST follow the same resolution
order as PHP. In other words:

• If the class is in the same namespace, simply refer to the class name without
  the namespace:

  namespace Foo\Component;
  
  class Bar
  {
      /**
       * Assumes Foo\Component\Baz:
       * @param Baz $baz
       */
      public function doSomething(Baz $baz)
      {
      }
  }
  

• If the class is in a subnamespace of the current namespace, refer to it
  relative to the current namespace:

  namespace Foo\Component;
  
  class Bar
  {
      /**
       * Assumes Foo\Component\Adapter\Baz:
       * @param Adapter\Baz $baz
       */
      public function doSomething(Adapter\Baz $baz)
      {
      }
  }
  

• If the class is imported, either via a namespace or explicit class name, use
  the name as specified by the import:

  namespace Foo\Component;
  
  use Zend\EventManager\EventManager as Events,
      Zend\Log;
  
  class Bar
  {
      /**
       * Assumes Zend\EventManager\Eventmanager and Zend\Log\Logger:
       * @param Events $events
       * @param Log\Logger $log
       */
      public function doSomething(Events $events, Log\Logger $log)
      {
      }
  }
  

• If the class is from another namespace, but not explicitly imported, provide
  a globally resolvable name:

  namespace Foo\Component;
  
  class Bar
  {
      /**
       * Assumes \Zend\EventManager\Eventmanager:
       * @param \Zend\EventManager\EventManager $events
       */
      public function doSomething(\Zend\EventManager\EventManager $events)
      {
      }
  }
  

Note: This last case should rarely happen, primarily since you should be
importing any dependencies. One case where it may happen, however, is in
@return annotations, as return types might be determined outside the class
scope.

Files

Every file that contains PHP code MUST have a docblock at the top of the file
that contains these phpDocumentor tags at a minimum:

/**
 * Short description for file
 *
 * Long description for file (if any)...
 *
 * LICENSE: Some license information
 *
 * @category   Zend
 * @package    Zend_Magic
 * @subpackage Wand
 * @copyright  Copyright (c) 2005-2011 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license   BSD License
 */

The @category annotation MUST have a value of “Zend”.

The @package annotation MUST be assigned, and should be equivalent to the
component name of the class contained in the file; typically, this will only
have two segments, the “Zend” prefix, and the component name.

The @subpackage annotation is optional. If provided, it SHOULD be the
subcomponent name, minus the class prefix. In the example above, the assumption
is that the class in the file is either “Zend_Magic_Wand”, or uses that
classname as part of its prefix.

Classes

Every class MUST have a docblock that contains these phpDocumentor tags at a
minimum:

/**
 * Short description for class
 *
 * Long description for class (if any)...
 *
 * @category   Zend
 * @package    Zend_Magic
 * @subpackage Wand
 * @copyright  Copyright (c) 2005-2011 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license   BSD License
 */

The @category annotation MUST have a value of “Zend”.

The @package annotation MUST be assigned, and should be equivalent to the
component to which the class belongs; typically, this will only have two
segments, the “Zend” prefix, and the component name.

The @subpackage annotation is optional. If provided, it SHOULD be the
subcomponent name, minus the class prefix. In the example above, the assumption
is that the class described is either “Zend_Magic_Wand”, or uses that classname
as part of its prefix.

Functions

Every function, including object methods, MUST have a docblock that contains at
a minimum:

• A description of the function
• All of the arguments
• All of the possible return values

It is not necessary to use the @access annotation because the access level is
already known from the public, private, or protected visibility modifier
used to declare the function.

If a function or method may throw an exception, use @throws for all known
exception classes:

@throws exceptionclass [description]

Since Xoops Engine has been developed upon Zend Framework 1.* libraries but ZF2 style including namespaces and autoloaders have been implemented in Xoops Engine, it is time to for us to formulate Abstract/Interface conventions.

After some brief research and talking with @weierophinney on twitter, Abstract naming convention will follow ZF2 style, i.e. Xoops\Zend\[Component]\Abstract[Component]. As for interfaces, @weierophinney suggests nouns w/o suffix/prefix; I just feel it not consistent with Abstract, but we will follow the rule any way.