Skip to content
This repository has been archived by the owner on Feb 24, 2021. It is now read-only.

Multiple guidelines #546

Open
iRon7 opened this issue Jun 20, 2020 · 1 comment
Open

Multiple guidelines #546

iRon7 opened this issue Jun 20, 2020 · 1 comment

Comments

@iRon7
Copy link

iRon7 commented Jun 20, 2020

Let's start with saying, it is good to have some guidelines and best practices at all.
But the value decreases if you need to choose between multiple guidelines and best practices:
There is (at least) this DSC Resource Style Guidelines & Best Practices and The PowerShell Best Practices and Style Guide. Both guidelines slightly differ.
With all respect, for me, The PowerShell Best Practices and Style Guide is leading, mainly because I am more concerned with the PowerShell in general than DSC. Nevertheless, I want you to know that I created an Unquoted Strings best practice issue at their project site with might concern you because my ConvertTo-Expression cmdlet is used by your DSC project.
From my view, it would make more sense if there is just one style guide and best practices with possibly a subset of DSC guidelines and best practices that highlights the differences and explains why it deviates from the general PowerShell style guide and best practices.

@gaelcolas
Copy link
Contributor

Hi @iRon7
Thanks for the feedback, and we agree that the clarification is needed.

It's even more confusing because a lot of the guidelines and practices have been taken over by the DSC community and we'll be removing the DSC resource Style Guidelines you pointed to very soon, and link to the DSC Community one instead.

The reason for divergence between PowerShell and DSC is historic, and the main reason we keep some of those rules is that we have the PSSA rules to enforce some of them, and we want consistency across DSC resources rather than uncoordinated changes and discrepancies (most maintainers look after several resource modules).

Yes, we'd like to align with those Guidelines, but we want to have the tools to enforce them before we make the switch.

There's also more to it than it looks, we also want our tooling and documentation to support class based DSC resources before we can generalize its adoption.

By the way, we're always looking for contributors :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants