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.

closed as primarily opinion-based by jwenting, user40980, durron597, user22815, GlenH7 Jul 24 '15 at 21:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    The working draft for XSL Transformations (XSLT) Version 3.0 states that 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. – user22815 Jul 24 '15 at 3: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 [sourceforge.net/projects/docbook/]. – Doc Brown Jul 24 '15 at 12:21

Browse other questions tagged or ask your own question.