The Spartanizer

Authors: Yossi Gil and Matteo Orrù, Technion, Israel

Editors: Nikolaos Tsantalis (@NikosTsantalis), Mei Nagappan (@meinagappan)

In this post, we would like to tell you about the Spartanizer, an automatic software-engineering tool developed at the Technion, that helps you code in the “Spartan Programming Style” that means that a programmer phrases his code’s statements in the same way a person of Laconia phrases his statements of speech:

saying the most in a few, clear words.

For example, the Spartanizer takes some verbose piece of code such as

public static String getCurrentLanguage() {   String language;   if (getBooleanProperty("lang.usedefaultlocale"))     { language = Locale.getDefault().getLanguage();     }     else     { language = getProperty("lang.current", "en");     }   return language; }

Figure 1: An example taken from jEdit

(found in the Jedit project), and converts it  into the concise spartan form;

public static String getCurrentLanguage() {  return getBooleanProperty("lang.usedefaultlocale")            ? Locale.getDefault().getLanguage()            : getProperty("lang.current", "en"); }

Figure 2: The spartanized code of Figure 1

Transformations made by the Spartanizer are too many (currently over 150) to enumerate here; their main kinds are compile time evaluation when possible, elimination of dead code, simplification of boolean expressions, removing syntactic baggage such as superfluous call to super(), short-circuiting and early returns, identifying cases in which a for should have been used instead of a while, using standard short names whenever this makes sense.  A frequently recurring theme is refactorings inspired by the distributive rules of arithmetic, ab+ac⇒a(b+c) and ba+ca⇒(b+c)a i.e., identifying a common factor of two

syntactical elements and rewriting it in equivalent way with this common factor occurring only once. The Spartanizer is thus able to unite two adjacent conditionals, factor out commonalities of the two branches of a conditional. Yet another kind of refactorings carried out by the spartanizer are applying programming idioms whenever appropriate, e.g., following fluent API programming style.

The code generated by the Spartanizer is concise, and often looks more functional than imperative, and may need some getting used to conventions. Yet, our experience in teaching spartanization, and applying it in student and non-student projects, including several projects with a couple of hundreds of classes each, shows that after adjustment period is short, and programmers tend to prefer minimal ink to verbosity, as long as the minimal like is regular, i.e., follows a small set of recurring patterns. An empirical study [1] shows that the spartanization of code makes it measurably more predictable.

Spartanized code has unique lean appearance: few statements, minimal number of intermediates, adherence to idioms, use of conditional expressions (and in recent versions Java streams) rather than explicit, general purpose, control such as if, else, while, and for. In fact, spartanized code often assumes the concise and elegant looks of functional programs, even though the original version of the code was purely imperative. For example, this function  for comparing two lists of nodes  (drawn from the Spartanizer’s implementation) was created  automatically from its imperative version.

<N extends ASTNode> boolean same(final List<N> ns1, final List<N> ns2) {   return ns1 == ns2 ||     ns1.size() == ns2.size() &&        range.from(0).to(ns1.size())        .stream()        .allMatch(λ -> same(ns1.get(λ), ns2.get(λ)));  }

Figure 3: An example of spartanized code taken from the Spartanizer project

Conversion can be done either interactively, or in batch form. The Spartanizer features an Eclipse plugin, which offers “spartanization” tips to the programmer. The programmer will reach the concise form by following the six tips offered by the Spartanizer to the jEdit function in Figure  Figure. Unlike many code analysis and code generation tools, the conversion from the verbose to the concise is continuous: one little change at a time. An experimental feature in the Spartanizer, available from version 2.8 is capable of doing the opposite conversion, from the concise to the verbose, making it possible for the programmer to use the mouse wheel for both zooming in and zooming out the code.

Alternatively, spartanization can be done in batch application. Unlike many deep analysis tools automatic spartanization is fast, with more than five thousand tips per minute on a contemporary computer.  Like other refactoring tools, the Spartanizer is optimistic, making e.g. some assumptions on the use of overloading, or that the order of evaluation of arguments to a function is immaterial to correctness.

Internally, the Spartanizer follows this extensible modular structure: spartanization tips are generated by small software modules, called tippers. Each of these generate its own kind of spartanization tips. Tippers are applied automatically or interactively by tip applicators, which apply automatic spartanization to user selected portions of the code (function, class, file or project).

The Spartanizer is available at the Eclipse marketplace, and open source on GitHub.

References

[1] Y. Gil and M. Orrú, “Code Spartanization,” in Proc. of SAC’17, the 32nd ACM Symposium on Applied Computing, Marrakesh, Morocco, April 3–7 2017.

[2] Y. Gil and M. Orrú, “The Spartanizer: Massive Automatic Refactoring,” in Proc. of 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering, Klagenfurt Austria, February 20-24, 2017.

[3] The Spartanizer at the Eclipse Marketplace. https://marketplace.eclipse.org/content/spartan-refactoring-0

[4] The Spartanizer on GitHub: https://github.com/SpartanRefactoring/Spartanizer

[5] The Spartanizer website: http://spartan.org.il/

[6] The Spartanizer wiki: https://github.com/SpartanRefactoring/Spartanizer/wiki