Improve naming convention section

[h-mayorquin]

We discussed today (@rly @stephprince @oruebel) the naming conventions described here:

https://nwbinspector.readthedocs.io/en/dev/best_practices/general.html#naming-conventions

To summarize, the current convention suggests naming things as:
{neurodata_type}{descriptive_specifier}
with examples such as:

• ElectricalSeriesAp
• SpatialSeriesMouse1
• TimeSeriesAnalogSensor

The discussion began around whether we should have a (weak) check that this convention is followed. It was unclear, for the following reasons:

• We don’t consistently follow this convention in the PyNWB tutorials.
• We couldn’t recall the original rationale behind the recommendation, where it came from or why it was proposed.
• The current writing in the best-practices guide could be clearer. According to @rly, the intended message was that if you only have one instance of a given neurodata_type, you could simply use the type name itself as the object’s name, and optionally add a specifier to disambiguate if you have more than one. This is not how I read the current documentation, and if @rly’s interpretation reflects the original intent I feel the documentation should be clarified.
• Both @oruebel and I mentioned that we tend to prefer the opposite naming convention, where the type appears at the end of the name, similar to some forms of Hungarian notation.
• @rly noted, and I agree, that even for a single object (e.g., one TimeSeries), he would prefer to choose a descriptive name rather than simply naming it TimeSeries. On my side, the argument for this is discoverability.

Overall, I personally think we should temporarily remove this naming convention. It is not enforced, we don’t follow it in tutorials, and we lack a clear rationale for it. We should instead gradually build a set of recommendations grounded in user-experience considerations such as API usability and discoverability, and then publish them.

Anything I forgot?

@bendichter @weiglszonja @alessandratrapani

[rly]

Looks good to me. Thank you @h-mayorquin for writing this up.

@rly noted, and I agree, that even for a single object (e.g., one TimeSeries), he would prefer to choose a descriptive name rather than simply naming it TimeSeries. On my side, the argument for this is discoverability.

This is true for generic data types like TimeSeries and DynamicTable where the data type name doesn't really say anything about what kind of data it is. Some neurodata types like Position and Fluorescence are sufficiently descriptive in my opinion.

[oruebel]

This is true for generic data types like TimeSeries and DynamicTable where the data type name doesn't really say anything about what kind of data it is. Some neurodata types like Position and Fluorescence are sufficiently descriptive in my opinion.

True, however, if we create a best practice for naming objects, I think it will be useful to keep it consistent and simple