On 2 February 2015 at 21:58, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > Inline.... > > On Mon, Feb 2, 2015 at 3:24 PM, Garrett Honeycutt <g...@garretthoneycutt.com> > wrote: > <snip/> >> >> Awesome work on the new style guide! > > > Completely agree! > >> >> >> == Section 5 >> Why the arbitrary line length? Puppet's DSL does not have the ability to >> break lines, such as '\' in bash, so imposing any limit does not buy >> anything, certainly not readability. If you want to give clear error >> messages that improve readability they will include the variable and its >> data which could be greater than 140 characters. In essence, until there >> is a way to break lines in the DSL, there should not be any limit to how >> long a line could be. >> > > 100% agree with this. I always turn off line length checking because > otherwise, it's completely unreadable over time. > >> >> == Section 9.6 >> This suggests that using symbolic modes (mode => 'u=rw,g=r,o=r') are >> acceptable. What is the purpose of this? This decreases readability and >> understanding. > > > How do you do this with numeric modes? > > mode => 'o-rwx' > > I.e. I don't care what U and G are but O better not be rwx. > > I would say that numeric should be 'preferred' but that symbolic should be > completely acceptable. > >> >> == Section 10.2 >> Would add that includes should happen right after defining parameters >> and before validation. >> > > I'd like to vote for putting all validation at the bottom of the file. > > Honestly, we're getting quite heavy in the amount of cruft in the files in > general. > > For a file with 30 parameters: > > ~ 120 lines of comments > ~ 30 lines of parameters > ~ 30 lines of validation
Worth noting that much of the validation is type checking, and with actual real types coming in 4.0 I'm looking forward to deleting much of those lines of validate_ function calls. http://puppet-on-the-edge.blogspot.co.uk/2014/06/optionally-typed-parameters.html Gareth > > This is *before* you get to any code. And, of course, the processor has to > ignore all that stuff, which could be upwards of a couple of MB of data for > large code sets. > > Would moving the comments to another file be better? modulename/doc/init.md, > modulename/doc/subclass.md, etc...? > > Anyway, back to my point. Having 30 more lines of stuff to wade through > before I get to code is just irritating, particularly when Puppet prints out > the exact line for validation when it errors out causing an immediate lookup > capability. > > Should there be some standard for 'Here There Be Code?'. > > For Example: > > # Commenty goodness > # > class foo ( > ... 30 params that point to another file ... > ) { > > ... 40 lines of validation magic .... > > ## I LOVE CODE ## > > user { 'something_useful': } ... > > == Section 10.2.7 > > I tend to order things in resource alphabetical order because then, if I'm > looking for a file resource, it's in the 'F' section. And I still like the > fact that order doesn't matter in Puppet unless I tell it to. Accordingly, > should I happen to break my order accidentally, I really don't want to care. > >> == Section 10.4 >> Suggest adding that chaining arrow syntax should only be used with the >> reference syntax and not between resources. The example below is a bad >> use of the chaining arrows that leads to changing ordering by >> inadvertently moving resources around. This is easy to do when merging >> software. >> >> package { 'foo': >> ensure => present, >> } -> >> >> service { 'food': >> ensure => running, >> } >> > > 100% Agree. This is very difficult to troubleshoot. > >> >> == Section 10.6 >> Suggest that while having required parameters for defines is OK, having >> them for classes is not. There should never be required parameters for a >> class. This breaks the ability to `include` a class. >> > > No, I disagree here. There are (many) times that I *need* you to give me a > parameter, I can't make one up that is magically correct. Moving this to a > define-only state means that we have to start slinging around singleton > defines which is what parameterized classes got us away from. > > I'd rather have my compile break than end up with a system doing something > nonsensical, particularly when the security of the system may be at risk. > >> >> <snip/> > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CANs%2BFoWQ3LhkzndGmgzSVt%3D1xR%2BjpUFj0SPWuftS65PNSJWX_Q%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAFi_6yL_5YCskYYHJvd03JgBDkXyCJGMZQqyj7P9-DTSE4ng8A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
