Moodle plugins directory: Code-checker

And I wonder about the »#398: ····protected·$unique_performance_info_token;
Member variable "unique_performance_info_token" must not contain underscores.« error. I always thought compound variable names must be separated by underscores. How should that variable name be written conforming to the coding style?

$uniqueperformanceinfotoken - as it says on https://docs.moodle.org/dev/Coding_style#Variables

The comment style is really not important. I don't know why Eloy implemented it. (Eloy says he implemented it because I said he should, but I don't remember that.)

Anyway, the point of coding style is readability, so that when you are trying to understand some code, there are as few irrelevant distractions as possible.

Eloy, in the case you read the comments - please consider to remove the »Inline comments must end in full-stops, exclamation marks, or question marks« errors.

Yep, »the point of coding style is readability«. But I have difficulties to read $uniqueperformanceinfotoken - $unique_performance_info_token is much easier to read. But with the info from the coding style page you had linked to »keep them short as possible« the varianble may have been named something like $perfinfotoken.

I don't complain - it's just a complex field and I am just starting dig deeper into Moodle coding style.

Hi Urs,

sorry for the delay, I've been out last weeks and has been long to catch up with everything on return.

Mimicking (and joking) Tim: The comment style is really not important. I don't know why Tim proposed it. It was proposed, voted and agreed, so I don't think we are going to vote it again soon. I just implemented it.

In any case, it's only a warning. If anything you should be looking for errors only, warnings are recommendations, basically.

Ciao

Hi Gareth,

somehow I missed your comment above about some operators not being detected properly when looking for whitespace around them. I've create CONTRIB-5862 about that, for reference.

Ciao

Thanks for your feedback Eloy. You recommend to »ignore« warnings - I can turn off PHP Code Sniffer warnings in the IDE to avoid the not relevant PHP Code Sniffer feedback. Great and thanks.

LOL, Urs.

I don't recommend to ignore warnings. In fact, I do recommend to check both errors and warnings. More yet, I do check both always.

I only say that, while errors are clear violations, warnings can be understood as recommendations. If you decide to follow or ignore them it's up to you. Personally I follow them, it's not so hard, really. But your choice, anyway.

Ciao

I don't understand, used plugins like?

Gents,

Looking at the code I believe that this: https://github.com/moodlehq/moodle-local_codechecker/blob/master/moodle/tests/moodlestandard_test.php#L344 should be a failure of 'Expected 1 space before "="; 2 found' given: https://github.com/moodlehq/moodle-local_codechecker/blob/master/moodle/tests/fixtures/squiz_whitespace_operatorspacing.php#L18

Cheers,

Gareth

"More documentation" link above should probably point to https://docs.moodle.org/dev/CodeSniffer rather than style documentation. Not sure though.

Would it be possible to include the latest version of the PHPCompatibility sniff and also add in the ability to pass in versions, so the code can be tested against different versions?

Hi Derek, just for reference, there is https://tracker.moodle.org/browse/CONTRIB-5158 about that. It's old, but any movement towards that feature should happen there.

Hi Tim,
This doesn't check the column names in install.xml file. There is a coding standard for the column names as well. "Column names should be always lowercase, simple and short, following the same rules as for variable names. (https://docs.moodle.org/dev/Database)".

You should be using the XMLDB editor built in to Moodle, to edit your database definitions (Admin -> Development -> XMLDB editor). That checks the rules for you. I agree it would be nice to have the same checks in codechecker, but not essential.