# Three module conventions to consider. **URL:** \ **Category:** Ansible Project\ **Created:** [May 15, 2012, 4:37pm UTC](https://forum.ansible.com/t/three-module-conventions-to-consider/11549 "2012-05-15T16:37:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Brad\_Olson](https://avatars.discourse-cdn.com/v4/letter/b/779978/32.png) [@Brad\_Olson](https://forum.ansible.com/u/Brad_Olson)\ **Post date:** [May 15, 2012, 4:37pm UTC](https://forum.ansible.com/t/three-module-conventions-to-consider/11549/1 "2012-05-15T16:37:53Z")
Just wondering about a couple module conventions that are developing as I read and write modules. 1. Boolean params. This one I feel pretty strongly about. While I'm glad that ansible is flexible about how modules are written, I think an explicit policy for core modules would be best. Yes/No? True/False? 0/1? Case: lower, initial, insensitive? 2. 'debug' param. I'm not certain about this one, but given that stderr is not the way to give debug info anymore, I think reserving a boolean debug param meaning, "give me lots of information if something goes wrong" would be helpful as people flesh out playbooks. 3. split("=",1). This is a subtle gotcha. Most core modules parse params by shlex() then string.split("="). If a param contains a "=", you'll crash your param parsing. Usually what's wanted is .split("=", 1) FWIW, --Brad ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [May 15, 2012, 4:49pm UTC](https://forum.ansible.com/t/three-module-conventions-to-consider/11549/2 "2012-05-15T16:49:02Z")
> Just wondering about a couple module conventions that are developing > as I read and write modules. > > 1. Boolean params. This one I feel pretty strongly about. While I'm > glad that ansible is flexible about how modules are written, I think > an explicit policy for core modules would be best. Yes/No? True/False? > 0/1? Case: lower, initial, insensitive? We have already standardized on yes|no. Modules should lowercase inputs but there should be no need to check for true, 't', 'y', 'yup', 'ok', 'reckon', etc > 2. 'debug' param. I'm not certain about this one, but given that > stderr is not the way to give debug info anymore, I think reserving a > boolean debug param meaning, "give me lots of information if something > goes wrong" would be helpful as people flesh out playbooks. Nope -- we should instead just use logging for what it changes here. That's in plan for 0.5 > 3. split("=",1). This is a subtle gotcha. Most core modules parse > params by shlex() then string.split("="). If a param contains a "=", > you'll crash your param parsing. Usually what's wanted is .split("=", > 1) Yeah, though very few parameters need to take an = either. ---
**Author:** ![Brad\_Olson](https://avatars.discourse-cdn.com/v4/letter/b/779978/32.png) [@Brad\_Olson](https://forum.ansible.com/u/Brad_Olson)\ **Post date:** [May 15, 2012, 7:28pm UTC](https://forum.ansible.com/t/three-module-conventions-to-consider/11549/3 "2012-05-15T19:28:47Z")
> We have already standardized on yes|no. Modules should lowercase > inputs but there should be no need to check for true, 't', 'y', 'yup', > 'ok', 'reckon', etc Great! > Nope -- we should instead just use logging for what it changes here. > That's in plan for 0.5 Also great! > \> 3. split("=",1). This is a subtle gotcha. Most core modules parse > \> params by shlex() then string.split("="). If a param contains a "=", > \> you'll crash your param parsing. Usually what's wanted is .split("=", > \> 1) > > Yeah, though very few parameters need to take an = either. Agreed, but it's nasty when it does. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [May 15, 2012, 7:31pm UTC](https://forum.ansible.com/t/three-module-conventions-to-consider/11549/4 "2012-05-15T19:31:06Z")
> Agreed, but it’s nasty when it does. Yeah please patch any you find that work strangely. ---
**Author:** ![Brad\_Olson](https://avatars.discourse-cdn.com/v4/letter/b/779978/32.png) [@Brad\_Olson](https://forum.ansible.com/u/Brad_Olson)\ **Post date:** [May 18, 2012, 4:08pm UTC](https://forum.ansible.com/t/three-module-conventions-to-consider/11549/5 "2012-05-18T16:08:42Z")
K