This chapter defines coding guidelines for the TYPO3 project. Following these guidelines is mandatory for TYPO3 Core developers and contributors to the TYPO3 Core .
Extension authors are encouraged to follow these guidelines when developing extensions for TYPO3. Following these guidelines makes it easier to read the code, analyze it for learning or performing code reviews. These guidelines also help preventing typical errors in the TYPO3 code.
This chapter defines how TYPO3 code, files and directories should be outlined and formatted. It gives some thoughts on general coding flavors the Core tries to follow.
The CGL as a Means of Quality Assurance¶
Our programmers know the CGL and are encouraged to inform authors, should their code not comply with the guidelines.
Apart from that, adhering to the CGL is not voluntary: The CGL are also
enforced by structural means: Automated tests are run by the continuous
bamboo to make sure that every (core) code change complies
with the CGL. In case a change does not meet the criteria, bamboo will
give a negative vote in the review system and point to the according
Following the coding guidelines not necessarily means more work for
Core contributors: The automatic CGL check performed by bamboo can
be easily replayed locally: If the test setup votes negative on a
Core patch in the review system due to CGL violations, the patch
can be easily fixed locally by calling
and pushed another time. For details on Core contributions, have a look at the
TYPO3 Contribution Guide.
Setup IDE / Editor¶
You are strongly advised to set up your editor / IDE properly so that the standards get checked and enforced automatically!
One method to set up your IDE / editor to adhere to specific Coding Guidelines, is to use an .editorconfig file. Read EditorConfig.org to find out more about it. Various IDEs or Editors support editorconfig by default or with an additional plugin.
For example, for PhpStorm there is an EditorConfig plugin.
An .editorconfig file is included in the TYPO3 source code.