NatLabRockies / NatLabRockies/OpenStudio
Update/Create internal Guidelines for developpers
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 646
- Forks
- 237
- Avg merge
- 3d 11h
- Merged PRs (30d)
- 10
Description
Enhancement Request
@joseph-robertson and I have been discussing this periodically, and at some point we ought to do something.
This is going to be a running list of things we should clarify. It would benefit anyone getting onboarded, but it would probably benefit seasoned developers too (I personally don't wrap objects often enough nowadays to remember 100% how to proceed with the clone/remove/children right away, I have to think)
Detailed Description
- Choice dependent fields
- Eg Field A is a choice field, Field B is only used if Field A = "Value1" and Field B is only used Field A = "Value2"
- Should the
setFieldA(std::string choice)clear the unused field? - If not, should you only translate choice-dependent fields to the IDF?
- Clarify how you should pick whether something is a ModelObjhect, PArentObject, ResourceObject, HVACComponent
- Clarify the methods one should be overriding, especially with respect to
children,clone,remove- (Note: I have clarified a bit of that in GenerateClass.rb in this PR https://github.com/NREL/OpenStudio/pull/5496)
- Clarify the methods one should be overriding, especially with respect to
Possible Implementation
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing GenerateClass.rb and the referenced pull request 5496 to understand the existing clarification. Then resolve and document the open questions about choice-dependent fields and ModelObject, ParentObject, ResourceObject, and HVACComponent conventions, including children, clone, and remove. Done means the internal guidelines clearly record these decisions for onboarding and ongoing development.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, ruby
- Domain
- developer-experience, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100