# module naming conventions?

**URL:** <https://forum.ansible.com/t/module-naming-conventions/18878>\
**Category:** Ansible Developer\
**Created:** [July 28, 2015, 9:36pm UTC](https://forum.ansible.com/t/module-naming-conventions/18878 "2015-07-28T21:36:29Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tim1](https://avatars.discourse-cdn.com/v4/letter/t/b782af/32.png) [@Tim1](https://forum.ansible.com/u/Tim1)\
**Post date:** [July 28, 2015, 9:36pm UTC](https://forum.ansible.com/t/module-naming-conventions/18878/1 "2015-07-28T21:36:29Z")

</div>

Hi folks,

I’m looking for guidance on how one might name modules that potentially have long names based on a deep API hierarchy.

For example, consider an API hierarchy that looks like this

management \> traffic group \> mac\_masquerade\_address

One could name the module

management\_trafficgroup\_mac\_masquerade\_address

But that’s just terribly long. Does anyone have any guidance from experience in naming “long” modules?

Thanks,  
tim

---

<div class="post-metadata">

**Author:** ![Jesse\_Keating](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@Jesse\_Keating](https://forum.ansible.com/u/Jesse_Keating)\
**Post date:** [July 28, 2015, 11:00pm UTC](https://forum.ansible.com/t/module-naming-conventions/18878/2 "2015-07-28T23:00:34Z")

</div>

Is there a multitude of actions that happen at the management \> traffic group \> \* point? can all of those be handled by one module, or will each action require it’s own set of options?

I’d probably look to shrink some of the names down a bit, mgmt\_tg\_mac\_masq\_addr or something like that.

Within the general product, is there any other place that a mac\_masquerade\_address could be configured?

---

<div class="post-metadata">

**Author:** ![Tim1](https://avatars.discourse-cdn.com/v4/letter/t/b782af/32.png) [@Tim1](https://forum.ansible.com/u/Tim1)\
**Post date:** [July 28, 2015, 11:36pm UTC](https://forum.ansible.com/t/module-naming-conventions/18878/3 "2015-07-28T23:36:23Z")

</div>

I think that in this particular case I could have a module\_tg module that is able to field all configuration options.

There are other apis that, on the surface sound familiar, but each has it’s own specific configuration options. For example, an api endpoint for a logging configuration may have multiple destinations (syslog, splunk, arcsight, etc) but each of those has its own configuration options.

I suppose for those I could use a type, name, or destination field and have an “options” key for the options specific to each destination? I feel like I would be repeating myself if I were to have a module\_syslog, module\_splunk, module\_arcsight, etc instead of a module\_log that supported all of them.

To the best of my knowledge, the mac thing is only used in this api.

-tim