On Tue, Apr 17, 2012 at 6:24 AM, Olivier Dony <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp > -- Cristian Salamea @ovnicraft
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
