search

opencaching / opencaching-pl

The source code of Opencaching.PL (and some other domains)
https://opencaching.pl/
GNU General Public License v3.0
22 stars 33 forks source link

Next part of changes necessary for reactivation rules notice #2297

Closed kojoty closed 2 years ago

rapotek commented 2 years ago

It looks like it is not only reactivation rules but a few more things too (cleaning/moving files). However, why don't you try to be compliant with php-cs rules in new or modern-style files (like config ones)? I do not mean the old ones which should be refactored anyway.

kojoty commented 2 years ago

It looks like it is not only reactivation rules but a few more things too (cleaning/moving files). However, why don't you try to be compliant with php-cs rules in new or modern-style files (like config ones)? I do not mean the old ones which should be refactored anyway.

HI Raptek,

The answer is simple: I need to install php-cs-fixer or another tool to check it locally before commit. For now I don't have such solution in my IDE and I often made small sins against code style but I trust your forgiveness :)

I promise to improve someday

jrmajor commented 2 years ago

@kojoty @rapotek First of all, sorry for not taking enough care of it. I hoped to be able to devote more time to this project. I will reconfigure PHP-CS-Fixer it so that it checks only the content of src/, because it doesn't work very well for fixing non-monolithic PHP code. There probably won't be so many changes there, so we will be able to just fix all violations and get a fresh start.

rapotek commented 2 years ago

HI Raptek,

The answer is simple: I need to install php-cs-fixer or another tool to check it locally before commit. For now I don't have such solution in my IDE and I often made small sins against code style but I trust your forgiveness :)

I promise to improve someday

I do not have php-cs-fixer integrated in my IDE, too (well, in fact I tried to integrate, but I don't like the result). I just run php-cs-fixer from command line on single files, when needed. I just hoped to gradually reduce amount of style-related errors without generating new ones if possible. Maybe what @jrmajor suggests, to take care for src/ only for now is a good start.