phpinspectionsea VS black

(I actually held the same opinion as you until recently: https://github.com/kalessil/phpinspectionsea/issues/1718 tl;dr the performance impact is negligible)

PHP Inspections is a static code analyzer and code review tool for PhpStorm IDE.

The PHP-EA Extended static analysis plugin for PHPStorm has a number of Performance rules which has some of the same items as this list, although they're not all in the performance category, the single quotes inspection is under code style.

PHP Inspections (EA Extended)[1] by Vladimir Reznichenko, a PHP language static analysis plugin for PHPStorm / JetBrains. I've coded in PHP for many years now, but there are many helpful reminders and checks that come standard with it. Some of the small performance quirks are game changers in long running processes, or intensive methods.

[1]: https://github.com/kalessil/phpinspectionsea

1. LICENSE: This file contains information about the rights and permissions granted to users regarding the use, modification, distribution, and sharing of the software. I already had an MIT License in my project. 2. pyproject.toml: It is a configuration file typically used for specifying build requirements and backend build systems for Python projects. I was already using this file for Black code formatter configuration. 3. README.md: Used as a documentation file for your project, typically includes project overview, installation instructions and optionally, contribution instructions. 4. example_package_YOUR_USERNAME_HERE: One big change I had to face was restructuring my project, essentially packaging all files in this directory. The name of this directory should be what you want to name your package and shoud not conflict with any of the existing packages. Of course, since its a Python Package, it needs to have an __init__.py. 5. tests/: This is where you put all your unit and integration tests, I think its optional as not all projects will have tests. The rest of the project remains as is.

using pylint and black ("the uncompromising code formatter")

It was with this test that I made that I was able to test my parse_md function, previously called check_md_and_write, and locate a bug that I uncovered a last week. I noticed this bug when I was using the linter, Ruff, and formatter, Black, I set up for my project. If you're interested in reading about the linter and formatter I chose and the setup process you can read last week's blog. Essentially the problem was that I could not parse any Markdown in my program. I wasn't sure what the problem was, but I think it had something to do with when I refactored my code and tried to clean things up. Luckily, I still has the branches where I worked on improved the function to parse markdown and the refactoring branch. To make note of it, I made an issue for myself and specified which branches to take a look at.

Whenever I start a new project I like to maintain quality standards and using automated quality tools makes it easy. Lets go ahead and install mypy for static type checking, black for formatting, and ruff for linting. Add these to the dev dependencies.

Black is a Python code formatter that automatically formats Python code to comply with its style guide called PEP 8. PEP 8 is the official style guide for Python code, and it provides recommendations on how to format code for better readability and consistency.

Uses a uniform line width of 100 for both black (my preferred auto-formatter) and flake8.

repos: - repo: https://github.com/psf/black rev: hooks: - id: black

In addition, you should use black or shed (uses black and other tools)

Btw there are tools to do this already but you should also read the reasoning here: https://github.com/psf/black/issues/134