1. Use static analysis tools to measure quality
We use static analysis to measure code without running it. We actually use these tools to evaluate code, read files, measure the elements of what it's written on. Using these tools can help us gain a complete hierarchical understanding of the code base, even as the code base becomes larger and more complex.
Static analysis tools are a key component in the project process, but they only truly show value if they are used regularly and every commit is performed in an ideal manner. These tools cover all aspects of code, from counting classes and counting lines, to identifying where similar code snippets prompt the use of copy and paste. Then we'll look at how static analysis tools can help us with two particularly critical issues in code quality: coding standards and documentation.
1.phploc
phploc: https://github.com/sebastianbergmann/phploc
PHP Lines of Code (phploc) may not be a very interesting static analysis tool, but it does give us some interesting information, especially over time when we run it repeatedly. phploc provides information about the project topology and size.
For example, to test a standard WordPress version, we only need to use the following command:
$ phploc wordpress
2. phpcpd
phpcpd: https://github.com/sebastianbergmann/phpcpd
PHP Copy Paster (phpcpd) appears to be a tool that looks for similar patterns in code, we use it in order to identify where code has been copied or pasted in a code base. This is a very useful tool during the regular build process, but getting the correct numbers from the output can vary from project to project.
Similarly, if we are testing WordPress, we can use the following command:
$ phpcpd wordpress
3.phpmd
phpmd: http://phpmd.org/
The PHP Project Message Detector (phpmd) is a tool that attempts to quantify what development veterans call "code smells." It uses a range of indicators to look for project elements that appear to be out of balance. The tool generates a lot of output, most of which is good advice, here is a command that asks phpmd to check for naming confusion in WordPress:
$ phpmd wordpress/ text naming
2. Coding Standards
Coding standards is a topic that has caused heated debate among many development teams. Since indentation and the use of spaces do not affect the running of the code, why do we create formatting rules and strictly adhere to them? In fact, when we are accustomed to a coding style and the code is arranged in the way we expect, it becomes easier to read. However, in the actual development process, it is easy to forget the rules, so you need to check all codes in the tool area.
1. Use PHP code detector to check coding standards
PHP code detector: http://pear.php.net/package/PHP_CodeSniffer
First, you need to install this tool on your server. Whether it's on a development machine or a development server, it all depends on the resources you have available.
After installation, you can test the code using the following command:
phpcs --standard=PEAR robot.php
2. Check for violations of coding standards
PHP Code Explorer has several very important report styles that allow you to look at the "highlights" of the code base you are using. We output these to the screen in the same way as detailed reports, but they can also be generated in other formats. .
To generate a summary report, just do this:
phpcs --standard=PEAR --report=summary *
3. View PHP code detector standards
There are several coding standards that PHP Code Detector runs by default, you can generate or set any of your own standards. To see what standards are available, you can run phpcs with the -i switch.
$ phpcs -i
3. Documentation and code
Convert comments into documents using phpDocumentor.
phpDocumentor: http://www.phpdoc.org/
For example:
phpdoc -t docs -o HTML:Smarty:PHP -d .
4. Source code management
Commonly used source code management tools:
Subversion: http://subversion.apache.org/
Git: http://git-scm.com/
5. Automatic deployment
Phing: http://www.phing.info/
Phing is a project build system based on Apache ANT. Phing uses XML-based configuration, which is saved by default in a file called build.xml.
We give this project a command and define a series of tasks belonging to this project. We can also specify which tasks are run by default, all of which can be configured through Phing.