It’s important to define standards that will be used on the Drupal project prior to the start of the project especially if the project is big. Thus everyone involved in the project will understand which rules should be respected during development and maintenance of the project.
It’s required for:
- Simplify support of the project because it will be simpler to sort out in the project.
- Facilitate entry for new developers - they will understand what and how to do due to described requirements.
- Lower risks of appearance of compatibility issues.
- Avoid problems in communications between team members.
Release naming convention.
Work on a project usually happens through iterations. System of releases is used. Each release contains specific functionality. In the beginning we should define naming convention for releases.
You can introduce any rules for release naming convention but you also may use Semantic Versioning standard. It was created by one of the creators of GitHub and nowadays is used on many projects. Professional developers are familiar with this standard so it will be easy to introduce it on your projects.
Drupal has used its own release naming convention for core and modules like 7.x-*, 8.x-* till Drupal 8 version. But then it was decided to switch to Semantic Versioning (more details about it).
Drupal coding standards
I think that most Drupal developers know about Drupal coding standards. These standards describe code formatting, naming and location of files, architectural patterns. These standards are mandatory for Drupal projects, especially if you develop modules for the community.
Here I would like to note that Drupal coding standards don’t cover composer.json files that use 4 space indent instead of 2 in Drupal files.
You can use a continuous integration system to validate your code using PHP CodeSniffer. Also GrumPHP can be used to disallow you commit wrong code to GIT.
You use external PHP libraries during development of Drupal projects (for example, PHP CodeSniffer or GrumPHP that have been mentioned above). It’s recommended to use “PHP Standard Recommendations (PSR)” in designing and development of PHP libraries . These recommendations allow you to embed PHP libraries easily or develop reusable libraries. For instance, standard PSR-4 is a key point of Composer.
CSS in Drupal project should satisfy Drupal coding standards.
As mentioned in the documentation Drupal uses architectural pattern “Scalable and Modular Architecture for CSS (SMACSS)”. Unfortunately it isn’t convenient in all cases so BEM (Block, Element, Modifier) methodology is becoming more widespread in theme development. BEM uses idea of building themes based on the components and is suited best for creation of components library that can be used in your theme. If you don’t use components then BEM is acceptable for class naming of page elements.
*.js files in the
core/misc folder. Developers work with
*.es6.js files but
Can code quality be standardised?
As I know, industry standards for code quality don’t exist. But we can measure quality by specific parameters, for example:
- Test coverage.
- Existing code duplication.
- Whether comments exist or not.
- Code complexity.
When conducting a code review, you can be guided by the principles SOLID):
- Single-responsibility principle - A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.
- Open–closed principle - “Software entities … should be open for extension, but closed for modification.”
- Liskov substitution principle - “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
- Interface segregation principle - “Many client-specific interfaces are better than one general-purpose interface.”
- Dependency inversion principle - One should “depend upon abstractions, not concretions.”
All computer programmers should use these principles in code development but this is not always happening. Introducing these principles as a standard of passing code review allows us to determine clear rules of qualitative code.
Standard environment for all developers
Projects often have problems associated with using different environments on the local computers of developers. For example, different versions of software can behave differently or some functions may not work on the local machine and need to spend time on the system configuration. To avoid such issues, use a standard environment for all developers in your team.
Docker containers of virtual machines with Vagrant can be used to set up a unified environment. Also pre-configured environments such as DrupalVM, Lando, Docksal may be used to build your environment.
As you see there are lots of various standards that you should use in the Drupal projects. Also such standards can be mentioned: patch naming, git branches naming, commit messages convention, You decide what you need and what not. The history of programming shows that the introduction of standards helps to work on projects, especially when lots of people involved. I just want to note that it is worth approaching this issue thoughtfully so that standards help you, and not interfere with your work.