Code-checker

Gents,
Using 2.3.1 - San Fermín release! and getting errors for legitimate code in a js file:
value·=·value·<<·2;
Expected 1 space after "<"; 0 found
Expected 1 space before "<"; 0 found
.....
value·|=·toggleflag;
Expected 1 space after "|"; 0 found
Expected 1 space before "="; 0 found
.....
value·&=·~toggleflag;
Expected 1 space after "&" operator; 0 found
Expected 1 space before "="; 0 found
Cheers,
Gareth

Hi David,
I suppose that, at fist shoot, the approach would be to exclude any jQuery js by default. Later, once we have the proper tools defined jslint/jhlint/js coding style... it shouldn't be complex to create a codechecker sniff wrapping whatever we want to test.
But, as said, surely the 1st step is to exclude JS stuff, to avoid informing about something that is, right now, undecided.
It would be great if you could create an issue in the tracker (related to this component) defining current behavior, with some real example, and also which are your expectations/desired result.
Thanks!

with more and more jquery based scripts (yay!) I noticed that the codechecker marks minified jQuery plugins always a faulty, are there any plans to include compatibility with jQuery javascript style?

upon MDLSITE-2339 I changed the description to include words "code checker"

Oleg:
1) yup, looks like commented code mix. More context lines would help to confirm it.
2) yup, any method only having a call to its parent is useless. Just allow inheritance to work, constructors included.
3) yup, curly brace is expected.
4) no, don't blame me. Blame code style guidelines, I'm not the inventor, just the implementor (in fact I think it was Tim the inventor). Easy to replace with: The "What is" hint... anyway. Have been attempts to open the hand a bit with this, but all them have been rejected.
Ciao

The indent problem seems to be getting confused by some commented out code, but you should not leave commented out code around. (It should be saved in git history.
If a PHP class does not have a constructor at all, then the parent constructor is automatically used, so that warning is correct
The foreach does not have a { after the ). It is nothing to do with the &.
Comment starting with uppercase is just a pain. Blame Eloy

When using local_codechecker on our files I found some strange messages from it: some are just overlooked, other may be bugs.
error
························'backtracking_matcher'·=>·'backtracking_matcher'*/
46: Line indented incorrectly; expected at least 8 spaces, found 0
It's quite obvious, that there is more than 0 spaces on that line. There is some problem in spaces counting in lines with multiline comments.
warning
····public·function·__construct()·{
81: Useless method overriding detected
AFAIK PHP don't call parent constructor automatically, so overriding __construct() just to call parent ones isn't useless at all. This warning may mislead someone.
error
····················foreach·($ranges·as·&$tmp)
440: Inline control structures are not allowed
That's totally strange. & in foreach is a common method to change elements of array inside foreach loop. What's wrong with it and what "inline control structures" have to do with such code?
warning
····//·"What·is"·hint·is·obviously·response·based,·since·it·used·to·better·understand·mistake·message.
68: Inline comments must start with a capital letter, digit or 3-dots sequence
I suggest adding some punctuation marks, from which a sentence could start: double and single quotes, $ in case comment start from variable names.
I have also some problematic strings, when comment starts from function or class name, which should be lowercase.

Seems it was already fixed but the new release, planned for the end of April was never rolled. Doing...

haha, funny! thanks for the report, I'll roll a new minor version soon.

Just downloaded and installed codechecker.
It's ironical that the codechecker should throw an error re its own code:
Did you remember to call setType() for 'exclude'? Defaulting to PARAM_RAW cleaning.
line 1303 of \lib\formslib.php: call to debugging()
line 281 of \lib\formslib.php: call to moodleform->detectMissingSetType()
line 202 of \lib\formslib.php: call to moodleform->_process_submission()
line 46 of \local\codechecker\index.php: call to moodleform->moodleform()

It could. It is more likely to happen if:
1. You file a but in the tracker: CONTRIB / local_codechecker component exists.
2. You code the change yourself, and submit it as a pull request through github.

Hi Eloy and Tim,
Please can 'Inline comments must end in full-stops, exclamation marks, or question marks' be changed to include colons? As it is possible to write '// The following code does something awesome:'
Cheers,
Gareth

Yeah, surely all the "errors" are upper / lower case one in the moodle/Sniffs dir. We use codechecker style rules there.
About the warning... I bet we still have a bunch of them... not fulfilling the "Inline comments must start with upper and end with dot". Next release will fix them (though they are not critical at all).
Thanks for code-checking the code-checker, btw!

Well, I am not sure about normal, but it is unavoidable, because the codechecker plugin contains the third-party codesniffer library which comes from PEAR, and so does not follow the Moodle coding rules.

Hi,
Is it normal to have 92 errors and 23 warnings in the local/codechecker folder?
It seems odd to me (a non-programmer).
Thanks in advance,
German Valero