Making compliant to "aik099/coding-standard"

[aik099]

• Stage 1: fixing whitespaces
• Stage 2: renaming variables and non-public class properties
• Stage 3: fixing DocBlocks (adding missing descriptions, converting from inline DocBlocks to multi-line DocBlocks)
• Stage 4: misc (variable assignment in loops and conditionals, join usage instead of implode, ...)

Closes #62

[aik099]

@jpastoor , please review. I've specially made several commits to simplify review process.

[jpastoor]

Great work in unifying the codebase and putting it onder a convention.

I'm no fan of "custom codestyles" and had much rather copied something like the Symfony convention then your personal list of prefs.

It will work for me though and guess focus should now be on making it as easy for developers to hook in. Maybe providing Vagrant config with the standard preconfigured and maybe add a phpStorm config for the auto formatter or something.

[aik099]

Coding standards is an interesting topic really, because there is no coding standard that will fit need of every developer on a team. Not even PSR2 can do that. That's why people recommend to observe needs and habits of every developer on a team and create a standard based on formatting that is encountered in most of the code. That when initial version of my coding standard was created. I've used it not only for my FOSS projects, but also for all projects in the company I'm working in.

Since PHP_CodeSniffer 2.0 release, where auto-fixing was enabled ensuring better life for developer (where phpcbf would fix all the code for them) was a priority for me and unfortunately majority of custom standards out there offered zero to none auto-fixing capabilities.

Over time I've analyzed mistakes people make and enhanced my standard even more to report them in time to make code base even more consistent.

To summarize I believe standard, that checks all that it can is better, then standard that leaves too much room for developer imagination in terms of code formatting.