Closed paulochang closed 4 months ago
Bad/Good for me sounds more clear and straightforward comparing to new fancy language :)
What do you think about the multiple cases:
<!--/* Bad */-->
<div data-sly-include="content.html" data-sly-unwrap></div>
<!--/* Bad */-->
<div data-sly-resource="${item @ selectors='event'}" data-sly-unwrap></div>
<!--/* Bad */-->
<div data-sly-test="${event.hasDate}" data-sly-unwrap>
...
</div>
<!--/* Good */-->
<sly data-sly-include="content.html"></sly>
<!--/* Good */-->
<sly data-sly-resource="${item @ selectors = 'event'}"></sly>
<!--/* Good */-->
<sly data-sly-test="${event.hasDate}">
...
</sly>
vs the proposed change
<!--/* Instead of */-->
<div data-sly-include="content.html" data-sly-unwrap></div>
<!--/* Use */-->
<sly data-sly-include="content.html"></sly>
<!--/* Instead of */-->
<div data-sly-resource="${item @ selectors='event'}" data-sly-unwrap></div>
<!--/* Use */-->
<sly data-sly-resource="${item @ selectors = 'event'}"></sly>
<!--/* Instead of */-->
<div data-sly-test="${event.hasDate}" data-sly-unwrap>
...
</div>
<!--/* Use */-->
<sly data-sly-test="${event.hasDate}">
...
</sly>
we could also try a sort of hybrid:
<!--/* Good */-->
<div data-sly-include="content.html" data-sly-unwrap></div>
<!--/* Bad */-->
<sly data-sly-include="content.html"></sly>
<!--/* Bad */-->
<div data-sly-resource="${item @ selectors='event'}" data-sly-unwrap></div>
<!--/* Good */-->
<sly data-sly-resource="${item @ selectors = 'event'}"></sly>
<!--/* Bad */-->
<div data-sly-test="${event.hasDate}" data-sly-unwrap>
...
</div>
<!--/* Good */-->
<sly data-sly-test="${event.hasDate}">
...
</sly>
For me, Good/Bad are easier to scan.
I'm not reading such guidelines but instead scanning them, so easy scanning is more important than the natural flow of the reading.
I'm going to drop this PR and open a new one just re-grouping the examples to collect some feedback on it.
The "Instead of" -> "Use" pattern is used instead of "Good" "Bad" in Adobe's Style guide. This is IMHO easier to read.
Additionally, each contrasting case is now presented separately. (see 4.1). This makes it much clearer to understand the preferred approach.
This relates to #29