1. What is CamelCase Coding Standard?
CamelCase is a naming convention in which a name is formed of multiple words that are joined together as a single word with the first letter of each of the multiple words capitalized so that each word that makes up the name can easily be read.
2. What are the advantage of CamelCase?
The advantage of CamelCase is that in any computer system where the letters in a name have to be contiguous (no spaces), a more meaningful name can be created using a descriptive sequence of words without violating the naming limitation.
3. Explain the difference between UpperCamelCase and lowerCamelCase?
In UpperCamelCase, the first letter of the new word is upper case, allowing it to be easily distinguished from a lowerCamelCase name, in which the first letter of the first name is lower case.
4. From where the name CamelCase derived?
The name derives from the hump or humps that seem to appear in any CamelCase name.
5. List the naming conventions in Coding Standards?
☆ Use camelCase, not underscores, for variable, function and method names, arguments;
☆ Use underscores for option names and parameter names;
☆ Use namespaces for all classes;
☆ Prefix abstract classes with Abstract. Please note some early Symfony classes do not follow this convention and have not been renamed for backward compatibility reasons. However all new abstract classes must follow this naming convention;
☆ Suffix interfaces with Interface;
☆ Suffix traits with Trait;
☆ Suffix exceptions with Exception;
☆ Use alphanumeric characters and underscores for file names;
☆ For type-hinting in PHPDocs and casting, use bool (instead of boolean or Boolean), int (instead of integer), float (instead of double or real);
☆ Don't forget to look at the more verbose Conventions document for more subjective naming considerations.
6. What is the structure of Coding Standard?
☆ Add a single space after each comma delimiter;
☆ Add a single space around binary operators (==, &&, ...), with the exception of the concatenation (.) operator;
☆ Place unary operators (!, --, ...) adjacent to the affected variable;
☆ Add a comma after each array item in a multi-line array, even after the last one;
☆ Add a blank line before return statements, unless the return is alone inside a statement-group (like an if statement);
☆ Use braces to indicate control structure body regardless of the number of statements it contains;
☆ Define one class per file - this does not apply to private helper classes that are not intended to be instantiated from the outside and thus are not concerned by the PSR-0 standard;
☆ Declare class properties before methods;
☆ Declare public methods first, then protected ones and finally private ones. The exceptions to this rule are the class constructor and the setUp and tearDown methods of PHPUnit tests, which should always be the first methods to increase readability;
☆ Use parentheses when instantiating classes regardless of the number of arguments the constructor has;
☆ Exception message strings should be concatenated using sprintf.
7. What are the conditions of CamelCase coding standard?
☆ The first letter is capitalized.
☆ One or more letters in that word are also capitalised.
☆ The word does not end on a capitalized letter: CamelCasE
☆ No two capitalised letters shall follow directly each other: CamelCAse
☆ No number in that word at any place: CamelCase1more
☆ No dot(.), under_score or dash (-) within the word, only letters: Camel_Case
8. From where CamelCase gained popularity?
The coding standard CamelCase gained popularity as a convention with WikiWiki (pronounced wikee wikee; wiki means "quick" in Hawaiian) software, which automatically creates and identifies hypertext links in Web pages and is used in Wikipedia, the user-contributed encyclopedia. CamelCase is now used in a number of World Wide Web Consortium-recommended protocols, such as the Simple Object Access Protocol (SOAP), Synchronized Multimedia Integration Language (SMIL), and Extensible Markup Language (XML).
9. Explain Documentation Libraries?
The documentation rules are almost exactly the same as for Scripts "Documenting scripts". Although from a technical point of view it is feasible to place procedures in libraries it is not common to do that. Functions are a better alternative as they accept parameter passing.
10. Documentation Introduction
Documentation is done to provide others with information and ease maintenance. The best documentation is done in the headers (function and scripts) and directly in the code. Any useful thoughts ie a chosen algorithm or a solution to a specific problem should be documented in order to help others understand the script(s) and/or function(s).
