gaelcolas
commented
4 years ago 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 :)
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-Expressioncmdlet 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.