-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: Naming convention class #149
Draft: Naming convention class #149
Conversation
Should we use capital casing for the variable names to emphasize that these are Python "const"'s? i.e. |
I suggest we avoid using all-caps for variable names. We may need to use these variables in many places in a component, and it is a pain to type them if they are all-caps.... |
All caps would be consistent with the PEP-8 style guide for constants. |
Users could always use a more convenient alias locally, like what was done here: |
@kejacobson Using all caps makes sense to me if it is consistent with the PEP-8 naming convention. I guess we need to use a local short alias anyway, as @timryanb mentioned. |
Split aero into surface anticipating volume coupling at some point down the road
…f the naming convention classes throughout the tests
…ore since the geometry and mesh sources are no longer the same name.
…amics only" coupling option
…se the initial coordinates, not the deformed coordinates
…bdiscipline of structures
The idea is to form a class that component developers can use instead of explicitly using the name strings. This way if we need to change the name of a variable down the road, everyone's components update automatically