On 2/2/15 1:21 PM, Lauren Rother wrote:
> The Modules team and I are excited to finally announce the newest
> version of the Puppet Language Style Guide.
>
> We've reworked the guide to reflect the new features and capabilities of
> Puppet 3.7, and we've expanded it to cover more topics related to
> building manifests and modules. If you're interested in publishing a
> module to the Puppet Forge or are looking to get your module "Puppet
> Approved," the updated guide is a great place to start.
>
> It was a massive, company-wide effort to update this style guide, but
> I'm sure we didn't catch everything. If you notice a mistake or would
> like more information on something that's not currently covered, please
> file a ticket. We plan to regularly update the guide from here on out,
> and we definitely anticipate another big release in the months after
> Puppet 4 comes out.
>
> Puppet Language Style Guide:
> https://docs.puppetlabs.com/guides/style_guide.html
>
> File a ticket:
> https://tickets.puppetlabs.com/browse/DOCUMENT/
>
> The Puppet Approved program:
> https://forge.puppetlabs.com/approved
>
> Thanks!
> Lauren
>
> --
> *Lauren Rother*
> Technical Writer
> Puppet Labs, Inc.
Hi,
Awesome work on the new style guide! I've got a few questions and some
suggestions.
== 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.
== 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.
== Section 10.2
Would add that includes should happen right after defining parameters
and before validation.
== 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,
}
== 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.
== Section 18
This wording is not very clear. Are you saying that parameters should be
listed in the order that they are used instead of alphabetical order?
Agree with adding resources, though how this actually works with adding
parameters is unclear.
Best regards,
-g
--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658
--
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/54CFDD0D.40801%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.
