Closed (fixed)
Project:
Scheduler
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
11 Apr 2017 at 08:02 UTC
Updated:
4 Mar 2019 at 10:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jonathan1055 commentedThe output from
phpcs --standard=DrupalPracticeon the current codebase is:and here is the summary
95 files checked with 25 warnings spread across seven files. However the 5 warnings in three .info.yml files
All dependencies must be prefixed with the project name, for example "drupal:"cannot be fixed. This is a known problem with the codestyle checking.Hence the best we can currently aim for is to fix the other 20 message. The four files in question have @TODO comments at the places where fixes are required.
Comment #3
morsokWell actually yes it's fixable ! For exemple in scheduler_rules-integration.info.yml, the dependencies should list as scheduler:scheduler and rules:rules
It is so to prevent namespace collisions.
https://www.drupal.org/docs/8/creating-custom-modules/let-drupal-8-know-...
Comment #4
jonathan1055 commentedThanks morsok for the tip, that's really helpful. Yes you are right, those three files can be cleaned. I cannot recall where I was reading about the dependency message not being fixable. Maybe it was an old issue and the test for namespace addition has been improved since.
Anyway, it is good that we can clean up the messages. Patch for three .info.yml files attached, just to check the testing on d.o. works the same as on my local machine before I commit the change.
Comment #6
jonathan1055 commentedHere are the current remaining codestyle warnings:
Patch fixes dependency injection in AdminForm and CronForm
Comment #9
mgiffordThanks for working towards this! Always helps in the long run.
Comment #10
idebr commentedThe patch in #6 is no longer relevant. However, some remaining coding standard issues can be found in the daily test results:
The status at 25 May 2018: https://www.drupal.org/node/3292/qa
Comment #11
jonathan1055 commentedHi idebr,
Thanks for your comment, and your interest in coding standards and best practice.
Do you mean it no longer applies? That is because it has already been committed, see #7 and #8
The warnings you list are actually the ones I showed in the summary in #6
The four "variable is undefined" messages is actually a false alert. The variables are defined using the list() function, but the code style checker is not programmed to recognise this, so thinks they are undefined. I have already raised #2876245: Incorrect "variable is undefined" when using array destructuring, for example list( ) syntax with no response yet.
Jonathan
Comment #12
idebr commented#11 Yes, I meant the patch is no longer relevant since it has already been committed. The workflow in this issue is somewhat different than the typical workflow in Drupal core, where a patch file fixes the issue completely and the issue is then marked as 'Fixed' when it is committed.
To fix the remaining failures, I have updated the LightweightCronController and SchedulerManager to follow the Drupal coding standards. Since the SchedulerRulesEventsTest generates false positives, I have added
@codingStandardsIgnoreStartand@codingStandardsIgnoreEndto bypass this validation.Comment #13
jonathan1055 commentedYou have done a great deal of work here, thank you very much.
The test result does not show any style or practice messages, so it looks like you have corrected them all in these changes. However, I thought we were getting "N more than branch" or "N fewer than branch" notices. and it would have been good to get "22 fewer" or at least something to prove that the codebase is clean.
It will take me a while to review the changes, before committing, but thanks again for your work on this. Much appreciated.
Jonathan
Comment #14
thallesLooks Good!
Comment #15
keeneganLooks good to me too.
Even if this doesn't appear in the phpcs, there is still unused use statements in some files, so maybe we should fix this aswell ?
Comment #16
jonathan1055 commentedThanks Kng. Did you have an automatic way to detect these unrequired use statements? I am sure I have seen something like that before, but cannot recall where it was. If you can give a screen shot, please share.
Comment #17
keeneganI use phpstorm, in the menu "Code / Inspect code" and it gives you a bunch of informations about your folder (code smells, erros, unused statements or variables, etc..)
Comment #18
idebr commentedThere are a few minor code style issues that are not picked up by phpcs:
\Drupal\scheduler\Form\SchedulerCronFormreferences@var Drupal\scheduler\SchedulerManagerwithout a\prefix, so PHPStorm cannot find the reference.\Drupal\scheduler\Form\SchedulerCronForm::__constructis missing a call toparent::__construct().When these issues are fixed, this issue should be ready to be committed.
Comment #19
bzhazreal commentedFix two last errors.
Comment #20
jonathan1055 commentedThanks idebr for your helpful reviews, much appreciated. Also thanks Kng and bzhazreal for your patches.
This issue has had quite a bit of scope-creep, and the patch in #19 alters 10 files. Whilst all of these changes are good, and won't be ignored, it is only actually 4 files that need to be changed to remove the phpcs best practice warnings. I think it would be better to do the minimum number of changes in the first place, so that we know exactly what has been done for this issue. Then we can do further tidy-up, either here or on #3033108: Miscellaneous changes before Scheduler 8.x-1.1 but I would like to keep the commits separate.
Here's a patch with just the minimum four files fixed.
Comment #22
idebr commentedAlright, let's consider this fixed then.
Comment #23
jonathan1055 commented@idebr, @Kng, @thalles - I would value your opinions on the extra changes that I did not commit above - please see the follow-up issue #3033783: Remove unused statements, use EntityTypeManager, fix annotations and other tidy-up
Thanks all for helping to clean-up the Scheduler codebase. It is great not to have any PHPCS warnings. We still have work to do as tests are failing on Travis due to deprecation warnings not being suppressed like they are on d.o. but those are for separate issues. For now lets be pleased that PHPCS gives a clean slate.