|
|
D'accord in all points. Have fun with the vote, thanks, Waleri
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
version.
Of course.
Yep.
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
that
"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
project.
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!
+1.
Thanks.
--
Waleri
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*
http://jira.codehaus.org/__browse/SONARPLUGINS/__fixforversion/18636
http://jira.codehaus.org/__browse/SONARPLUGINS/component/__15262* <http://jira.codehaus.org/browse/SONARPLUGINS/component/15262*>
*
*
*
*Snapshot version*
sonar-python-plugin-1.0-__SNAPSHOT.jar
<http://repository-__sonarplugins.forge.cloudbees.__com/snapshot/org/codehaus/__sonar-plugins/python/sonar-__python-plugin/1.0-SNAPSHOT/__sonar-python-plugin-1.0-__SNAPSHOT.jar
<http://repository-sonarplugins.forge.cloudbees.com/snapshot/org/codehaus/sonar-plugins/python/sonar-python-plugin/1.0-SNAPSHOT/sonar-python-plugin-1.0-SNAPSHOT.jar>>
*Documentation*
http://docs.codehaus.org/__display/SONAR/Python+Plugin
------------------------------__------------------------------__---------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/__manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-- Best regards, Evgeny Mandrikov aka Godin < http://godin.net.ru> http://twitter.com/_godin_
|