In this section, we make the notion of a law smell more precise (3.1), illustrate it via examples (3.2), and develop a taxonomy of law smells that prove particularly problematic in practice (3.3). For conciseness, we refer to the government parties involved in creating legal rules as lawmakers (e.g., parliaments or agencies), to the parties affected by such legal rules as lawtakers (e.g., law firms, companies, and citizens), to people with a legal education as lawyers (e.g., judges, attorneys, and legal scholars), and to the labeled, often nested units of legal texts as elements of law (e.g., Titles, Chapters, Sections, and Subsections of the United States Code).
Definition
A code smell, as understood by Fowler (2018), is “a surface indication that usually corresponds to a deeper problem in the system.”Footnote 4 Making only small changes to this statement, we arrive at our working definition of a law smell:
Definition 1
(Law Smell) A law smell is a surface indication that usually corresponds to a deeper problem in a legal system.
To clarify what this means, we highlight the most important building blocks of our definition.Footnote 5 First, a law smell is a surface indication: It can be easily identified, perhaps algorithmically, from the words and the structure of a legal text— even with very limited semantic knowledge. Second, the problem indicated by a law smell concerns a legal system, which—regardless of how exactly we define itFootnote 6 — goes beyond the body of rules in which the problem is identified (for example, a smell discovered in the text of a regulation can indicate a problem in the statute-making process). Third, the indicated problem is a deeper problem, that is, an aspect of the design of a legal system that affects its usability for at least one of its stakeholders— e.g., by making it harder to maintain (for lawmakers) or to navigate (for lawtakers). Finally, a law smell only usually indicates a problem, i.e., upon closer inspection, it can turn out to be harmless or even necessary, given the legal rules that need to be expressed. From a practical perspective, law smells can tell us where we should look to improve the legal system (as lawmakers) or where we should pay extra caution (as lawtakers).
So far, we have defined law smells in terms of their form and their consequences. To capture their content, we propose to characterize each law smell systematically, using the five categories laid out in Table 1. We refer to the resulting overview as a law smell profile. For a given law smell, a law smell profile sketches (1) what the law smell is and (2) why it is problematic. It summarizes (3) how we might detect the smell and (4) how we might mitigate it, and gives (5) at least one illustrative example.
Table 1 Categories used in a law smell profile Examples
We now introduce some particularly intuitive example law smells, which will accompany us throughout the paper. To maximize comprehensibility for readers with computer science or legal backgrounds, we choose law smells that can be derived both via adaptation of the code smells known from the software engineering literature (e.g. Fowler 2018) and by appealing to the intuition and experience of lawyers. As the primary objective is to build intuition, our discussion is deliberately brief, and we detail the structured profiles of our example law smells in the Supplementary Information. We provide a broader view of the law smell landscape in Sect. 3.3, elaborate on the critical question of law smell detection in Sect. 4, and assess the practical prevalence of our example smells in Sect. 5.
Duplicated phrase
Duplicated phrase is the legal equivalent of the software engineering code smell duplicated code. Lawyers smell it when they get the feeling that a text is verbose and repetitive. More formally, a duplicated phrase is a phrase above a specified length that has more than a specified number of occurrences in a legal text. Here, we construe “phrase” broadly and allow phrases to have parameters. That is, a phrase is a nonempty sequence of terms, where a term is either a token (i.e., a sequence of non-whitespace characters roughly corresponding to a word) or a placeholder for an argument that is itself a phrase (e.g., “not later than {period} after {date}”).
Duplicated phrases are problematic because they increase the risk of inconsistencies introduced by incomplete edits, and because they communicate legal content inefficiently. We can detect duplicated phrases using scalable variants of n-gram search, possibly after some preprocessing, where, for intuitive results, the length and occurrence thresholds should be adaptive and inversely correlated— i.e., the longer a phrase, the fewer occurrences should be required for it to qualify as duplicated (see Sect. 4.3.1 for details). To eliminate duplicated phrases, we can introduce and rigorously reuse named variables and definitions.
Long element
Long element is a legal adaptation of the software engineering code smell long function. Lawyers smell it when they get lost in the text they are reading or have trouble discerning those parts of the text that are relevant to them. More formally, a long element is an element of law containing text that is long as assessed by some absolute or relative measure (e.g., its number of tokens or its quantile in a token length distribution). Long elements are problematic because they may indicate a lack of structure or abstraction in the legal text, making the law both harder to read and more complicated to maintain. We can detect long elements using domain-specific adaptations of outlier detection methods (see Sect. 4.3.2 for details). To eliminate long elements, we can move some of their text to other (preexisting or newly created) elements or rewrite the text itself, e.g., by applying mitigation strategies for other law smells.
Ambiguous syntax
Ambiguous syntax is a legal adaptation of the software engineering code smell mysterious name, with pinches of repeated switches and speculative generality. Lawyers smell it, inter alia, when they litigate over the meaning of commas or argue about whether an or is inclusive or exclusive. More formally, ambiguous syntax is the use of logical operators (e.g., and, or, and no(t)), control flow operators (e.g., if, else, and while), or punctuation (e.g., commas and semicolons) in a way that leaves room for interpretation. Ambiguous syntax is problematic because it creates legal uncertainty, which is often removed through costly lawsuits and sometimes leads lawmakers to adopt mathematically redundant syntax like and/or.Footnote 7 We can detect instances of potentially ambiguous or mathematically redundant syntax using pattern matching with regular expressions (see Sect. 4.3.3 for details). To eliminate truly ambiguous instances, logical operators can be used with their mathematical meaning, xor can be introduced as a shorthand for the exclusive or (reserving or for the cases with inclusive meaning), and brackets can be added as syntax (e.g., to clarify operator binding).
Large reference tree
Large reference tree is a legal adaptation of the software engineering code smell message chain. Lawyers smell it when they find themselves following many references to understand the full meaning of the text they were originally interested in. More formally, a reference tree rooted at an element of law r is a tuple \(T_r = (V_r, E_r)\), where \(V_r\) is the set of elements of law reachable from r by following references (including r), and \(E_r\) is a minimal set of edges (references), which is generally not unique, such that each element of \(V_r\) can be reached from r. To illustrate this definition, a sample reference tree is depicted in Fig 1. A large reference tree is a reference tree whose edge set exceeds a given size x, which represents the largest acceptable number of references that we must follow to fully understand the content of a root element. The simplest case of a large reference tree is a long reference chain. Large reference trees are problematic because they increase the cognitive load involved in navigating legal texts, and they raise the risk of unintended normative side effects when elements deep in the tree hierarchy are changed. We can detect large reference trees using domain-specific adaptations of graph traversal algorithms (see Sect. 4.3.4 for details). To eliminate large reference trees, we can restructure the texts and references contained in its elements, and we can make all references as specific as possible.
Natural language obsession
Natural language obsession is a legal adaptation of the software engineering code smell primitive obsession. Lawyers smell it, inter alia, when they are interested in the law related to a specific named entity (e.g., a committee of the United States Senate), or when they try to automate their clients’ compliance. More formally, natural language obsession is the representation of typed data as natural language text, often without a standardized format. It is problematic because typed data is notoriously hard to extract or maintain when represented using (inconsistently formatted) natural language. We can detect natural language obsession using Named Entity Recognition methods (including methods as simple as pattern matching with regular expressions), potentially augmented or validated by techniques detecting duplicated phrases (see Sect. 4.3.5 for details). To eliminate natural language obsession, we can create a data layer that is separate from the text (representation) layer, use strong types for named entities, and associate type checking, highlighting, and data analysis rules with the introduced types.
Taxonomy
We now abstract and expand the ideas introduced above into a taxonomy of law smells. To this end, we first derive the necessary distinctions and then give more details on ten additional smells that we position within the resulting taxonomy. This taxonomy is not meant to be exhaustive. Rather, our goal is to provide a starting point for conceptual and empirical validation, discussion, and further refinement.
Distinctions
To develop our taxonomy, we observe some commonalities and differences between the exemplary law smells introduced in Sect. 3.2.
First, all of the law smells from Sect. 3.2 can be sniffed from the text only (in programming language parlance: they can be detected at compile time; in legal theory parlance: they concern law in books), but there might also be law smells that can only be detected when the law is used (i.e., at runtime, concerning law in action). Thus, we distinguish static and dynamic law smells.
Second, we find that the duplicated phrase and natural language obsession smells are strongly related to the content of legal rules, i.e., the data of the law, while the ambiguous syntax smell is related to how this content is expressed, i.e., the grammar of the law, and the long element and large reference tree smells relate to how the legal content is organized, i.e., the structure of the law. Consequently, we differentiate between data-related, grammar-related, and structure-related law smells. Note that since grammar-related law smells are generally static, there is no need for this category in the dynamic setting. Instead, we require an additional dynamic category, called relevance-related, to gather smells related to elements of law with limited overall utility (including, but not limited to, legal cleaning, i.e., identifying and removing elements of law that are no longer relevant).
Third, while long element (when measured in absolute terms, on which we focus here), ambiguous syntax, and natural language obsession can often be detected by looking at a single element of the law, duplicated phrase and large reference tree (as well as long element when measured in relative terms) mostly require looking at multiple elements of law together. Therefore, we further distinguish local (i.e., locally detectable) and non-local (i.e., locally undetectable) law smells.
Table 2 summarizes the distinctions just introduced, and Figure 2 gives an overview of the resulting taxonomy. Figure 2 also contains ten new law smells in addition to those already classified above, thus painting a more complete picture of the law smell landscape we envisage.
Table 2 Overview of distinctions used in the law smell taxonomy
Details
We now elaborate on the new law smells from Fig. 2. Of these smells, five are static and five are dynamic, and we discuss them in the order in which they occur in Fig. 2.
Long requirements list, a legal adaptation of the software engineering code smell long parameter list, is a static law smell describing the situation in which a stated legal consequence only applies given a large number of preconditions. As preconditions might have their own preconditions to be resolved recursively, computer scientists may think of the setting as a search tree whose initial branches need to be expanded until we have either a negative answer on one branch or positive answers on all branches. The efficient lawyer’s task is to pick, using their legal intuition and the facts of an individual case, an expansion order that minimizes the number of search nodes to be expanded. This can only work if they can retain at least the initial preconditions in short-term memory, and therefore, the cognitive load imposed by these preconditions should not exceed the average lawyer’s—if not the average lawtaker’s— short-term retention capacity. Although the precise measurement of short-term memory is still debated in cognitive psychology, for the purposes of flagging long requirements lists, we can still use a conservative maximum number of requirements x as a heuristic. To shorten long requirements lists, lawmakers can introduce new concepts bundling requirements that cooccur frequently.
Rule envy, a legal adaptation of the software engineering code smell feature envy, describes a setting in which a legal rule is more closely related to rules from other parts of the law than to the rules with which it is grouped (e.g., the rules in its own section). Typical warning signs that an element of law is affected by rule envy are its extensive (implicit or explicit) references to rules from far-away parts of the law, paired with an absence of (implicit or explicit) references to rules in its immediate neighborhood. Rule envy is problematic because it goes against the rationale that underlies the structuring of law into separate elements: improving its comprehensibility and maintainability by grouping related content together. In theory, rule envy can be mitigated by placing the envious element with the elements it envies. However, in practice, many elements of law rely on legal rules from different places, and consequently, it may not always be clear where an element naturally belongs. Furthermore, some prominent drafting techniques such as index sections deliberately create rule envy, and when used with caution, the gain in navigational efficiency associated with these techniques may outweigh the drawbacks of the resulting law smell.
Failed integration can be conceived as the group-level opposite of rule envy: it refers to a sequence of (mostly lower-level) elements of law that are isolated from the environment in which they are placed— although their position within the structure of the law suggests otherwise. As the train of thought spun in the environment of an affected sequence is interrupted by failed integration, it makes navigating the law unnecessarily difficult. This smell frequently results, e.g., from hasty or unenthusiastic implementation of supranational legal rules into national legal systems (e.g., when the German legislator needs to implement law mandated by the European Union), especially when supranational and national law differ in their legal concepts. As a result, affected sequences often differ from their environment in drafting style and desired interpretation of core terms, which increases, inter alia, the risk of inconsistent enumeration and term overloading (described below). Failed integration can be mitigated by either moving the affected sequence completely out of its environment, i.e., making it into an independent unit of law, or rephrasing its elements for better coherence with its environment.
Complicated logic arises when legal rules contain nested conditionals, switches, or loops, often with elaborate heads including negations. It sometimes cooccurs with long requirements list and frequently results in ambiguous syntax. In legal texts just as in code, humans have trouble parsing complicated logic because it puts significant strain on their mental cache, impairing the usability of the law for both lawmakers and lawtakers. Lawmakers can follow programmers’ mitigation principles to eliminate complicated logic, e.g., they can decompose or consolidate conditionals where possible. In extreme cases, e.g., when lawmakers communicate a table in writing (example: 7 U.S.C. §8732, which details loan rates per unit of crop per crop type and year), the best choice is to use an entirely different structure to present the content (in the example: a table).
Inconsistent enumeration refers to the unstandardized usage of enumeration labels (e.g., large Latin alphabets, small Latin alphabets, Arabic numbers, large Roman numerals, small Roman numerals, etc.) across nesting levels in legal texts (or, more mathematically: the lack of a bijection between enumeration labels and nesting levels). As programming languages use the same syntax at all levels to indicate nesting (e.g., lists are nested simply by using list syntax inside list syntax) or enumeration (e.g., switch-case expressions in some languages), this law smell has no close counterpart in the software engineering code smell literature. Its repercussions, however, could be compared to those of overly lenient XML schema definitions: The affected text becomes hard to parse, be it for humans or machines, because the meaning of an encountered nesting element can only be resolved within a larger context. Lawmakers can mitigate inconsistent enumeration by (legally) mandating a one-to-one mapping between enumeration labels and nesting levels, which is then used consistently across legal documents and can, consequently, be relied upon by all stakeholders.
Term overloading, a legal mixture of the software engineering code smells mysterious name and mutable data, occurs when the same term is used to denote different concepts in different places, either explicitly (explicit namespacing, e.g., using scoping language such as “For the purposes of this section, \(\dots\)”) or implicitly (implicit namespacing, e.g., through jurisprudence). It is classified as a dynamic smell because divergent meanings of the same term often result from the interpretation of legal rules in practice, e.g., by courts. Term overloading increases the cost of navigating the law for lawtakers, as the meaning of a term becomes context-dependent, and the context-applicable meaning becomes accessible only through (often non-local) further reading (explicit namespacing) or background knowledge (implicit namespacing). Additionally, it raises maintenance costs for lawmakers, especially when tasked with applying changes to all instances of a concept labeled by an overloaded term. Term overloading can be mitigated by introducing separate labels for each concept referenced by the overloaded term, and by using strategies similar to those combating natural language obsession.
Divergent change, a legal adaptation of the eponymous software engineering code smell, describes a situation in which the same element of law needs to be changed in different ways for different reasons. For example, an element holding a sequence of generic legal rules is affected by divergent change if in different application contexts, different specific exceptions need to be made to rules contained in different sequence parts, and the lawmaker’s original strategy is to place the exceptions with the generic provisions. Divergent change is a dynamic smell because it can be detected only during maintenance. It indicates that the chosen level of abstraction is inadequate for the affected legal rules, thus pointing to a problem in the structure of the law that may also impair its usability (e.g., the affected element of law may lack conceptual clarity or be hard to navigate). Divergent change can be counteracted by restructuring the code to enforce a clear separation of concerns between application contexts, such that the rules that are truly shared between contexts are separated from the context-specific details.
Shotgun surgery, like the eponymous software engineering code smell, is the opposite of (the legal adaptation of) divergent change. It captures the setting in which one high-level change to the law necessitates many small changes to legal rules in many different parts of the law, and as such, it often indicates natural language obsession. Just as divergent change, shotgun surgery is a dynamic smell because it can only be detected during maintenance. Shotgun surgery is not only slow but also hard for lawmakers to perform consistently (and painful for lawtakers to follow). As a result, conducting shotgun surgery may lead to inconsistencies in the law. This makes future amendments to the law even harder, if not impossible, to perform correctly, and produces unwarranted legal uncertainty (and litigation costs associated with removing that uncertainty) for lawtakers confronted with the resulting inconsistencies. Where it is due to natural language obsession, shotgun surgery can be counteracted by the strategies used to neutralize that smell. Otherwise, close inspection of those parts of the law that are altered by shotgun surgery might yield characteristics that could be abstracted into new concepts or generalized rules for smell mitigation.
An overbroad reference is a reference to a structural element of law that is more general than its use case requires. It is a legal adaptation of the software engineering code smell speculative generality, which we classify as dynamic because the use case requirements of a legal rule often become clear only as it is used in practice. This smell typically manifests in formulations such as “Subject to the provisions of X [related to Y]”, where X is a large structural element of the law, e.g., a Title, a Part, or a Chapter of the United States Code, and Y (if present) is some roughly sketched topic. Overbroad references shift the cost of identifying the relevant referenced material from lawmakers to lawtakers, decreasing efficiency and legal certainty and increasing the probability of errors. Lawmakers can eliminate overbroad references by identifying the applicable legal rules themselves and referencing these rules as precisely as possible. Their need for using overbroad references to hedge against future changes could be diminished by using computational tools to track the dependencies among legal rules.
Lazy element, a legal adaptation of the eponymous software engineering code smell, refers to elements of law that are hardly relevant in practice. It is a dynamic smell because both laziness and non-laziness can develop over time: For example, a legal rule can be relied upon by a lot of other rules when it is first promulgated, but newer rules can gradually supersede it, or it can be completely isolated at the start but then form the basis of many lawsuits or contracts. The most extreme case of lazy elements is dead law: legal rules that are simply not needed (anymore)— e.g., because their preconditions imply that a person needs to have witnessed a certain event that happened x years ago, and x exceeds maximum observed human lifespan. In the absence of systematic compression or cleaning strategies for law (sunset clauses are still a fringe phenomenon), lazy elements cause bloating, and bloated law is frustrating to read and maintain. Lawmakers can eliminate lazy elements by integrating them with their more industrious peers or, if the elements turn out to be dead, removing them entirely (through cleanup acts such as the Rechtsbereinigungsgesetze in Germany).