Le 2014-10-22 04:09, Leonardo Pistone a écrit :
> I think we should wipe the document, and start entering the
> conventions that are already accepted, that is those that we already
> check with flake8 and pylint.
+1
> On the topic of one-file-per-class, I understand the reasons, but I
> vote -1
Hi Sandy,
Thanks a log for bringing up the problem of frustration by newcomers.
There are indeed things we can do to ease the barrier of entry.
I think we should wipe the document, and start entering the
conventions that are already accepted, that is those that we already
check with flake8 and py
@sylvain
ok for me
makes sense to have 'mandatory' and 'nice to have' rules
and in 'nice to have' could we capture travis answers in PR comments like ?
"your file ... have more X00 lines, have you considered to split several
files to improve readbility ..."
or
"seems there are no link between mod
Stefen, Raphael +1
What about to have 2 sections in
http://odoo-community.org/page/website.how-to
- "Mandatory" rules: pep8 ... that will block PR if not respected;
- "Nice to Have" rules with sandy's remarks (and others conventions), that
will not block PR;
My 2 cents.
*Sylvain LE GAL*
* Serv
Hello, I share the same opinion as Stefan about this.
In any case we should not forget the big picture and loose our energy on
details that could easily become void depending on the big picture, even if
ideally enforcing such guidelines will be great for new stuff or
refactoring.
Regards and thank
On 20-10-14 16:52, Sandy Carter wrote:
> What the consensus I seem to get out of this is: Often it is better to
> separate the models (especially in xml), but there are some acceptable
> exceptions:
>
> * Small changes to models
> * One to many relationships (single column add to related model)
>
why not just to add an entry in the manifest to say which model has been
inherited/modified as it AFAIU the main reason raised.
splitting the modification in files by model make sense for xml but for py
file as far as they contain a bug number of lines of code we won't gain any
benefit.
my 2 cent
Sandy, for me it's OK this way.
Regards.
2014-10-20 16:52 GMT+02:00 Sandy Carter :
> Hi,
>
> My issue with leaving it to subjective criticism is:
>
> Firstly, if you're new and learning the ropes to contribution to OCA and
> you do your homework, you're going to do two things to make sure your
>
Hi,
My issue with leaving it to subjective criticism is:
Firstly, if you're new and learning the ropes to contribution to OCA and
you do your homework, you're going to do two things to make sure your
module gets integrated. First you'll check existing modules and emulate
what they do and second y
Hi all,
I understand the convenience of finding classes easily, and the
reasons behind this are sound. Still, I do not sopport such a rule on
splitting files.
Still, I think we can and should work to improve subjective quality
and clarity of code. Example: after the machine checked lint, I think
On 10/19/2014 10:46 PM, Graeme Gellatly wrote:
> Hi,
>
> While having a sale order line modification in the same file as sale
> order makes some sense, these can become big files and it's nice to see
> them split, but then in addon modules maybe not. But for me this comes
> down to personal prefe
Hi,
While having a sale order line modification in the same file as sale order
makes some sense, these can become big files and it's nice to see them
split, but then in addon modules maybe not. But for me this comes down to
personal preference, not sure it needs to be a convention. Sometimes it
Hi,
Please let me object to this new rule, which I find wrong in several ways.
I'm very attached to separation of concerns, and I would much rather
have us use the files to group all the code that implements a feature.
Actually, I often prefer to split a class in several files if that makes
sen
Hi,
I agree with Sandy's suggestion.
About the sale_order and sale_order_line files, I would prefer two files.
It avoid to have an exception on the basic rule "one model, one file", that
is maybe not perfect, but like all rules...
Note:
Once that is decided, we can imagine a script to check that
On 18-10-2014 09:12, Pedro Manuel Baeza Romero wrote:
Hi, I'm with Sandy that splitting each model in a class is a win
strategy, but with a middle term: if you have models that comes from a
one2many field, I prefer having these classes also in the same file as
the main class. For example, I wo
I'm agree with Pedro but I think that files must have a maximum number of
line to simplify comprension and reading. For example the new core stock
module is not easy to read because have to many models and to many lines in
one file: splitting it in more files will improve reading and comprension
M
Hi, I'm with Sandy that splitting each model in a class is a win strategy,
but with a middle term: if you have models that comes from a one2many
field, I prefer having these classes also in the same file as the main
class. For example, I would put sale.order and sale.order.line in the same
file, *s
If a module is picked up, it is nice for the dev to be able to see
directly without openening the files what models have been affected.
The product example might start with a single field, but there is no
guarentee that it won't grow with additions of on_change methods or
simple overwrites which e
Hi Sandy,
If we do like this with an example on a module:
2 models modified: 'product.product' and 'product.category' with adding a
new field for each
It takes 5 or 20 lines by model. Having 2 files for this could be a lot.
I prefer one file named 'product.py'.
And if the code grows too much, the
Hi,
I would like propose adding the following to the Module section in
http://odoo-community.org/page/website.how-to
Each XML and python script should be separated and named by model.
example:
_name = 'sale.order' # goes in a file named sale_order.py and the class
name should be SaleOrder
_in
20 matches
Mail list logo
