Closed prjemian closed 2 years ago
I, too, was wondering about the scope of this test function: test_naming_conventions__issue_65()
. #65 is about attributes that start with @
. The existing cover that intent but also go beyond that, testing incorrect names in attributes and fields. The TODO items appear to go even further, so they can probably be deleted (or moved to some other place where they might be used).
And there are merge conflicts to be resolved.
This pull request introduces 1 alert when merging 536241efca1fef4744e493f68d0d6c8b7a6865f0 into 21ab1b9ba118965c23f03e5bfd1dbbbbb40d5b8e - view on LGTM.com
new alerts:
@carterbox : Merge conflicts resolved. Added docstring to test_naming_conventions__issue_65()
function. Ready for review.
I'm still confused.
["v2018.5", 99, "/entry@NX_class", "OK", "validItemName", "pattern: NX.+"],
["v2018.5", 99, "/entry@default", "OK", "validItemName", "strict pattern: [a-z_][a-z0-9_]*"],
["v2018.5", 99, "/entry/data@NX_class", "OK", "validItemName", "pattern: NX.+"],
["v2018.5", 99, "/entry/data@signal", "OK", "validItemName", "strict pattern: [a-z_][a-z0-9_]*"],
Why are these names marked as 'OK' if @
is not allowed in the Nexus names?
The string"/entry@NX_class"
refers to HDF5 address /entry
with attribute named NX_class
. The first @
is a compact representation agreed upon within NeXus to mean "has attribute with name that follows this a
symbol".
NeXus manual page describes this use.
@carterbox Thanks!
Start with unit tests from previous generation of this code.
https://manual.nexusformat.org/search.html?q=warning