openerp-expert-framework team mailing list archive

[Ovnicraft <ovnicraft@xxxxxxxxx>]

On Tue, Apr 17, 2012 at 6:24 AM, Olivier Dony <odo@xxxxxxxxxxx> wrote:

> On 04/16/2012 07:37 PM, Valentin LAB wrote:
> >
> > Is there any coding convention enforced on the OpenERP Code ?
>
> As Lionel (Numérigraphe) said, we try to enforce common-sense best
> practices
> when working on new developments, refactoring existing code, and every
> opportunity we have to improve code.
>
> However, we prefer to avoid changing unimportant things like whitespace,
> line-wrapping etc when we don't have any other reason to touch the code.
> In general it has little value compared to the cost of decreasing the
> visibility of the main goal of the patch, creating extraneous merge
> conflicts,
> and even causing unexpected regressions.
>

At this point we need to wait for 7.0.

>
> In rare cases it may make sense to do a quick mass-cleanup, if and when the
> timing is convenient.
>
>
> > I'm thinking about:
> > - code pure aesthetic as the PEP08, or PEP257
> >     http://www.python.org/dev/peps/pep-0008/
> >     http://www.python.org/dev/peps/pep-0257/
> >     (ie: trailing whitespace, 80 col ...)
>
> Those PEPs are very good but we don't enforce them to the letter, common
> sense
> always prevails [1]. As an example, I will never hold it against any
> developer
> if they don't strictly wrap their line at 80 chars, because we don't have
> good
> reasons to enforce it. When was the last time you _really_ needed 3 files
> side-by-side on the same screen? OTOH that wrapping length flexibility
> usually
> improves readability (e.g. 90 cols are fine if it avoids wrapping at all)
>

If you don´t enforce them, IMO that´s wrong.
Why?, now in code:
arithmetic w/o spaces
documentation string, here OpenERP has a big problem, check PEP257
class_name instead ClassName
there is methods with +150 lines
Lines with +120 chars
79 chars was for old screens (common sense applied ok)
multiple statements in same line
concat strings with +, here you can check ORM and you get this, so python
>=2.5 has a better format string world.

This are basic python style coding and openobject must enforce them, we
hope in 7.0 will fixed.

Regards,



>
> > - best practice as checked by pylint
> >     (size of variables, number of method, ...)
> > - code coverage checks
> > - code complexity checks
>
> For these kinds of improvements we definitely welcome patches, such as
> refactoring of over-sized methods, dead code removal, etc. But one has to
> keep
> in mind that there's always a risk, these tools only give hints...
>
>
> I hope this gives you a general idea of what to do when something is
> bugging
> you in the source code... ;-)
>
>
> [1] PEP8 starts by telling you when to break those rules that it has not
> stated
> yet.. there's a reason to that :-)
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Cristian Salamea
@ovnicraft