Currently we are using the twig convention for naming all of these which is
Going forward in 4.0 one of our goals is to completely separate all concerns which means the js does not directly touch or inject any html/css, the php code does not inject any html/css/js
This is considered a best practice to ensure a clean organized codebase as well as improving legibility and control of all aspects of the app.
Yet another of our goals related to this is to improve the clarity and confidence of our front-end code.
Which you can read more about here for how we are accomplishing this all with the CSS: https://area51.phpbb.com/docs/dev/devel ... amespacing
- How much information can we glean from the smallest possible source?
- Is our code self-documenting?
- Can we make safe assumptions from a single context?
- How much do we have to rely on external or supplementary information in order to learn about a system?
- Do we have enough knowledge about a system to be able to safely interface with it?
- Do we know enough about our code to be able to confidently make changes?
- Do we have a way of knowing the potential side effects of making a change?
- Do we have a way of knowing what we might be able to remove?
With all of this in mind the issue is with the naming of the twig functions as they do not meet all the aspects of clarity and confidence . It may not be possible to meet all of these but we should strive to meet as many as possible whenever building the front-end of any highly customizable or extendable application.
I am open to feedback on exactly how to accomplish this but some of the suggested ideas are as follows.
- Use PascalCase for the functions as this breaks standards for all front-end languages. However it is a major deviation from our local established standards
twig_for all the functions. This one is the most specific and descriptive and follows the same guidelines as the approach used for CSS.
- Similar to the above we could use an appended flag that more closely follows that of the CSS approach like
f_for function. This has the added benefit over the above of being short but also using a flag for the definition to make it more obvious that the first part of the name is not part of the name.
Keep in mind that this would require changes to all current twig functions to meet whatever new standard we enforce. EXPS: