General Coding Practices
- Parameters and logic set at the beginning of the function.
- At most 3 tabs of indentation.
- Keep line widths to a sensible maximum.
- If you need more than two parameters for a component function better use a params array and document it.
- Every component should be described as a set of functions
- Every function should be no longer than a 100 lines, better to be less.
- Component functions should be as pure as possible – take an input and return an object (with few exceptions).
- Name of the trait should be the same as the name of the function – remove “get” prefix
- Take away view logic as components if there is a chance for them to be reused or to abstract complex view logic
- Inline styles only for development when they need to be dynamic (rely on screen width for example)
- Unique identifiers for the styles or prefixes
- Put any component styles into it’s own style file where the name of the file is the same as the name of the component
Most common problems
- Not using isset is the most common reason for errors.
- Make sure that none of the objects are sent null values.