Coding Guidelines
Here, we will put all coding guidelines that community will decide around oemedical:
First already defined:
1.- All .py files should comply with pep8.
2.- All unique classes defined will start with OeMedical [CameCase].
2.5- All unique objects defined will comply with openerp standard oemedical.name [CameCase].
2.6.- All methods will be named snake_case.
3.- One Folder per object and view.
4.- All views will be V7.0 compatible.
5.- All new module and file will have this diclaimer regarding with licence and authoring:
http://
6.- All documentation will be in a web_doc_oemedical module to be able to embed documentation compiled with sphinx in the same server.
7.- Data loaded should be in an extra module called oemedical_data, to separate data errors from model errors, frequently data dont change so much, because it is based on Standards.
8.- Modules that improve functionality with the core of openerp, should be in an extra module, it means:
i.e:
Creation of Automated invoices and commercial management: oemedical_account
Relation with sale orders and purchase: oemedical_sale oemedical_purchase
Main Objective is to be able to use Medical, wiithout an especific feature that can brake all installation and in some context is not necesary.
To discuss.
1.- All object should have.
-- Process.
-- Help on fields.
-- Help on Actions.
2.- All methods will have a documentation as is documented here:
http://
3.- At least the model is still on development, we must avoid code commented, all commentaries must be usuables by sphinx to use autodocumentation embebed.
4.- To discuss and important: Until V7, we will have per object: js, css, qweb, Should we put in separate folders and declare or we can just use a unique js and css folder?
5.- If a model is inherited, we should create them own view with them own action, to be sure the user is able to use this model in its functional context without unnecesary information in this function.
6.- Is a model impact some kind of a more than 3 steps flow, the object MUST have Workflow.
IMHo it is all.
In whiteboard you can decline or approve something or add what you think.
Blueprint information
- Status:
- Not started
- Approver:
- OEmedical Driver
- Priority:
- Undefined
- Drafter:
- Nhomar - Vauxoo
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Review
- Series goal:
- None
- Implementation:
-
Informational
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
One Time it is defined i will pass to *.rst files.
Defined:
7. Data in extra module, this must be discussed because developers put data files on data/ by module.
Nhomar Said: I'm talking to data to comply with some medical standards sometimes there 10000 records that for testing purpose are not necessary, and we in development time must to comment the code everytime we will install the module, other reason is that probably we will have hospitals that need all data, and other ones that simply data doens't means nothing for them. In Data necessary for the module working, i'm with your point, do you approve with this explanation?
Discussion points:
3. code *must* be commented this is highly important, there is no place to accept dont document code.
Nhomar Said: Ok it is approved by default so.
5. But what happen when i am inheriting jus for add a field ? i need to create a new view by rule ? IMO this complicate the process.
NHomar Said: Yes you are right, let me explain by my self better, if we add 20 fields in oemedical and in some case it just have sense in the context of an attendance of patiente, i must creaste a new view, but if you are adding a field, and this field have sense in all cases the view is not necesary.
It is something like crm_claim and crm_phoncall, both are the same object, but both needs different fields to be filled in different functional contexts, but BTW i think it can be a rule with exceptions, what do you think?
6. I am not clear here, but there is object just in transactional way, has a wkf must be decided depending from business case.
Nhomar Said: It depends, IMHO everything MUST pass for a workflow to be sure all considerations in a devel are considered, i.e.: if i will improve invoicing, we can pass a first version of devel just inheriting, but ASAP it must be done trhought workflows.
Nhomar Said: Look the concept that support this paradigm: http://
