-
Notifications
You must be signed in to change notification settings - Fork 11
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
naming convention for default names #31
Comments
The NWB Best Practices recommend that a data type be named the same as the name of the data type, e.g., An analogous case is the This conflict between conventions causes inconsistencies and confusion, especially when users create extensions, and is a pain to deal with. I don't have a good solution except to use lower case when an object is intended to be a named field in another data type and camel case otherwise. It's not ideal. Some other options:
|
Thanks for the clarification.
I think we usually use lowercase names for all fixed names in NWB (e.g., processing etc.) so this option seems consistent with naming in the core NWB schema. |
Another aspect of this is the name assigned in the default arguments of some PyNWB classes, e.g. the default name for the Position class is "Position" |
snake_case reflects the Python convention of having classes be UpperCase and instances be snake_case, however I think that convention is pretty Python-specific, and this differentiation is less important here, where there isn't such a danger of confusing class objects with instances of the class, so it makes more sense to just stick with the same name. It does create a conflict of convention when the class is a field of another class. |
Makes sense. In the Python analogy, every object in a file is an instance, the equivalence of the class is the specification of the neurodata type in the schema. In that sense, using snake case for names seems most consistent. |
So it sounds like if we change the best practice to snake_case naming for all objects (option 1) we would avoid the conflict between stand-alone objects and child objects AND follow python naming convention (making it more intuitive for python users), at the cost of temporary confusion for people already accustomed to CamelCase. Seems like a reasonable option. |
Could you clarify the convention for assigning the
default_name
values in this extension. Some of the types seem to use camel-case, e.g.,default_name: PoseTraining
, while other types use all-lowercase , e.g.,default_name: skeleton_instance
.The text was updated successfully, but these errors were encountered: