XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Special case code is evil … properties of programming languages that enable avoidance of special case code

Hi Folks,

I think special case code is evil.

What properties must a programming language possess to enable programmers to reduce (or eliminate) the need for writing special case code? This might be an interesting research project for a graduate student.

Michael Kay gave a terrific example of avoiding special case code. He said this on the xsl-list:

---------------------------------------------------------------

In XSLT 1.0 you often see code that does

 

<xsl:for-each select="item">

  <xsl:value-of select="."/>

  <xsl:if test="position() != last()">

    <xsl:text>, </xsl:text>

  </xsl:if>

</xsl:for-each>

 

That's special case code to handle the last item in a list. In 2.0 we introduced the separator attribute, so this becomes

 

<xsl:value-of select="item" separator=", "/>

 

So yes, we made a language design change to reduce your need to write special-case code.

---------------------------------------------------------------

That is just a portion of Michael’s message. I recommend reading his entire message, it is great:

https://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/202106/msg00090.html

Last week I was grappling with a problem that seemed to require special case code but then Mukul Gandhi showed me a small tweak which resulted eliminating the need for special case code. Here is a recap of that discussion:

---------------------------------------------------------------

I created the following XPath expression to fetch the <Row> element where Cell[1]/Data equals $element and Cell[2]/Data equals $parent.

 

$document/Row[Cell[1]/Data eq $element][Cell[2]/Data eq $parent]

 

However, when $parent is empty, the XPath expression fails.

 

I was all set to write special case code:

 

<xsl:if test="empty(Cell[2]/Data)"> do something </xsl:if>

 

Bad, bad, bad.

 

But then Mukul showed me an XPath expression that works correctly -- whether $parent is empty or not -- without any special case code:

 

$document/Row[Cell[1]/Data eq $element][Cell[2]/string(Data) eq $parent]

 

Just add string(…) around Data. Awesome!

---------------------------------------------------------------

 

A few days ago I was writing some XSLT to show, for each element in an XML document, its name, the name of its parent, the name of its grandparent, and the name of its great-grandparent:

 

<xsl:template match="*">

    <row>

        <element><xsl:value-of select="name(.)"/></element>

        <parent-element><xsl:value-of select="name(..)"/></parent-element>

        <grandparent-element><xsl:value-of select="name(../..)"/></grandparent-element>

        <great-grandparent-element><xsl:value-of select="name(../../..)"/></great-grandparent-element>

    </row>

    <xsl:apply-templates select="*" />

</xsl:template>

 

Obviously as the XSLT traverses through an XML document some elements don't have a great-grandparent or a grandparent or even a parent. But I didn't need to write special case code to check those conditions. That is terrific!

 

To recap:

  • Special case code is evil.
  • Are there properties that a programming language must possess that enable programmers to write code that is free of special case code?
  • Is it theoretically possible to never have to write special case code?

 

I welcome your thoughts and comments.

 

/Roger



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS