Your Moodle version

General plugins (Local): Code-checker

local_codechecker
Maintained by Tim at Lone Pine Koala Sanctuary Tim Hunt, One poor developer... Eloy Lafuente (stronk7)
A tool for developers that helps them follow Moodle's coding style.
14k
230
7
Moodle 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9

The code checker tool is based on the Zend PHP CodeSniffer library. It implements a set of 'sniffs' that check for many parts of the Moodle coding style. They also present a nice web interface for viewing the results.

Contributors

Tim at Lone Pine Koala Sanctuary
Tim Hunt (Lead maintainer)
One poor developer...
Eloy Lafuente (stronk7)
Please login to view contributors details and/or to contact them

Comments RSS

Show comments
  • Picture of Marina Glancy
    Wed, Jul 10, 2013, 10:36 AM
    upon MDLSITE-2339 I changed the description to include words "code checker" smile
  • David
    Wed, Jul 9, 2014, 6:49 AM
    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?
  • One poor developer...
    Wed, Jul 9, 2014, 5:01 PM
    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!
  • Gareth J Barnard
    Fri, Jul 18, 2014, 1:25 AM
    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
  • Picture of Florian Fa
    Thu, Oct 16, 2014, 7:55 PM
    "More documentation..." under Useful Links gives a 404.
  • Picture of Carlos Chiarella
    Wed, Jun 17, 2015, 5:00 AM
    When I ran code checker against my plugin, I am getting this error: The use of function print_r() is forbidden
    Why is that? I have look at some Moodle core code and it is using this function. What function should we use instead?
  • Tim at Lone Pine Koala Sanctuary
    Wed, Jun 17, 2015, 5:50 AM
    Well, it is just a warning.

    However, print_r is generally only used in debug code. And debug code should generally be removed before everything is finished. That is why the warning exists.
  • Picture of Carlos Chiarella
    Wed, Jun 17, 2015, 5:59 AM
    Ok thanks Tim. I will remove the use of print_r in my plugin.
  • Picture of Urs Hunkler
    Thu, Jul 30, 2015, 3:19 AM
    When I check Moodle 2.9 core code with the code checker I very often get a lot of errors. I notice many whitespace errors, »Inline comments must end in full-stops, exclamation marks, or question marks« errors and »Member variable "unique_end_html_token" must not contain underscores.« errors.

    Does the code checker need an updated to follow the actual Moodle coding style or is Moodle core code not validated against the Moodle coding style?

    I would like to be able to reliable use the code checker to validate coding style. The code checker is a great tool, especially when it is integrated into the IDE and errors/warnings are shown while working on the code. But when it throws may errors for core code it becomes confusing and irritating.

    Any idea how the issue can be solved?

    An example:

    lib/outputrenderers.php - 209 error(s) and 239 warning(s)
    Total: 209 error(s) and 239 warning(s)
    lib/outputrenderers.php

    #183: ········//·Remove·_renderable·suffixes
    Inline comments must end in full-stops, exclamation marks, or question marks
    #311: ········//·Remove·_renderable·suffixes
    Inline comments must end in full-stops, exclamation marks, or question marks
    #335: ········//·pass·to·core·renderer·if·method·not·found·here
    Inline comments must start with a capital letter, digit or 3-dots sequence
    Inline comments must end in full-stops, exclamation marks, or question marks
    #393: ····protected·$unique_end_html_token;
    a
    #398: ····protected·$unique_performance_info_token;
    Member variable "unique_performance_info_token" must not contain underscores.
    #403: ····protected·$unique_main_content_token;
    Member variable "unique_main_content_token" must not contain underscores.
    #437: ············//·legacy·xhtml·1.0
    Inline comments must start with a capital letter, digit or 3-dots sequence
    Inline comments must end in full-stops, exclamation marks, or question marks
    #439: ············return·('html·PUBLIC·"-//W3C//DTD·XHTML·1.0·Strict//EN"·"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">'·.·"\n");
    Line exceeds 132 characters; contains 140 characters
    #479: ········//·This·is·only·set·by·the·{@link·redirect()}·method
    Inline comments must end in full-stops, exclamation marks, or question marks
    #483: ········//·already·meta·refreshing
    Inline comments must end in full-stops, exclamation marks, or question marks
    #484: ········if·($this->metarefreshtag==''·&&·$this->page->periodicrefreshdelay!==null)·{
    Expected 1 space before "=="; 0 found
    Expected 1 space after "=="; 0 found
    Expected 1 space before "!=="; 0 found
    Expected 1 space after "!=="; 0 found
    #485: ············$output·.=·'page->periodicrefreshdelay.';url='.$this->page->url->out().'"·/>';
    Line exceeds 132 characters; contains 135 characters
  • Tim at Lone Pine Koala Sanctuary
    Mon, Aug 3, 2015, 7:50 PM
    A lot of old code does not match all of the coding style. That is sad, but not easy to fix (fixing it all would create a lot of noise in git).

    The policy is that you should fix probles on the lines you need to change, then ignore the rest. When you submit a patch to Moodle core, it just checks the problems on the lines in the patch. E.g. https://tracker.moodle.org/browse/MDL-27177?focusedCommentId=364873&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-364873
  • Picture of Urs Hunkler
    Tue, Aug 4, 2015, 7:54 PM
    Thank you for your answer Tim. So the code-checker conforms to the actual Moodle coding style and I can rely on it's output.

    Many errors are comment errors like »Inline comments must end in full-stops, exclamation marks, or question marks«. Is it really important for a good coding style that inline comments must end in a predefined way? Many of these coding errors or warnings could be avoided when this rule may be removed. Especially because I would never add any mark after a short comment and find it strange to be forced to do so to avoid the coding errors. And looking at Moodle core code it's not only me.

    What do you think?
  • Picture of Urs Hunkler
    Tue, Aug 4, 2015, 7:58 PM
    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?
  • Tim at Lone Pine Koala Sanctuary
    Tue, Aug 4, 2015, 9:14 PM
    $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.
  • Picture of Urs Hunkler
    Tue, Aug 4, 2015, 10:40 PM
    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.
  • Picture of Urs Hunkler
    Tue, Aug 4, 2015, 10:50 PM
    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.
1 2
Please login to post comments