Code Quality Tools

[lonnieezell]

I've been thinking about this for a while now. While this project was started with the intent of being a new forum system that we can for CodeIgniter, it has never been a CI team project, but a personal project of mine, that a couple team members have made valuable contributions to.

One thing that has bugged me is the tools we use for the main CodeIgniter repo. While I can see their value, and I think they are likely even more important on a framework than a single app, I have problems with them. The largest one is that they suck the fun out of programming. For this project I want to try to optimize the experience for developer happiness. Meaning, I don't want to constantly fight tools in places where I find the ROI to not be worth it.

For the last couple of years, I've let the CI core team do what they felt best for quality tools, even when the results weren't to my preference. We've had a couple of very passionate contributors who have a love for the tooling, and that's awesome. But that's not me. I've fallen behind on what the benefits of all the tools we use are and how they complement each other and our workflow.

So I'm going to make some big changes to the code quality tools we use on this repo. The first step is to rip them all out. We won't use the CI team's quality repo/toolset anymore. Instead, I'm going to start exploring the tools one-by-one to see what I personally find value in and attempt to find a balance where the quality of the code is still looked after, but the tools used will be setup in a way to complement the developer and not be so strict as to form a constant tug-of-war between developer and tools.

Expect this sooner rather than later.

[datamweb]

The fact is, when I took a close look at the team's performance, I had never used or even been familiar with any of these tools(CQ).
This tools, as you mentioned, turned me off at first. But the passage of time and a little research about the reason for using them surprised me.

I understand your concern about this because I was in a situation where I was removed from participation, but we have to say that these tools are extremely helpful for code maintenance and development and are worth these conflicts.

I believe that people who participate here or who are learning in complete silence should be able to get familiar with this tool and gain relative mastery. This has a positive impact on creating a dynamic community for Codeigniter and encouraging contributors to other repositories.

I want to try to optimize the experience for developer happiness

If you want to make developers feel good, train them. If you don't have the time, put them on the learning path. If a developer is determined enough to contribute, he will definitely try to learn.

Do not forget that it is not clear who will be the maintainer of this project in the future, but using this tool will be extremely helpful for anyone in the maintenance and development of the code. I don't have much experience in software maintenance, but my personal experience in Shield says that this tools helps maintain code a lot.

Conclusion, here it seems that I have a strong disagreement with you. Because I believe this repo should use exactly the same CI4 uses of this tools.

In any case, I hope that your experience will make the best possible conditions for this repo.

[lonnieezell]

If you want to make developers feel good, train them.

If this was more than just a personal project, or it was part of a company, I would agree. To some extent. Just because I know how tools work, doesn't mean they don't make life miserable. Training won't always help. Clearly I've been listening to too much of David Hanemeir Hanssen lately lol.

When the tools you use are setup in a way that all they do is bring constant frustration, it makes it hard to want to work on the project. And no one's getting paid for this so why subject ourselves to this. While I've never crunched the numbers watching the PRs that go through the CI repo I get the feeling that easily 1/3 of them are based on our tools, changing rules, correcting things we caused when we went strict everywhere, etc. And, while I agree that's good for the codebase, a part of me wonders if it's actually efficient. I wonder if the bugs that our tools are helping us catch are costing a lot more time spent then we would have spent just fixing the bugs that crop up. Obviously, I have no way of knowing that answer, and it is possible my feeling of the percent of time spent on it could be way off, but that's part of where I'm starting from.

Do not forget that it is not clear who will be the maintainer of this project in the future

Actually, it's quite clear. As stated, this was started as a personal project. I don't intend to hand complete reins over to the CI team. I have a personal project I've wanted to do for a long time that is based on the very same ideas that are getting put into this software, though they'll have many other layers on top of them. So, for the time being, there's no need to worry about that aspect. If, at some point the CI team wants to fork it or I do transfer it to them, they can take the time to massage the code into the state they want at that point.

Another reason I'm doing this is because I want to really get into the guts of where our tools overlap and what we can do, if anything, in the main repo to simplify things, and not just make things more complex to work with. There might not be any changes we can make, but I'll never know that until I do a deep dive into the settings of each tool and find what I believe is a good balance. Only then can I bring up any suggestions with the team. Otherwise, it's just me getting frustrated at the hoops we have to jump through and not being able to bring an informed argument about why we might want to change. If there's any change to be made, of course.

To be clear - while I'll start by ripping them out, some of them will make their way back in, and the settings and exact tools may change over time as I learn them better. So, I'm not scrapping the idea of tools, just trying to find a healthy balance between the tools and a developer's frustration levels.

[kenjis]

It's certainly true that coding styles often change with recent updates of php-cs-fixer.
These are annoying to me as well.

But to say that 1/3 of them are about tools is not really true.
See https://github.com/codeigniter4/CodeIgniter4/pulls?page=1&q=is%3Apr+is%3Amerged+sort%3Aupdated-desc

[lonnieezell]

I realize 30% was probably an exaggeration, but we also know that almost every PR is impacted by the tooling, so the "cost" is higher than it initially looks. I know I've had a couple of smaller PRs that took just as much time -- or more -- making the tooling happy than the actual development. And that's not 100% bad, either. Just not enjoyable.

[kenjis]

For example, there are 875 PHPStan (ignored) errors in CI4 4.5 branch. And if we set the level to max, the error will be 3086.
The larger the code base, the harder it is to introduce tools, and to raise the level of the tool.
So I think it is better to introduce tools at a higher level from the beginning.

Also, any code that does not pass the checks of these tools is more or less incomprehensible or difficult to understand to me.
For example, I don't know how to fix these undefined property errors: #260 (comment)
You said they are simple, but I don't know why you use undefined properties, and I don't know their types.
So to fix them, I need probably one day or at least a half of a day. So I stopped fixing them.

When it comes to static analysis like PHPStan, maybe we have different coding habits.
Static analysis tools check for type consistency. So what we need to do is specify the correct types in the code and/or doc comments.
The person who wrote the code has the most correct understanding of the type of the value.
So I think it makes sense to specify the correct types from the beginning.
Code that lacks type information is unfinished code.
If the correct types were specified to all values, any bugs due to type inconsistencies would be reported by PHPStan.
However, there are still many PHP programmers who do not have this practice of specifying types.

I understand that this explanation will not make you happy with your coding.
However, if the checks are weakened, the quality of the code will decrease. At the very least, the quality of the code will never increase.

But I also think healthy balance also makes sense because neither the tools nor we are perfect.