Ticket #10317 (closed PLIP: wontfix)

Opened 6 years ago

Last modified 5 years ago

Automatic reporting on code style errors and warnings

Reported by: Pander Owned by:
Priority: major Milestone: 4.2
Component: General Version:
Keywords: Cc:

Description

Proposer: Pander
Seconder:  http://plone.org/team/FrameworkTeam

Motivation

In an ongoing effort to increase code quality and by employing existing code style checking software, it would pay off to have automated reporting on code style errors and warnings.

Assumptions

Reporting on code style errors and warning might prevent bugs of high risk code going into production releases. The reporting will only be advisory for the developers in assisting them to improve code quality.

Out of scope are post-commit hooks and other penalties. The goal is to reward products with 0 errors and 0 warnings if they comply with the code style. In order keep a workable situation, controversial or difficult to fix rules will be disabled at some stage and enabled once they contribute again to improving code quality.

Report any code style issues upstream in the projects for the checking software.

Developers should be rewarded for adhering to proper code style, not punished. If you would like you product to stand out, having no style errors or warnings is one way of drawing extra attention.

Proposal & Implementation

In nightly build before units are being run, report with the following tools on code style:
 http://pypi.python.org/pypi/pep8
 http://pypi.python.org/pypi/pyflakes
 http://pypi.python.org/pypi/pylint
 http://pypi.python.org/pypi/PyChecker (currently not support Python 2.6)

The latter two are optional, the first two are most important to implement.

This process could be integrated with Hudson.

Deliverables

Automated reporting on code style errors and warnings per product with pep8 and pyflakes while ignoring some rules.

A person willing to manage and fine tune this process.

If possible, an icon per release per product on  http://plone.org/products indicating that code style is with or without any error or warning and a link (via the icon) to the reports.

Documentation on the website describing this process and how developers can do code style checking in vim/emacs/eclipse+pydev/etc.

Communicate successful implementation to  http://pypi.python.org/pypi motivating them to follow this example.

Risks

Especially in the beginning this could result in very large reports or reports with errors or warnings which are hard or controversial to fix. This can be governed by disabling certain rules temporarily.

Please follow the pep8 style, even though it is also changing and not perfect. If Plone is to have customisation, it should only be in temporarily disabling certain rules and not changing rules. For that, please file tickets at pep8 and other tools. This risk can be managed by wisely configuring the tools.

Participants

 http://plone.org/team/FrameworkTeam

Progress

Discussion has been held on Plone developers mailing list and several developers have good experience with these tools.

Change History

comment:1 Changed 6 years ago by limi

  • Milestone changed from 4.0 to 4.x

comment:2 Changed 6 years ago by esteele

We've been experimenting with a Hudson setup for Plone 4 ( http://hudson.plone.org). I have it running zptlint checks against templates, but there's no existing reporting mechanism for that. I've done the same with pylint elsewhere.

comment:3 Changed 5 years ago by rossp

  • Status changed from new to closed
  • Resolution set to wontfix

PLEASE READ THIS AND RE-OPEN VALID PLIPS!

As we launch the new PLIP process we'd like to see which PLIPs:

  • are still appropriate/needed
  • still have owners/proposers/champions
  • still have available implementers

If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.

comment:4 follow-up: ↓ 5 Changed 5 years ago by pander

  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Milestone changed from 4.x to 4.2

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 5 years ago by rossp

Replying to pander:

If you want to re-open this PLIP, please add the details requested in comment #3

comment:6 in reply to: ↑ 5 Changed 5 years ago by rossp

  • Status changed from reopened to closed
  • Resolution set to wontfix

Replying to rossp:

Without details or a seconder we can't proceed with this PLIP. Please re-open when, and only when, you have a real seconder and provide the details requested.

comment:7 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.