Code Analyzer v1.0.5

Release Notes

  • Fixed private functions iterator bug
  • Added support for namespaces that come with Elgg 1.10.0
  • Improved test coverage and fixed minor issues
  • Dropped PHP 5.2 support.
  • Thanks! Using this a lot

  • testing this here. i am seeing this line many times at the top of the analysis results:

    
    Warning:  Unexpected character in input:  '' (ASCII=1) state=0 in /mypath/mod/code_review/classes/PhpFileParser.php on line 42
  • also, the file titles in the outputs contain a spurious slash:

    In file: /mypath//pages/settings/tools.php
  • do you know why i am seeing so many of these types of lines in the output here?

    Function call: elgg_view_entity_list (use of function marked private is unsafe)
    
  • I could suppress those character warnings, but that's something I have little control to overcome in smarter way, It's originating from one of analyzed PHP files.

    As for elgg_view_entity_list, it's not part of public api and it's use is discouraged. It can be removed or changes at any point from the core so you should not rely on it in your code.

  • i'm not sure what you mean by 'not part of the public api'. that function is within views.php in core elgg 1.8, so why is a separation being made between functions in a way that isn't marked in the code?

  • Yes there is distinction. Private functions are marked in the code with "@access private". See also http://learn.elgg.org/en/1.10/contribute/code.html#documentation

    We go through the deprecation process and support public api. Private functions may be removed on minor releases without any notice.

  • oh ok, i had no idea of that. so why would such a generic function be part of a core file if it could be removed at any moment?

  • It's just the matter of what we promise to support and what not. If you want to discuss this function case, please do so in separate thread so more people could talk about it. Generally public api part that's supposed to be used, is elgg_list_entities_from_*.

  • @Pawel great plugin!

    I´ve two questions:

    - When I specify a subdirectory to analyze (like /mod/files/), with some plugins this warning is shown:

    *** No files were processed! *** Analysis input parameters did not resolve to any files.
    

    Disabled plugins option is set to Yes, the directory contains files and webserver has write perms.

     

    - What this mean?: 

    Function call: (use of function marked private is unsafe)

    Why is unsafe?

    Thanks.

  • @Javier Did you mean to use /mod/file/ instead of /mod/files/ ?

    In the core there are two types of functions. The ones that are considered "public api" and are supported, follow normal deprecation policy and are meant to be backward compatible along all minor versions in semver meaning.

    The second kind of functions is marked as "@access private" and are meant for core internal use ONLY. We do not guarantee anything about them. They might be changed or removed between bugfix versions without any notice. For that reason using them in plugins is very risky and might cause plugin to break unexpectedly.

    Did you get the

    Function call: (use of function marked private is unsafe)

    without function name? I'd be very interested to get the file it failed to analyze.

     

  • @Pawel /mod/files was only an example, I´ve just try with

    mod/metatags/

    ...and this was the log:

    Subpath selected mod/metatags/
    Max version: 1.8
    Skipped inactive plugins: no
    Search for deprecated functions usage: yes
    Search for private functions usage: yes
    Attempt to fix problems: no
    Found 0 problems in 0 files
    Found 0 fixes in 0 files
    *** No files were processed! *** Analysis input parameters did not resolve to any files.
    
    
    Time taken: 5.3726s

    About

    Function call: (use of function marked private is unsafe)

    Sorry, I omited the function but it was there ;)

  • *** No files were processed! ***

    This might be a misleading error message. I got the same "error" when testing a few plugin directories, too. My guess is that the error shows up when there are no deprecated and no private function usages found. I made a test by adding a deprecated function on purpose and then this usage was displayed and no error message instead.

  • @Pawel I think I´ve found an error, with the deprecated add_metastring function, plugin suggest:

        Line 902:	Function call: add_metastring (deprecated since 1.9) Use elgg_get_metastring_id()
    

    It not must be _elgg_add_metastring?

    Tested in Elgg 1.9

  • It looks ok. elgg_get_metastring_id will create metastring if not exists and return the id.

    Actually _elgg_add_metastring should be probaly marked explicitly as private api. It's also obsolete now in the core, so will be removing it soon I think.

     

    Edit:

    @iionly You're right, that's mistake on my end in the way I check amount of files processed. Will just need to dump number of files checked to have some feedback on iterator filtering.

  • Really nice plugin ! Please remark the below:

    By introducing elgg_get_version() as a function in 1.8 you're plugin is fooling other plugins to be on 1.9 or later.

    I use it for once in videos plugin to check if the system is on 1.9 or higher and Matt is doing that to in Solr.

    Could you rename that function maybe to elgg_get_version_for_code_analysis() or something similar ?
     

Paweł Sroka

Former Core Elgg team member, freelance developer.

Stats

  • Category: Tools
  • License: Expat (MIT) License
  • Updated: 2016-9-25
  • Downloads: 1774
  • Recommendations: 30

Other Projects

View Paweł Sroka's plugins