Re: Attribute order recommendations

I can't say I share the author's admiration for Chekhov. When I watch a
Chekhov play, I'm usually sitting there wishing the characters would just get
on with the action and cut out the small talk.

Yes, Serhiy is right, consistency in naming is useful, and consistency is also
useful in other aspects of coding. But I'm not sure there are any "right
answers" as to what conventions are best.

I think my instinct with attributes is to put them in order of rarity: the
most common attributes first, then the less common ones. So I tend to write

<xsl:param name="p" as="xs:integer" select="0"  tunnel="yes"/>

But asking someone else to do the same is a bit like asking them to change
their handwriting to match yours; I'm not sure it's well-spent effort.
However, I wouldn't object to an IDE that regularises the attribute order to
match project-level settings.

Michael Kay
Saxonica



> On 25 Aug 2020, at 08:45, Michael MC<ller-Hillebrand mmh@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Folks,
>
> Understanding XSLT as quick as possible is important. This blog post with
the motto "Spare the maintainer" impressed me some years ago:
https://blog.xml.rocks/xslt-naming-conventions/
<https://blog.xml.rocks/xslt-naming-conventions/>
>
> But what about attribute order conventions?
>
> I started putting the typing attribute as="b&" at the end of e.g.
xsl:variable, xsl:function or xsl:param.
>
> But then I meet tunnel="yes", shall I put it before as="b&" or at the very
end, to make it more obvious to the casual observer?
>
> Also, in a recent post by Graydon Saunders I notice as="b&" as the very
first attribute on every xsl:variable, even before name="b&" which also makes
sense to me somehow.
>
> Have I missed some insightful source/post, or can we discuss the benefits of
attribute order conventions?
>
> - Michael MC<ller-Hillebrand
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/293509> (by
email <>)