2

Is a long XSLT file a code smell?

In imperative programming languages it's generally acknowledged that very large classes and/or sub-routines are an indication of possible problems, e.g. a class that is doing too much. Such a class should be considered for refactoring into multiple smaller classes, each having a clearer and more well defined function thus making for code that is more easily unit tested, maintained etc.

Does a similar rule apply for XSL transforms?

When I see a large XSLT my instinct is that it needs breaking up in some way similar to how I would break up and refactor a large class.

redcalx
  • 345
  • 3
  • 14
  • 3
    The [working draft for XSL Transformations (XSLT) Version 3.0 states that](http://www.w3.org/TR/2012/WD-xslt-30-20120710/) one of the primary motivations for the change is to "improve the modularity of large stylesheets, allowing stylesheets to be developed from independently-developed components with a high level of software engineering robustness." – Robert Harvey Jul 23 '15 at 14:37
  • "long" is always relative. In itself there's nothing wrong with long, as long as it's not needlessly long... If something can be cut into pieces without losing performance and without creating unacceptable overhead,.. – jwenting Jul 23 '15 at 20:52
  • Do not look at it in terms of length, but efficiency. If there are chunks of XSLT that do not belong, or are needlessly verbose... then it is too long. But length is a result of the underlying problem. This principle is also true of program code, Word documents, and certainly emails. Also, this comment. Concise is good: every piece should have a purpose. –  Jul 24 '15 at 03:56
  • @Snowman - It's generally beneficial to decompose a large monolithic piece of logic into easily understood and hence maintainable sub-units. Each sub-unit can then have its own set of unit tests, and there can be well defined and strictly imposed interfaces between the sub-units, thus restricting the possibility of unexpected use cases invoking undefined behaviour. This approach is independent of program size - i.e. if your project fundamentally requires lots of logic then 'make it concise' doesn't work at the project level, but it does work at the component level. – redcalx Jul 24 '15 at 10:59
  • @redcalx: sounds you already know the answer to your question. If you need a good example of how to split a large XSLT program into smaller subunits, look at the docbook stylesheets [http://sourceforge.net/projects/docbook/]. – Doc Brown Jul 24 '15 at 12:21
  • I asked the question because I'm unfamiliar with XSLT and conventions around it's use. I been seeing large and, what look to me to be, monolithic XSLT files in codebases that were otherwise relatively well structured. Hence I was wondering if (A) I was misreading the situation (i.e. they are actually well structured XSLTs), or (B) maybe there was something about the technology that was causing lack of good structure. – redcalx Jul 24 '15 at 12:39
  • @redcalx correct, and like Doc says you seem to have the tools to answer your own question already. –  Jul 24 '15 at 13:39
  • Apart from my immediate research needs I would also hope that the question (+answers) acts as a reference source for others (and future me!). – redcalx Jul 24 '15 at 13:53

0 Answers0