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.
PHP CodeSniffer library with rules for Drupal is used to check coding standards. You can find instruction how to install it here. Lots of Drupal boilerplate projects include this library.
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.
PHP standards
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 standards
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.
Javascript standards
There are Drupal standards for Javascripts. But besides it you should define what version of Javascript to use on the project.
Drupal core uses Javascript of standard ES6 (EcmaScript 2015). There are *.es6.js и *.js files in the core/misc folder. Developers work with *.es6.js files but *.js files, that are loaded by browsers, generated by Javascript compiler Babel. Such code is fully compatible with old browsers that don’t support ES6 standard.
You should decide what version of Javascript to use on the project but better to do it earlier. You can use the familiar standard ES5 that was used in Drupal 6 and 7 or ES6 + Babel if you need to support outdated browsers. If only modern browsers are supported by your project you can use standard ES6 that is supported by all browsers released after 2013. Also you can take ES7 or ES8 + Babel if you need all the advantages of the latest Javascript versions and it’s planned to support your project for long.
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.
Such parameters can be checked using tools PHP MessDetector or SonarQube for which you can set custom rules. Code duplication can be found using library PHP Copy/Paste Detector.
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.
Resume
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.