• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Eclipse Code Review

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Currently we use three (PMD, FindBugs and Checkstyle) Eclipse tools to make a painless code review.

We want to avoid that the developer commit the code with no error regarding this tools in Eclipse. This is possible? Has anyone do something like that?

ps: Sorry my bad english
 
Marshal
Posts: 22456
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving to our IDEs forum.
 
Douglas Mendonca
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Prime wrote:Moving to our IDEs forum.



Thanks! Any idea guys?
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have not found any way in Eclipse, or in subversion for that matter, to prevent a user from checking in code that does not meet the coding guidelines. For my team, I demand that all checked in code either has no warnings or that any warnings are clearly documented in the code as to why the guidelines could not be followed. Of course, they can always check stuff in anyway but then they will incur my wrath. Most people fix their code mainly to prevent the yellow flags from showing up in the editor.

One possibility is if you use Maven for builds, have it generate the various code review reports and publish them on a web site. Then violators will be caught fairly quickly because everyone can see the coding flaws.

Moral of the story: do not discount peer pressure!
 
Douglas Mendonca
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Peter Johnson wrote:I have not found any way in Eclipse, or in subversion for that matter, to prevent a user from checking in code that does not meet the coding guidelines. For my team, I demand that all checked in code either has no warnings or that any warnings are clearly documented in the code as to why the guidelines could not be followed. Of course, they can always check stuff in anyway but then they will incur my wrath. Most people fix their code mainly to prevent the yellow flags from showing up in the editor.

One possibility is if you use Maven for builds, have it generate the various code review reports and publish them on a web site. Then violators will be caught fairly quickly because everyone can see the coding flaws.

Moral of the story: do not discount peer pressure!



Thanks a lot Peter, currently we use Hudson for this purpose, a very good tool by the way. I will continue my quest.
 
author & internet detective
Posts: 40747
827
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Peter Johnson wrote:I have not found any way in Eclipse, or in subversion for that matter, to prevent a user from checking in code that does not meet the coding guidelines.


You could use a Subversion pre-commit hook, no? If you had the ability to run the coding guidelines check on the server.

I wouldn't recommend it though for a number of reasons - slower commits; extra version control complexity; problems on those occasions you want to commit something anyway. (say for a production problem and then fix it right after)
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another option is a two-stage commit process. I'm also in the "don't bother" club, at least just for the tools you list (particularly since some things they find might not actually be errors). Two-stage commits are nice when the master build *must* not break, though.

Note that those tools alone are most definitely *not* enough for a real code review--they deal only with some code mechanics. A review with actual people is still really important, particularly if mentoring junior developers.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic