Thread: [Codenarc-developer] A M.Sc. thesis on CodeNarc (in progress) - any suggestions?
Brought to you by:
chrismair
Menu
▾
▴
codenarc-developer
|
From: Artur G. <art...@gm...> - 2013-03-17 23:04:35
|
Hi Guys! As you might have seen, I've recently done two<https://github.com/CodeNarc/CodeNarc/pull/12> pull requests <https://github.com/CodeNarc/CodeNarc/pull/13> to CodeNarc, both containing a rule implementation. There are more to come, as I am doing a M.Sc. thesis on CodeNarc. In my thesis I'd like to focus on implementing some feature requests (mainly: new rules). Which feature requests I'll implement is not sealed yet (and probably won't be until I finish my thesis... :)), and I'd like to ask you for direction in this matter. Are there any feature requests that you would especially like implemented in the first place? What would the users benefit from the most? If time allows me (I'd like to defend the thesis in July; September is - I think - the last possible deadline...) I'll be more than happy to follow any of your advice. BTW: I've got some ideas for new features as well. Most of them are new rules and I'll probably add some feature requests for them soon. There is, however, one (bolder) proposal I'd like to discuss with you as soon as possible: gathering statistical information on CodeNarc's usage. I think it would be great to somehow measure how popular rules are, how often they get @SuppressWarnings, how often they are violated and how these numbers change over time. Also, how is CodeNarc run (ant task, Sonar analysis, IDE plugin, command line, etc...). Another idea is to gather some code snippets around violations and suppresions (by default off, if one agrees - by default obfuscated). I feel that all this information can be a great guide for CodeNarc maintainers (and analysing it for rules implemented by me would be a great addition to my thesis :)). I would be very happy to implement such a feature for CodeNarc, but - due to aforementioned time constraints - am hesitant to undertake the effort if I there is not hope that we'll gather some data that I could use in my thesis. Otherwise I'd like to focus on implementing new rules. Could you shed some light on how fast new versions of CodeNarc are adopted (and, therefore, how fast we can get any data at all)? I think, according to this SO thread<http://stackoverflow.com/questions/8874670/maven-detailed-download-statistics-for-artifacts-of-public-repositories-like>you should have such data available. Best regards, Artur Gajowy P.S. The seed of all this was planted by Hamlet D'Arcy during a hackergarten on the first edition of 33rd Degree <http://33degree.org>(Cracow, Poland, two years ago), where we drank beer and made an attempt to implement EqualsOverloadedRule. The commit is here<https://github.com/CodeNarc/CodeNarc/commit/3320a8>. Just thought you'd like to know :) |
|
From: Artur G. <art...@gm...> - 2013-03-18 20:59:00
|
Hamlet, I believe you wanted this on the mailing list as well :) On 18 March 2013 09:38, Hamlet D'Arcy <ham...@gm...> wrote: > One of the features of Groovy 2.0 is the static typing option. Supposedly, > the static types of variables, parameters, and fields are now somewhere in > the AST. I don't know for sure how reliable the data is, but my expectation > is that if we find a bug or missing type information that the Groovy team > would consider it a defect and fix the issue. So it is sort of a safe > feature to use. > > Someone correct me if I am wrong, but I believe that CodeNarc is not > currently using this data during analysis. I recommend working on using > this new type information to drive rules. Thanks for the idea! I guess, however, that this would demand migrating CodeNarc to groovy 2.0 or later? Will CodeNarc-dependent libs be ok with that? > You will have to look through other products' rulesets and just pick out > some rules that require advanced type information. For example, there might > be a rule named "don't do X on a File object". In the past we never knew if > a parameter or variable was really a File so we could not write the rule. > But with Groovy 2.0 we do know. A real example, is don't call > File.getText() within a loop because it would read the entire contents of a > file into a String on every iteration. Here are some rulesets from other > products: > > * http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html > * > http://www.klocwork.com/products/documentation/current/Java_checker_reference > * > https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java > * http://pmd.sourceforge.net/pmd-5.0.2/rules/index.html > * http://findbugs.sourceforge.net/bugDescriptions.html > > Good luck! > Thanks! What do you think about the stats collection idea? Do you have any info on adoption of new versions of CodeNarc? Best regards, Artur Gajowy |
|
From: Hamlet D. <ham...@ca...> - 2013-03-19 06:03:37
|
What statistic could we collect that would event ually lead us to make Codenarc a better product? -- Hamlet D'Arcy ham...@ca... ----- Original Message ----- > Hamlet, I believe you wanted this on the mailing list as well :) > On 18 March 2013 09:38, Hamlet D'Arcy < ham...@gm... > wrote: > > One of the features of Groovy 2.0 is the static typing option. > > Supposedly, the static types of variables, parameters, and fields > > are now somewhere in the AST. I don't know for sure how reliable > > the > > data is, but my expectation is that if we find a bug or missing > > type > > information that the Groovy team would consider it a defect and fix > > the issue. So it is sort of a safe feature to use. > > > Someone correct me if I am wrong, but I believe that CodeNarc is > > not > > currently using this data during analysis. I recommend working on > > using this new type information to drive rules. > > Thanks for the idea! I guess, however, that this would demand > migrating CodeNarc to groovy 2.0 or later? Will CodeNarc-dependent > libs be ok with that? > > You will have to look through other products' rulesets and just > > pick > > out some rules that require advanced type information. For example, > > there might be a rule named "don't do X on a File object". In the > > past we never knew if a parameter or variable was really a File so > > we could not write the rule. But with Groovy 2.0 we do know. A real > > example, is don't call File.getText() within a loop because it > > would > > read the entire contents of a file into a String on every > > iteration. > > Here are some rulesets from other products: > > > * http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html > > > * > > http://www.klocwork.com/products/documentation/current/Java_checker_reference > > > * > > https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java > > > * http://pmd.sourceforge.net/pmd-5.0.2/rules/index.html > > > * http://findbugs.sourceforge.net/bugDescriptions.html > > > Good luck! > > Thanks! > What do you think about the stats collection idea? Do you have any > info on adoption of new versions of CodeNarc? > Best regards, > Artur Gajowy > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Codenarc-developer mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codenarc-developer |
|
From: Chris M. <chr...@ea...> - 2013-03-19 01:54:32
|
Artur, Thanks for your contributions and interest and help. As Hamlet indicated, there are a bunch of existing feature requests for rules that are currently impossible or impractical given the limitations of the AST stage and contents, at least with Groovy 1.7. If Groovy 2.x does fill some of those gaps, that would certainly be one worthwhile thing to explore. I think upgrading the minimal requirement for CodeNarc to Groovy 2.x would be possible. I don't take that decision lightly, but CodeNarc is a tool rather than a framework, and there is no requirement that application code run at the same Groovy level that CodeNarc uses. The stats collection angle is intriguing. It would have to be non-intrusive and "opt-in", rather than on by default. It seems very ambitious, but if you have ideas on how to implement that, it does sound cool. I was not planning on putting out another release for at least a couple months, and probably more (busy on other projects), but that could be negotiable. We only moved to the Sonatype Maven repository with the 0.18 release back in November 2012, so we only have download stats since December 2012. And note that 0.18.1 came out in February. December 2012 (version count percentage) 0.16.1 174 0.169591 0.5 2 0.001949 0.6 3 0.002924 0.7 3 0.002924 0.8 2 0.001949 0.9 6 0.005848 0.8.1 2 0.001949 0.1 2 0.001949 0.11 4 0.003899 0.12 2 0.001949 0.13 4 0.003899 0.14 17 0.016569 0.15 156 0.152047 0.16 4 0.003899 0.17 538 0.524366 0.18 105 0.102339 0.13-RC1 2 0.001949 January 2013 (version count percentage) 0.16.1 247 0.125063 0.5 2 0.001013 0.6 2 0.001013 0.7 4 0.002025 0.8 2 0.001013 0.9 10 0.005063 0.8.1 3 0.001519 0.1 2 0.001013 0.11 14 0.007089 0.12 2 0.001013 0.13 6 0.003038 0.14 21 0.010633 0.15 144 0.072911 0.16 2 0.001013 0.17 870 0.440506 0.18 642 0.325063 0.13-RC1 2 0.001013 February 2013 (version count percentage) 0.16.1 218 0.071312 0.9 9 0.002944 0.8.1 3 9.81E-04 0.1 2 6.54E-04 0.11 12 0.003925 0.13 4 0.001308 0.14 17 0.005561 0.15 121 0.039581 0.16 2 6.54E-04 0.17 1788 0.584887 0.18 675 0.220805 0.18.1 206 0.067386 Chris |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X