Software Design Quiz (TypeScript)

We believe that learning just a few principles can take you to a state where murky decisions become obvious, designs become clear, debugging becomes easy, and coding is a joy.

And we want that for you.

May this quiz be your first step.

Enjoy.

As part of a large application, you are reading an input and need to escape all single quotes. Which of these two options is better and why? Assume both do the exact same thing.

Option 1: x = sanitize(readInput());
Option 2: x = readInput().replaceAll("'", "\\'");

Multiple benefits of your preferred option may apply. Choose the best answer.

A) Option 1 because it’s shorter

B) Option 1 because option 2 is just plain incorrect, even though it always works

C) Option 2 because it’s more clear what it does

D) Option 2 because it’s more efficient, avoiding the function call overhead

Discussion:

See question

As part of a large application, you are reading an input and need to sanitize it by escaping all single quotes. Which of these two options is better and why? Assume both do the exact same thing.

Option 1: x = sanitize(readInput());
Option 2: x = readInput().replaceAll("'", "\\'");

Multiple benefits of your preferred option may apply. Choose the best answer.

A) Option 1 because it’s shorter

B) Option 1 because option 2 is just plain incorrect, even though it always works

C) Option 2 because it’s more clear what it does

D) Option 2 because it’s more efficient, avoiding the function call overhead

You might have had the reaction “How could something that always works be incorrect?” This is actually part of a very important concept which goes back at least to 1967: that of treating the guarantees of what a function must do as a different entity from what it actually does. One Googler told us that he considers understanding this as the dividing line between a junior and a senior engineer. This idea can be called “the implementation/interface distinction,” although that term is often used for a more elementary concept. There are other reasons to prefer Option 1, but it’s hard to beat “Option 2 is literally incorrect” for strength.

To explain this: There’s actually another instance of this idea which is much more widely taught, and we’ll start by drawing a connection there. In systems programming, the low-level C API used to write to the console is invoked like this: write(1,str,len). Here, write is a function that writes to a stream, and 1 is a constant that refers to stdout, the stream that by default writes to the console. Beginning programmers are taught to “not use magic numbers” and instead write write(stdout,str,len). The justification is that the definition stdout == 1 is a low-level implementation detail which is secret to another module. It should be possible to read and write this code without knowing that detail, and the code should still work even if that detail changes.

Another way to say that is that the code write(1,str,len) is incorrect as written, because it is not possible to know that it works without making assumptions about the rest of the system. The idea of the number 1 and the idea of the stream stdout are different, even though they are the same in implementation.

Back to the original question: the idea of a sanitized string and the idea of a string with all single quotes removed are different, even though they are the same in implementation. It is thus not possible to know that Option 2 actually sanitizes the string without knowing this detail. And this detail is far more likely to change than that stdout == 1, which actually is required by the POSIX standard.

At this point, the question of whether Option 2 is incorrect reduces to whether the exact format of sanitized strings should be considered secret to its module. But this is the case in nearly all contexts, for not doing so makes the program very hard to change, especially as the details of sanitization are referenced in ever-more places throughout the program.

This example comes from Jimmy’s Strange Loop Talk “You are a Program Synthesizer”, which spends significant time explaining this example and why programming languages for formal verification would actually give a compile error for Option 2. We explain the ideas more in the Advanced Software Design Web Course, as parts of the lessons on “the hidden layer of logic” and on secrets. But the concept behind this example is as old as programming.

Option 1 is not better in every way: Option 2 is clearer about what it does. It is a general fact that hiding information tends to make applications easier to change but harder to understand, a tension we term “The Information Hiding Dilemma.” But this is a case where the tradeoff swings very strongly towards hiding the information: the definition of sanitization is very easy to understand even with the indirection, details about sanitization can spread throughout the codebase in nasty subtle ways if it’s not hidden (as shown in the Strange Loop talk), and the problem description states this is a large application.

Consider this Rectangle type as you might find in a GUI framework.

class Rectangle {
  constructor(
    private x: number,
    private y: number,
    private width: number,
    private height: number
  ) {}
  getArea(): number {
    return this.width * this.height;
  }
  getPerimeter(): number {
    return 2 * (this.width + this.height);
  }
}

Which of the following is mostly likely to be a design improvement to this class?

A) The constructor should take two parameters, not four

B) The application should pass around arrays of integers instead of the Rectangle type to avoid the overhead of classes

C) Rectangle should be made to be an implementation of an IRectangle interface

D) The class should cache the area and perimeter instead of computing them anew each time

Discussion

See question

Consider this Rectangle type as you might find in a GUI framework.

class Rectangle {
  constructor(
    private x: number,
    private y: number,
    private width: number,
    private height: number
  ) {}
  getArea(): number {
    return this.width * this.height;
  }
  getPerimeter(): number {
    return 2 * (this.width + this.height);
  }
}

Which of the following is mostly likely to be a design improvement to this class?

A) The constructor should take two parameters, not four

B) The application should pass around arrays of integers instead of the Rectangle type to avoid the overhead of classes

C) Rectangle should be made to be an implementation of an IRectangle interface

D) The class should cache the area and perimeter instead of computing them anew each time

This question mostly rests on comparing one thing which is definitely a design improvement to the trained eye with several contenders whose benefits are more mixed or negative.

(A) is the correct answer. The current constructor API is flawed. For two reasons, it should instead take a Point and a Dimension, being called like newRectangle(point(x,y), dim(width,height)). The other answers are tempting but have far weaker support, and we shall discuss them below.

The first reason is that it fails what’s called The Plain English Test. Suppose you were to describe what a Rectangle is in plain English. When we’ve asked people to describe what data defines a rectangle, almost none have answered 4 integers; they are far more likely to say that it consists of the top left corner and its dimension. Changing the constructor to instead take a point and dimension brings the code closer to the level of thought.

Secondly, the current API invites misuse. With 4 integers in a row, the constructor allows for 24 possible argument orderings, 23 of which are incorrect. While most of these, like newRectangle(height,y,x,width), would look strange to many programmers, the incorrect call newRectangle(width,height,x,y) could very easily pass code review. Having it take a Point and Dimension turns such a mistake into a type error. Another approach is to use keyword arguments in languages that have them, although the Plain English Test still gives weight to the two-argument constructor.

The Plain English Test is a consequence of the Embedded Design Principle, which is the focus of Unit 2 of the Advanced Software Design Course. The issue of argument ordering is an instance of the Representable/Valid Principle, the subject of Unit 3.

Discussion of other answers

C is not “the most likely to be a design improvement,” because most of the methods of the Rectangle type have only one reasonable implementation (except for internal details like caching), so that there is very unlikely to be a need for multiple Rectangle implementations. At best, this would be premature optimization, as the switch to a separate rectangle interface can happen later. And if the interface is just called Rectangle, then Rectangle-using code need not be touched.

D might look like a performance-saver, but whether it actually saves cycles depends on quite a few factors: the higher-level issue of how often these functions are used, and the super-low-level issues of cache alignment and instruction scheduling. It should not be adopted without either serious knowledge of CPU architecture or (more likely) serious profiling, as there’s a fair chance that the extra space and memory operations it requires would outweigh the gains from avoiding the arithmetic. Even if the proposed alternative is more performant, by many definitions (D) is still not a design issue, as the change can be implemented at any time without changing the API of Rectangle.

(B) is the second best answer. Adopting (B) comes with a significant maintainability cost: working with raw integer arrays is much less convenient, and makes the rest of the code more error-prone. This tradeoff could be worthwhile in some performance intensive applications like games, but even many game engines such as Unity provide a Rect type. And classes can still save space by using primitive integers for rectangles internally but a Rectangle class in the APIs, as is done in OpenJDK. Note, by the way, that this tradeoff does not exist in languages such as C++ and Rust, which can represent a Rectangle type without overhead.

Extra Discussion

Q: Wouldn’t you want to make the Rectangle class more general and instead have it defined by things that could also be used for other shapes?

A: Even if the representation is different, taking either a point and a 2D dimension or two points is still a good API for the Rectangle constructor, and so (a) is still the best of the 4 answers. That aside, you actually probably would not want to aggressively generalize rectangle operations to work with other shapes because rectangles are special in GUI frameworks. As a quick demonstration: open up the Chrome or Firefox debug inspector and highlight any element. It will show you the bounds for the element and the bounds for the element with its margin. These are always rectangles, even if the element is a different shape.

Q: But shouldn’t it be three parameters: there is likely to be an existing type for points, but not dimensions, so it should take in a point, a width, and height, right?

A: The question only asks for the best answer out of four choices, so if you think that there should be three parameters, then you probably agree the suggestion to use two is the best of the four options. Nonetheless, here are some reasons to prefer using a separate Dimension type. First, as mentioned above, rectangles are special in GUI frameworks, so that such a dimension type already exists. Here it is for Java’s included GUI frameworks, AWT and Swing. And here’s the equivalent for the iOS GUI library. Second, as mentioned earlier, empirically programmers do think of dimensions as a separate concept, which motivates capturing them as a separate type.

Here is a snippet of code you might find in an ecommerce website. Think about what you would do to generally improve this code without changing the behavior.

public setProductDisplayType(displayType: string): void {
    if (displayType === "compact") {
        this.maxDescriptionLength = 140;
        this.numSimilarProductsToShow = 2;
        this.numReviewsToShow = 1;
    } else if (displayType === "detailed") {
        this.maxDescriptionLength = 500;
        this.numSimilarProductsToShow = 5;
        this.numReviewsToShow = 7;
    }
}

Try to think of the best refactoring yourself before looking at the answers. We are deliberately not showing you full detail in the answers below, for fear that showing you the possible solutions would make this question too easy. But if you can think up the best refactoring, then it should be clear which of the answers below is the best match.

A) The best refactored version does the equivalent of looking up a COMPACT_PRODUCT_WIDTH in a hardcoded global hash table

B) The best refactored version contains some form of the triple (140, 2, 1)

C) The best refactored version replaces the hardcoded strings with constants `COMPACT` and `DETAILED`, defined either as String constants or as an enum

D) The best refactored version uses a switch statement instead of an if-statement

Discussion:

See question

Here is a snippet of code you might find in an ecommerce website. Think about what you would do to generally improve this code without changing the behavior.

public setProductDisplayType(displayType: string): void {
    if (displayType === "compact") {
        this.maxDescriptionLength = 140;
        this.numSimilarProductsToShow = 2;
        this.numReviewsToShow = 1;
    } else if (displayType === "detailed") {
        this.maxDescriptionLength = 500;
        this.numSimilarProductsToShow = 5;
        this.numReviewsToShow = 7;
    }
}

Try to think of the best refactoring yourself before looking at the answers. We are deliberately not showing you full detail in the answers below, for fear that showing you the possible solutions would make this question too easy. But if you can think up the best refactoring, then it should be clear which of the answers below is the best match.

A) The best refactored version does the equivalent of looking up a COMPACT_PRODUCT_WIDTH in a hardcoded global hash table

B) The best refactored version contains some form of the triple (140, 2, 1)

C) The best refactored version replaces the hardcoded strings with constants `COMPACT` and `DETAILED`, defined either as String constants or as an enum

D) The best refactored version uses a switch statement instead of an if-statement

Fundamentally, the function needs to output either the three numbers (140, 2, 1) or the three numbers (500, 5, 7). While there are many superficially-different variants, there really aren’t that many ways to do this.

Here is example code for the best refactoring, which corresponds to Answer B. There are minor variations, but the key idea is to pass around a structure containing all the values for a configuration. You can click on the expandable bullets below to look at the code for the other answers.

public static COMPACT: ProductDisplayType = new ProductDisplayType(140, 2, 1);
public static DETAILED: ProductDisplayType = new ProductDisplayType(500, 5, 6);
public setProductDisplayType(displayType: ProductDisplayType): void {
  this.maxDescriptionLength = displayType.maxDescriptionLength;
  this.numSimilarProductsToShow = displayType.numSimilarProductsToShow;
  this.numReviewsToShow = displayType.numReviewsToShow;
}

Example code for Answer A

public setProductDisplayType(displayType: string): void {
  this.maxDescriptionLength = productDisplayTypeDescriptionLengths.get(displayType);
  this.numSimilarProductsToShow = productDisplayTypeNumSimilarProducts.get(displayType);
  this.numReviewsToShow = productDisplayTypeNumReviews.get(displayType);
}

Example code for Answer C

enum ProductDisplayType {
    COMPACT,
    DETAILED
}
public setProductDisplayType(displayType: ProductDisplayType): void {
    if (displayType === ProductDisplayType.COMPACT) {
      this.maxDescriptionLength = 140;
      this.numSimilarProductsToShow = 2;
      this.numReviewsToShow = 1;
    } else if (displayType === ProductDisplayType.DETAILED) {
      this.maxDescriptionLength = 500;
      this.numSimilarProductsToShow = 5;
      this.numReviewsToShow = 7;
    }
}

Example code for Answer D

public setProductDisplayType(displayType: string): void {
  switch (displayType) {
    case "compact":
      this.maxDescriptionLength = 140;
      this.numSimilarProductsToShow = 2;
      this.numReviewsToShow = 1;
      break;
    case "detailed":
      this.maxDescriptionLength = 500;
      this.numSimilarProductsToShow = 5;
      this.numReviewsToShow = 7;
      break;
  }
}

Looking at the code for the other solutions, it’s easy to explain why Answer B is better in nearly every way.

First, the disadvantages of the others: Option D is the easiest to eliminate because it is nearly identical to the original, as a switch statement and an if-else statement are both variants of the idea of a conditional. The switch statement will be marginally easier to extend if new options are added other than compact and detailed, but otherwise, it only has the disadvantages of being slightly longer.

The enum option, Answer C, is similar but marginally better. Fundamentally, the function before could take in one of two values, “compact” or “detailed”, and then conditionally branched over them. With this change, it is the exact same, except the values are now called COMPACT and DETAILED instead. The interface is more type-safe, however.

Answer A makes the code straight-line instead of conditional, at least superficially. It also makes it much easier to do the possible future work of making the product display type settings configurable and extensible. However, in a sense, it doesn’t actually eliminate the conditional, because if you were to describe what it does, you would still need to say “It sets the configuration to these values for ‘compact,’ and these other values for ‘detailed.’”

Answer B dominates. It has all the type-safety of Answer B, more brevity than Answer A, and shares the configurability-and-extensibility benefit of Answer A. And it is competitive with the other answers in how easy it is to see the range of possible values for the three variables being set; whether it’s better or worse depends on extra details such as code placement.

However, its greatest advantage is that it is the only solution that truly eliminates the conditional, making the function both shorter and simpler.

There are still a few marginal improvements that can be made on top of this. For instance, if you did this example in a different language that has keyword arguments, it may be beneficial to use them in the ProductDisplayType constructor. But introducing this data structure is the key ingredient in improving this code.

There are tools and techniques from programming language theory that let you look at code like this and come up with the main ways for changing it, so that you can pick the best refactoring without depending on creativity. We teach this focused subset of PL theory in Unit 5 of the Advanced Software Design Course, “Algebraic Refactoring.” There’s a similar example to Answer A in Jimmy’s Strange Loop talk that uses PL theory to explain why it’s still conditional, and this is covered more in one of the first exercises of our Advanced Software Design Course. Also check out this article where we give a detailed discussion of how to truly remove conditionals from code.

Extra discussion

Q: But doesn’t answer B best refactoring still contain a conditional, since the calling code must determine whether to pass in COMPACT or DETAILED

A: If the caller previously stored “compact” as a String, it would now store it as a ProductDisplayType. No conditional necessary.

But then you could say that the caller’s caller needs to have the conditional. So you would also change the caller’s caller to store a ProductDisplayType rather than a string.

This process repeats until the original source of the string “compact” is changed to instead provide a ProductDisplayType, and the conditional is truly eliminated.

This is one of the two techniques for truly eliminating a conditional: moving the conditional to a place in the code where the branch is already known.

Consider the following code that you might find in a blog or news website.

class Post {
  private comments: Comment[];
  constructor(
    private id: number,
    private content: string,
    private author: string,
    comments: Comment[] 
  ) {
    this.comments = [...comments]; // Create a shallow copy of the comments array
  }
  getId(): number { return this.id; }
  getContent(): string { return this.content; }
  setContent(content: string): void { this.content = content; }
  getAuthor(): string { return this.author; }
  getComments(): Comment[] {
    return [...this.comments]; // Return a shallow copy of the comments array
  }
  addComment(c: Comment): void {
    this.comments.push(c);
  }
}

Which of the following proposed changes is most likely to improve the maintainability of this code and the rest of the system? Note that this code may contain other flaws not listed among these choices.

A) The id of a Post should be a hash of its content and author

B) The Post class should not contain a list of Comments

C) The comments list should not be copied

D) The code should not assume that all Posts have authors

Discussion:

See question

Consider the following code that you might find in a blog or news website.

class Post {
  private comments: Comment[];
  constructor(
    private id: number,
    private content: string,
    private author: string,
    comments: Comment[] 
  ) {
    this.comments = [...comments]; // Create a shallow copy of the comments array
  }
  getId(): number { return this.id; }
  getContent(): string { return this.content; }
  setContent(content: string): void { this.content = content; }
  getAuthor(): string { return this.author; }
  getComments(): Comment[] {
    return [...this.comments]; // Return a shallow copy of the comments array
  }
  addComment(c: Comment): void {
    this.comments.push(c);
  }
}

Which of the following proposed changes is most likely to improve the maintainability of this code and the rest of the system? Note that this code may contain other flaws not listed among these choices.

A) The id of a Post should be a hash of its content and author

B) The Post class should not contain a list of Comments

C) The comments list should not be copied

D) The code should not assume that all Posts have authors

This example comes from Daniel Jackson’s book The Essence of Software, endnote 81 (first edition). The rule behind it is only mostly-objective, but that is still enough to make answer B unambiguously the best of the four answers.

That is: Although posts may contain comments, the Post class should have no references to the Comment class, because doing so hinders reusability.

We determine this using a powerful-but-underappreciated rule called the Parnas Subset Criteria, first stated in 1979. This rule requires us to ask: are there useful subsets of the program which contain posts but not comments? The answer to this question is almost certainly yes. Because of that, the Parnas Subset Criteria dictates that the Post class is not allowed to use the Comment class, for that would hinder reusability.

There are multiple possible fixes. One option is to keep the post/comment relation in a relational database, or its in-memory imitation, having an external Post->List<Comment> map. Another is to instead have Post contain a collection of PostAttachment’s, an abstract type whose implementations include Comment's. A third is to instead put a reference to Post’s within Comment’s instead of the reverse. Each of these has their own tradeoffs. Even without considering reusability or future changes, these possible fixes also simplify the code that deals with posts, for this need not be concerned with comments except to the minimal extent that they are attached to posts.

The Parnas Subset Criteria are one of many topics covered in Unit 6 of the Advanced Software Design Course, “Future-Proofing Code.”

Discussion of other answers

(C) is incorrect because not copying the comments list leads to bugs from concurrent modification. It may improve performance, but it creates new ways two pieces of code may interfere with each other, hindering maintainability. This would not raise maintainability concerns in languages where the type system can prevent concurrent modifications, but there are very few languages that have such type systems, namely Rust and a few research languages such as Plaid.

Replacing the id of a post with a hash (prohibiting duplicate posts) would change posts to represent a slightly different concept, but would not improve maintainability. Likewise for removing mandatory authors.

Extra discussion

Q: Isn’t the copying of comments a maintainability issue because the extra memory usage can cause server crashes?

A: Let’s think about this, starting with the lens of what “maintainability” means. Unlike many things in software engineering, there actually seems to be pretty widespread agreement about what “maintenance” means. E.g.: according to Wikipedia, “Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.” There is in particular universal agreement that “maintenance” refers to modification of the system (as opposed to, say, how often servers need to be rebooted), from which it follows that the term “maintainability” specifically refers to ability to change the code or infrastructure.

Through this lens, the only maintainability concern of copying the comments list is the difficulty of modifying the code to not do this in the event that the resource consumption becomes an issue. (Note also that the actual resource usage is likely to be low, as only references to the comments are copied, not the comments themselves.) This is an extremely easy change. The reverse, however, is not true in case any code improperly relies on concurrent modifications to the comments list. (Which, if used enough, it will be; see Hyrum’s Law.)

Following is code you might find in a distributed system. A digest in this context is a hash of information relating to the cluster.

This function is used to simultaneously compare an unordered set of objects (files, messages, etc) against a checksum. It first combines the digests of each object by taking their XOR, and then compares the result to the target checksum, also using XOR. Note that, while there are many disadvantages to using XOR as a digest, this example is adapted from a real codebase where those were deemed not important.

function compareDigestsToTarget(digests: number[], target: number): boolean {
  let combinedDigest = 0;
  for (const curDigest of digests) {
    combinedDigest = combinedDigest ^ curDigest;
  }
  const difference = combinedDigest ^ target;
  return difference === 0;
}

Choose the best of the following proposed code improvements. There may be other useful improvements not named.

A) The `target` parameter should be merged into the digests[], so that line 8 can be removed

B) The code should be optimized to have one less loop iteration, initializing combinedDigest to digest[0]

C) The two uses of the XOR (^) operator should be extracted into a function

D) The two uses of the XOR (^) operator should be extracted into two different functions

Discussion:

See question

Following is code you might find in a distributed system. A digest in this context is a hash of information relating to the cluster.

This function is used to simultaneously compare an unordered set of objects (files, messages, etc) against a checksum. It first combines the digests of each object by taking their XOR, and then compares the result to the target checksum, also using XOR. Note that, while there are many disadvantages to using XOR as a digest, this example is adapted from a real codebase where those were deemed not important.

function compareDigestsToTarget(digests: number[], target: number): boolean {
  let combinedDigest = 0;
  for (const curDigest of digests) {
    combinedDigest = combinedDigest ^ curDigest;
  }
  const difference = combinedDigest ^ target;
  return difference === 0;
}

Choose the best of the following proposed code improvements. There may be other useful improvements not named.

A) The `target` parameter should be merged into the digests[], so that line 8 can be removed

B) The code should be optimized to have one less loop iteration, initializing combinedDigest to digest[0]

C) The two uses of the XOR (^) operator should be extracted into a function

D) The two uses of the XOR (^) operator should be extracted into two different functions

In our Advanced Software Design Course, we challenge students to come up with examples of two code snippets with identical implementations that nonetheless should not be merged, because their specifications are incompatible. One student, whose company builds messaging infrastructure, submitted this real example from their codebase:

/* returns a ClusterDigest object containing the differences (i.e. bitwise xor)
 * between two digests for the same cluster segment */
compare(other: ClusterDigest): ClusterDigest {
  return new ClusterDigest(this.digest ^ other.digest);
}
 
/* Merge two digests for different cluster segments (using bitwise xor) to produce a
 * new digest for the union of the two cluster segments */
merge(other: ClusterDigest): ClusterDigest {
  return new ClusterDigest(this.digest ^ other.digest);
}

This question is based directly on that example, featuring a (somewhat contrived) function that uses both operations.

This challenge rests on two questions. First, should the uses of XOR be extracted into a function at all? Second, if so, should it be the same function?

To understand why they should be extracted to a function, we employ the Embedded Design Principle. It works like this: The high-level intention of the code on line 5 is to combine two digests. It is a low level detail that the method of combining them is through the XOR. Likewise, the high-level intention of the code on line 8 is to take the difference of two digests, with its implementation via XOR a low-level detail. Compared to writing combineDigests(combinedDigest,curDigest) or digestDifference(combinedDigest,target), writing lines 5 and 8 requires more thought and knowledge. It requires more thinking to read these lines and reconstruct the high-level intention. And, as written, these lines must change if either the implementation of differencing or combining digests changes. The Embedded Design Principle states the programmer should do less thinking to write this code by using a function instead.

The above discussion also strongly implies that the extracted functions for line 5 and 8 should be different because they have different high-level intentions. Elaborating on this more: it should be possible to give a spec to the combineDigests function “returns a digest combining the two arguments” without stating what it means to combine them, and likewise for digestDifference. It follows that the two functions may evolve differently, i.e.: you may change what it means to combine two digests without changing what it means to difference them, and in that case the functions will need to be split. Doing so requires inspecting every usage of this combined function to determine whether that usage is for a combine or difference operation.

In short, because these two functions have different descriptions of what they do, they should remain separate even though their implementations are identical. Case in point: what would you call the combined function? It is hard to give a name more descriptive than xorDigests, at which point the function adds nothing over just using the XOR operation inline.

The Embedded Design Principle is the subject of Unit 2 of the Advanced Software Design Course. The lens of specifications is used all throughout the course, but is introduced in Unit 1, “The Hidden Layer of Logic.” The idea that two functions with identical implementations but different specs should not be deduplicated is presented in The Design of Software is a Thing Apart.

Discussion of other answers

With the above discussion, we can now explain why the other two choices are poor. With (A), line 5 becomes complicated to describe: it should be seen as either combining or differencing the digests depending on the position in the loop. It also makes the description of the array more complicated, as it now contains two unlike things, and callers will need to do extra work to accommodate this unnatural parameter. (B) is very easy to rule out: with that change, the code no longer works for an empty list of digests.

There are arguments that, if the codebase is very small and this is the only code involving digests, none of the proposed changes should be made. But that is unlikely for the provided context that this is a distributed system, and, in any case, it is clear from the above that (D) is the best improvement.

Click Submit for results