[sonar-dev] AW:Re: [sonar-dev] [VOTE] Release Sonar Python Plugin 1.0

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[sonar-dev] AW:Re: [sonar-dev] [VOTE] Release Sonar Python Plugin 1.0

Waleri Enns
D'accord in all points. Have fun with the vote, thanks,

Von Samsung Mobile gesendet

Evgeny Mandrikov hat geschrieben:

Waleri, according to your examples :
Feel free to create ticket about complexity.
About lines of code: This is definitely relates to another subject - docstring (PEP 257). Indeed - docstring should not be counted as a line of code in general (feel free to create ticket). But if multiline string is a part of expression (i.e. variable = """value"""), then IMO absolutely clear that all lines included into this string should be counted as lines of code. So since we don't have notion of docstring, current behaviour is correct.

On Thu, Jul 12, 2012 at 12:57 PM, Waleri Enns <[hidden email]> wrote:
On 07/12/2012 07:10 AM, Evgeny Mandrikov wrote:
Hi Waleri,

See my comments below :

On Thu, Jul 12, 2012 at 4:54 AM, Waleri Enns <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Evgeny,

    I just spent some time testing the new version, see my findings below.

    * The following syntaxes arent supported by the new parser:
       [x for x in 1, 1]
       (x for x in 1, 1)

       If you wonder what the hell comes after 'in': its a tuple ;)

I'll take a look on this, but in any case this should come to the next
Of course.

    * The doc-strings count as code, currently. Would be better if we could
    count them as comments. Thats not thats simple, though: the
    long-string-syntax is also valid code (i.e.: str = """lala""").
    Note: that's not a regression as the 0.1-version had the same problem.

 From a syntaxis point of view there is only one type of comments -
http://docs.python.org/reference/lexical_analysis.html#comments ;)
But indeed - in next version we should take in account PEP 257 -

    Furthermore, I compared the values of the metrics for the new and
    the old versions for the codebases of Mercurial and Trac, just to
    make sure there are no regressions. Results:

    - The 'lines of code' metric has a bigger diff.

I'm not surprised about diff. I inclined to say that new version should
be more accurate.

    One of the factors is that the new implementation counts the empty
    lines within the doc-strings also as code, while the old one doesnt.
    I woulnt count that as a regression as actually neither behavior is
    optimal (see above).

This is surprising and I can't believe in this - could you provide small
example to demonstrate this?

    But thats probably not all, there should be other reasons. Should be
    investigated further, I guess.

    - The 'comments' metric is also quite different. The old version didnt
    differentiate between blank and not black comments so I would expect
    "comments_old == comments_new + comments_black_new"
    Its not the case though. Didnt investigate further where the diff
    comes from.

    - Complexity: bigger diff, also. One of the reasons is that the new
    implementation doesnt consider the code in modules' namespace. And I
    have the feeling it gets confused in presence of nested functions.

Once again - I believe that any incorrect behaviour should be
demonstrated on a small example.

To be clear: I too tend to think that the new implementation is more accurate, at least in the case of lines of code and comments. The above are just observations and feedback, not regressions. See attached files for examples which show potential minor issues, which (of course!) arent blocking this version.

    - Duplications: in case of Trac, there is actually a small
    regression as the new version finds one less duplicated blocks and
    the not found one seems to be a valid clone.

Detection of duplications isn't precise in general (as a
subject). Difference can be explained by the fact that we completely
replaced lexer and I trust to the new one more than previous, because
precisely know that there was incorrect handling of some tokens in
previous. On other side - I'll take a look on what wasn't found in Trac

    So there's nothing dramatic.

    On the other side, its gotten very fast (it you dont switch on pylint ;)
    more complete and provides a good starting point for further
    development. Great work, thanks!




    On 07/10/2012 03:52 PM, Evgeny Mandrikov wrote:

        Hi all,

        I'd like to release Sonar Python Plugin version 1.0.

        This plugin enables analysis of Python projects into Sonar.

        This version introduces implementation of own Python parser for
        computation of metrics, adds new metrics, new rules, fixes some
        bugs and
        provides default SQALE model.
        Should be noted that current version of parser might be incomplete,
        however it was successfully tested on projects Django, Buildbot,
        Tornado, GNU Mailman, pylint.

        *26 issues have been solved*


        *There are still a couple of issues left*
        http://jira.codehaus.org/__browse/SONARPLUGINS/component/__15262* <http://jira.codehaus.org/browse/SONARPLUGINS/component/15262*>

        *Snapshot version*



        *Vote** open to everybody for 72 hours.*
        [ ] +1
        [ ] +0
        [ ] -1

        *Release early, release often!*


        Best regards,
        Evgeny Mandrikov aka Godin <http://godin.net.ru>


    To unsubscribe from this list, please visit:



Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>

To unsubscribe from this list, please visit:


Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>