Establish consistent naming strategy for model fields & filters #11296

Open
opened 2025-12-29 21:43:13 +01:00 by adam · 0 comments
Owner

Originally created by @jeremystretch on GitHub (Jun 20, 2025).

Proposed Changes

Devise and document a comprehensive strategy for naming the following:

  • Model fields
  • Reverse relations (e.g. related_name)
  • Generic relations
  • Filters

There may be additional elements applicable for inclusion here. An in-depth audit of the code is necessary to identify a prudent scope for these changes.

Justification

There are many instances where the names of these elements differ unexpectedly, stemming from organic growth over time and the absence of a clear directive.

For instance, the PowerFeed model has a reverse relation on the Rack model named powerfeeds, but its reverse relation from Tenant is named power_feeds. Neither of these is necessarily incorrect, but the same name should be used in both cases.

Originally created by @jeremystretch on GitHub (Jun 20, 2025). ### Proposed Changes Devise and document a comprehensive strategy for naming the following: - Model fields - Reverse relations (e.g. `related_name`) - Generic relations - Filters There may be additional elements applicable for inclusion here. An in-depth audit of the code is necessary to identify a prudent scope for these changes. ### Justification There are many instances where the names of these elements differ unexpectedly, stemming from organic growth over time and the absence of a clear directive. For instance, the PowerFeed model has a reverse relation on the Rack model named `powerfeeds`, but its reverse relation from Tenant is named `power_feeds`. Neither of these is necessarily incorrect, but the same name should be used in both cases.
adam added the type: housekeepingnetboxstatus: backlog labels 2025-12-29 21:43:13 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11296