icon to open the header menu
Aesthetic ideals in programming practices

Ideals of beauty

Following our overview of the varieties of practices and program texts amongst those who read and write source code, we now analyze more thoroughly what are the aesthetic standards most valued by those different groups. The aim here is to formalize our understanding of which source code is considered beautiful, and to do so in a dual approach; capturing both the specific manifestations of beautiful code enunciated by programmers, and identifying the semantic contexts from which these enunciations originate. To do so, we will introduce a discourse analysis framework for the empirical study of the corpus, followed by an examination of the discourses that programmers deploy when it comes to expliciting their aesthetic preferences of source code. What we will see is that, while the aesthetic domains that are mobilized to justify the aesthetic standards are clearly distinct, we can nonetheless identify recurrent sets of aesthetic values and a set of aesthetic manifestations against which the quality of source code can be measured.

Introduction to the Methodology

Discourse consists of text, talk and media, which express ways of knowing, experiencing and valuing the world. This study builds on Kintsch and Van Dijk's work on providing tools to analyze an instance of discourse, and is centered around what is said to constitute good source code. While discourse analysis can also be used critically by unearthing the value judgments, and thus the power relationships, which occur in linguistic exchange ( Mullet, 2018) , we focus here on aesthetic value judgments, as their are first expressed through language. Of all the different approaches to discourse, the one we focus on here is that of pragmatics , involving the spatio-temporal and intentional context in which the discourse is uttered. We find this approach particularly fitting through its implication of the cooperative principle , in which utterances are ultimately related to one another through communicative cooperation to reveal the intent of the speaker ( Schiffrin, 1994) . Practically, this means that we assume the position of programmers talking to programmers is cooperative insofar as both speaker and listener want to achieve a similar goal: expliciting what writing good code entails. This double understanding—focusing first and foremost on utterances, and then re-examining them within a broader cooperative context—will lead us to encompass a variety of production media (blog post, forums, conferences, text books), in order to depict the cultural background (software practices as outlined above as well as additional factors such as skill levels). Our comprehension of those texts, then, will be set in motion by a dual movement between local, micro-units of meaning and broader, theoretical macro-structures of the text, and linked by acts of co-reference ( Kintsch, 1978) . As the macro-structures represent certain kinds of world situations, we will connect these to specific aesthetic fields, considering that the world of the aesthetics of source code is pragmatically connected, by the programmers and via their discourses, to adjacent worlds of the aesthetics of architecture, literature and mathematics.
Particular attention will be paid to the difference between intentional and extensional meaning ( Dijk, 1983) . As we will see, some of the texts in our corpus tend to address a particular problem (e.g. on forums, social media or question & answer platforms), or to discuss broader concepts around well-written code. Particularly, figures of speech such as metaphorical devices may attract attention to important concepts, provide more cues for local and global coherence, suggest plausible interpretations (e.g., a praise versus a critique), and will in general assign more structure to elements of the semantic representation, so that [meaning] retrieval is easier ( Dijk, 1983) . As we will see, a reference to code as a spaghetti is not made to connote a specific kind of food, but rather convoluted spatial properties.
Following this idea, we will examine discursive markers to deduce overarching concepts at the semantic level. Among those discursive markers, we include single propositions as explicit predicates regarding source code, lexical fields used in those predicates in order to identify their connotations and denotations, as well as for the tone of the enunciations to identify value judgments. At the semantic level, we will examine the socio-cultural references, the a priori knowledge assumed from the audience, as well as the thematic entities which underline the discourse at hand. We will also not be limited to discourses in natural language, but also include source code examples presented by programmers as components of their argumentation.
Finally, our intepretation of the macrostructures described by Kintsch and Van Dijk will be complemented by the work done by Lakoff and Johnson on a theory of conceptual metaphors. They argue that the metaphor maps a source domain, made up of cognitive structures, to a target domain and, in the process, they extend the field of applicability of metaphors from the strictly literary to the broadly cultural; metaphors work because each of us has some conception of those domains involved in the metaphorical process ( Lakoff, 1980 Lakoff, 1980) . Metaphors' essential dependence on these pre-existing cognitive structures, which we associate with familiar concepts and properties, give them an explanatory quality when it comes to qualify foreign domains.
In particular, these sources are defined enough to not be mistaken for something else, but broad enough to allow for multiple variants of itself to be applied to various targets, providing both diversity and reliability in our inquiry.
As we will see below, their approach allows us to focus not just on textual objects, but on the vast range of linguistic devices used to make sense in computing-related environments. Given that the source of the metaphor should be grounded, with as little invariablity as possible, in order to qualify a potentially ill-defined target domain, this provides us with a first foray into the inherent elusiveness and instability of computing when presented to a broader audience.
Going beyond the role of metaphors manifested in expressions such as the desktop , the mouse , or the cloud mentioned in  Metaphors in computation   , we will explore Lakoff's understanding of the specifically poetic metaphor in  Literary metaphors   when it comes to qualifying the aesthetics of source code. We will pay particular attention to what programmers are saying about beautiful (or ugly) source code, which metaphors they employ to support these value judgments, and why—focusing first on the metaphors of source code, before moving, in the next chapter, to the metaphors in source code.
The corpus studied here consists of texts ranging from textbooks and trade manuals to blog posts and online forum discussions48 . These constitute our primary sources insofar as they are written by practitioners on the topic of good and beautiful code. The rationale behind such a broad approach is to constitute a lexical basis for what practicing programmers consider when assessing good code, as expressed in the everyday interactions of online forums and blog posts, but also inclusive of diverse sources of communication, beyond edited volumes. We consider that authoritative sources can be both canonical textbooks or widely-read blog posts from well-known skilled practitioners, but also include more casual forum exchanges in order to support the empirical dimension of our research. This methodology will allow us to show that there are specific ways in which programmers qualify well-written code, and employing recurring references.

Lexical Field in Programmer Discourse

There is one major study of the lexical field programmers use, done by Erik Piñeiro in his doctoral thesis. In it, he argues that aesthetics exist from a programmers perspective, decoupled from the final, executable form of the software. While this current study draws on his work, and confirms his findings, we also build upon it in several ways. First, Piñeiro focuses on a narrower corpus, that of the Slashdot.org forums ( Pineiro, 2003) . Second, he examines aesthetic judgment from a private perspective of software engineers, separate from other possible aesthetic fields which might enter in dialogue with beautiful code ( Pineiro, 2003) , such as artists or hackers. Finally, his discussion of aesthetics takes place in a broader context of business management and productivity, while this current study situates itself within a broader interdisciplinary field including comparative media studies and aesthetic philosophy and science and technology studies. Still, Piñeiro's work provides valuable insights in terms of identifying the manifestations and rationales for an aesthetic experience of source code. Here, we build on his works by highlighting the main adjectives in the lexical field of programmers' discourse, in and beyond software developers.

Clean

Already mentioned in Peter Naur's analysis of the practice of programming, clean is the first adjective which stands out as a requirement when assessing the form taken by source code. Clean code, he says, is a reference to how easy it is for readers of code to build a coherent theory of the system both described and prescribed by this source code ( Naur, 1985) . This purpose of cleanliness is developed at great lengths a couple of decades later in a series of best-selling trade manuals written by Robert C. Martin and published by Prentice Hall from 2009 to 2021, the full titles of which clearly enunciate their normative aim49 . What exactly is cleanliness, in Martin's terms, is nonetheless defined by circumlocutions; he relies on contributions from experts, again showing the relationship between expertise and aesthetic judgment. After asking leading programmers what clean code means to them, he carries on in the volume by providing examples of how to achieve clean code, while only loosely defining what it is. In general, cleanliness is mostly a definition by negation: it states that something is clean if it is free from impurities, blemish, error, etc. An alternative to this definition which trade manuals such as Clean Code use consists in providing examples on how to move from bad, "dirty" code, to clean code through specific, practical guidelines regarding naming, spacing, class delimitation, etc.. Starting at a high-level, some hints can be glimpsed from Ward Cunningham's answer:
You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem. ( Martin, 2008) (p.10)
along with Grady Brooch's:
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control. ( Martin, 2008) (p.11)
Cleanliness is tied to expressiveness: by being devoid of any extraneous syntactic and semantic symbols, it facilitates the identification of the core of the problem at hand. Cleanliness thus works as a pre-requisite for expressivity. In a clean-looking program text, the extraneous details disappear at the syntactic level, in order to enable expressiveness at the semantic level.
Martin echoes Hunt when he advocates for such a definition of clean as lack of additional syntactic information:
Don't spoil a perfectly good program by over-embellishment and over-refinement. ( Hunt, 1999)
Here, it is about quantity rather than quality: ornaments that are positively valued in parsimony (such as comments) can prove to be detrimental when there are too many of them. This advice to programmers denotes a conception of clean that is not just about removing as much syntactic form as possible, but which also implies a balance. Overembellishment implies excess addition, while over-refinement implies, on the contrary, excess removal. This normative approach finds its echo in the numerous quotations of Antoine de Saint-Exupéry's comment on aircraft design across programmer discourses ( Programming Wisdom [@codewisdom], 2021 Jackson, 2010 4.4.7, 2003) :
Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. ( Saint-Exupéry, 1972) 50

Obfuscation

As a corollary to clarity stands obfuscation. It is the act, either intentional or un-intentional, to complicate the understanding of what a program does by leading the reader astray through a combination of syntactic techniques, a process we have already seen in the works of the IOCCC above (see the discussion around    ). In its most widely applied sense, obfuscation is used for practical production purposes: reducing the size of code, and preventing the leak of proprietary information regarding how a system behaves. For instance, the JavaScript source code in    is obfuscated through a process called minification into the source code in    . The result is a shorter and lighter program text when it comes to its circulation over a network, at the expense of readability.
home_js

import { ref, onMounted, reactive } from 'vue';

const msg = ref("")
const HOST = false ? "http://localhost:3046" : ""
const syllabi = new Array<SyllabusType>()

let start = () => {
    window.location.href = '/cartridge.html'
}

onMounted(() => {
    fetch(`${HOST}/syllabi/`,
        {
            method: 'GET'
        })
        .then(res => {
            return res.json()
        })
        .then(data => {
            Object.assign(syllabi, JSON.parse(data))
            console.log(syllabi);
            if (syllabi.length == 0)
                msg.value = "No syllabi :("
            else
                msg.value = `There are ${syllabi.length} syllabi.`

        })
        .catch(err => {
            console.error(err)
            msg.value = "Network error :|"
        })
})
- An excerpt of a JavaScript program text as it is written by a human programmer, before minification.
home_minified_js

import{_ as p,g as f,o as l,c as n,a as c,h as e,t as r,b as u,i as b,u as _,F as y,H as g,e as w}from"./Header.js";const H={class:"container p-3"},N=e("h1",null,"Home",-1),k={class:"syllabi"},x=["href"],B={class:"cta"},F=m({setup(S){const s=v(""),d="http://localhost:3046",o=new Array;let h=()=>{window.location.href="/cartridge.html"};return f(()=>{fetch(`${d}/syllabi/`,{method:"GET"}).then(t=>t.json()).then(t=>{Object.assign(o,JSON.parse(t)),console.log(o),o.length==0?s.value="No syllabi :(":s.value=`There are ${o.length} syllabi.`}).catch(t=>{console.error(t),s.value="Network error :|"})}),(t,i)=>(l(),n(u,null,[c(g),e("main",H,[N,e("div",k,[e("div",null,r(s.value),1),e("ul",null,[(l(!0),n(u,null,b(_(o),a=>(l(),n("li",null,[e("div",null,[e("a",{href:"/syllabi/"+a.ID},r(a.title),9,x)]),e("div",null,r(a.description),1)]))),256))])]),e("div",B,[e("button",{id:"cta-upload",class:"btn btn-primary mb-4 cc-btn",onClick:i[0]||(i[0]=a=>_(h)())},"Upload yours!")])]),c(y)],64))}});var O=p(F,[["__file","/home/pierre/code/commonsyllabi/viewer/www/src/Home.vue"]]);w(O).mount("#app");
- The same program as in , after minification. Syntactical density is gained at the expense of clarity.
In most cases, this process of obfuscation has very defined, quantitative assessment criterias, such as the size of the source code file and cryptographic complexity ( Pellet-Mary, 2020) . Nonetheless. obfuscation can also be valued as a positive aesthetic standard, of which the IOCCC is the best example and the most institutionalized guarantor. These kinds of obfuscations, as Mateas and Montfort analyze, involve the playful exploration of the intertwinings of syntax and semantics, seeing how much one can bend the former without affecting the latter. These textual manipulations, they argue, possess an inherently literary quality:
Obfuscation and weird languages invite us to join programming contexts to the literary contexts that must obviously be considered when evaluating literary code. They also suggest that coding can resist clarity and elegance to strive instead for complexity, can make the familiar unfamiliar, and can wrestle with the language in which it is written, just as much contemporary literature does. ( Mateas, 2005)
Such literary connection can also be seen in Noël Arnaud's work Poèmes Algol  ( Arnaud, 1968) , in which he uses the constructs of the language Algol 68 in order to evoke in the reader something different than what the program actually does (i.e. fail to execute anything meaningful). Here, obfuscation can be considered a literary value, but its negative connotations, obfuscation nonetheless points at the recurring theme of ease (or difficulty) of understanding.

Simple

This balance between too much and too little is found in another dichotomy stated by programmers: between the simple and clever. Simplicity, argues Jeremy Gibbons, is not only a restraint on the quantity of syntactic tokens (as one could achieve by keeping names short, or aligning indentations), but also a semantic equilibrium at the level of abstracted ideas ( Gibbons, 2012) .
Simplicity in source code is therefore a form of parsimony and balance51 .
This requirement of exerting balance leads us to make a difference between two kinds of simplicity: syntactical simplicity, and ontological simplicity. Syntactic simplicity measures the number and conciseness of visible lexical tokens and keywords. Ontological simplicity, in turn, measures the number of kinds of entities involved in the semantics of the program text. Source code can have syntactic simplicity because it wrangles together complex concepts in limited amount of characters (see our discussion on one-liners in  Program texts as puzzles   ), or code can have ontological simplicity, because of the minimal amount of computational concepts involved (as explained in  Computation as an end   ). Syntactical simplicity also has a more immediate consequence on one's experience when reading a program text: one of the issues that programmers face is that there are just too many lines of code that one can wrap its head around, thus requiring that the content be pared down to its functional minimum ( Butler, 2012) .
This distinction between syntactical and ontological simplicity highlights this need for balance, along with the concrete tradeoffs between syntax and semantics that might need to be done when writing code. Source code aesthetics thus have to balance between simplicity in breadth and simplicity in depth regarding the composition of the program text, between the precision of a use-case in a problem domain and its generalization, and between its self-reliability and its leveraging of external—i.e. supposedly reliable—program texts.
In another ACM publication, Kristiina Karvonen argues for simplicity not just as a concrete design goal, as leveraged by human-computer interface designers52 , but as a term with a longer history within the tradition of aesthetic philosophy, especially the work of Johann Joachim Winckelmann ( Karvonen, 2000) . In particular, she stresses the difficulty "to create significant, that is, beautiful works of art with simple means" ( Karvonen, 2000) . Here, we take her correlation between significance and beautiful in a very literal manner; a connection between significance and beauty hints at the semantic role of beauty, and thus of simplicity as a component of the beautiful, at the role of beauty as a means to communicate (i.e. to signify ) ideas to an audience.
Precisely, simplicity is correlated with clarity (of meaning); if the former refers mainly to the syntactical and ontological components, it enables the non-obfuscated representation of the ideas at play in the function of a program text. An example of clarity is given in    by Dave Bush in a post titled 15 Ways to Write Beautiful Code .
clearer_method_c

  void SomeMethod(int x, int y){
    if(x != y){
        //-- stuff
    }
}

void SomeClearerMethod(int x, int y){
    if(x == y) return;
    //-- do stuff
}
- Example of clarity differences between two methods.
Here, striving for simplicity implies removing the brackets, and flipping the boolean check in the if-statement to add an early return  statement. Even though it is, strictly speaking, more characters than the brackets and newline (six characters compared to four), the program becomes cleaner, and thus clearer, by trading syntactical simplicity for ontological simplicity. Bush argues that, by separating the two branching cases inherent to the use of conditional logic, under the form of an if-statement, the program-text becomes clearer. In the second version, it is made clear that, if a condition is true , the execution should stop, and any subsequent statement can entirely disregard the existence of the if-statement; in the first version, the condition that is not true is entangled with code that should be executed, since the existence of the if-statement has to be kept in mind until the closing bracket, at the bottom of the program text ( Bush, 2015) .
A final insight on simplicity and programming regarding the communication of ideas is hinted at by Richard P. Gabriel in his use of the concept of compression in both poetry and programming. He argues that programmers have a desire to increase the semantic charge (or significance, in Karvonen's terms) all the while reducing the syntactic load (or the quantitity of formal tokens). Compression thus implies simplicity, but also qualifies such simplicity in terms of how much is expressed by a simple statement. The more complex the problem the program intends to solve, the more important the role simplicity plays in communicating such complexity. William J. Mitchell sums it up in his introductory textbook for graphics programming:
Complex statements have a zen-like reverence for perfect simplicity of expression. ( Mitchell, 1987)
Simplicity is found in source code when the syntax and the ontologies used are an exact fit to the problem : simple code is code that is neither too precise, nor too generic, displaying an understanding of and a focus on the problem domain, rather than the applied tools.

Clever

Conversely, the intellectual nature of a programmer's practice often involves technical tricks. Even though programming is both a personal and collective activity, there is a tendency of programmers to rely on convoluted, ad hoc solutions which happen to be quick fixes to a given problem, but which can also be difficult to generalize or grasp without external help. Such an external help often takes the form of explanation, and is not often positively valued, as pointed out online by Mason Wheeler:
When it requires a lot of explanation like that, it's not "beautiful code," but "a clever hack." ( Overflow, 2013)
This answer, posted on the software engineering Stack Exchange forum, in response to the question "How can you explain "beautiful code" to a non-programmer?" ( Overflow, 2013) , not only highlights the ideal for a program text to be self-explanatory, but also points at a quality departing from simplicity—cleverness.
Cleverness is often found, and sometimes derided, in examples of code written by hackers, since it unsettles this balance between precision and generality. Clever code would tend towards exploiting particularities of knowledge of the medium (the code) rather than the goal (the problem). Hillel Wayne presents the snippet of Python code reproduced in    as an example of clever, and therefore bad, code:
is_unique_python

def is_unique(_list):
    return len(set(_list)) == len(_list)
- A function to check for the uniqueness of array elements, using a very specific feature of the Python syntax, and as such an example of clever code.
From the name of the function, is_unique()  , one can deduce that what the program text does is returning whether all elements of a list are unique. However, to understand the particular way in which this is done, the writer requires knowledge of how the set()  function in Python behaves. A programmer without familiarity with Python would be unable to do so without consulting the Python documentation, or through external explanation.
Hillel elaborates on the difference between "bad" clever code53 , which is essentially read-only due to its idiosyncracy and reliance on tacit knowledge, and "good" clever code, and such distinction corroborates our previous observations regarding beautiful code as a means for expression of the problem domain. His example is that the problem of sorting the roughly 300 million U.S. american citizens by birthdate can be made considerably more efficient by cleverly considering that no U.S. american citizen is older than 130 years, whereby radically reducing the computation space.
Cleverness is thus valued positively in certain contexts. Hacker practices in particular tend to put more emphasis on the technical solution than on the problem domain, as we have saw in  Hackers   . A salient is example was the 1994 smr.c  entry to the IOCCC, which aimed at being the smallest self-reproducing program ( Kanakarakis, 2022) . An exact reproduction of the source code can be found in   
smr_c
- An empty program text which was awarded the IOCC's "World's smallest self-replicating program" and "Worst abuse of rules"  ( Rusinkiewicz, 1970)
Consisting of a file weighing zero bytes, smr.c  provides both a clever reduction of the problem domain, and a clever understanding of what C compilers would effectively accept or not as a valid program text ( Kanakarakis, 2022) , resulting in a particular confusion to the reader (and jury). Because it has since been banned under the rules of the IOCCC, this source code entirely renounces any claim to a more general application, and finds its aesthetic value only within a specific socio-technical environment.

Elegance

Programmers hold the idea of reaching aesthetic quality through the reduction of complex syntactical and ontological constructs, without minimizing expressivity. Striving towards an inverse relationship between the complexity of an idea and the means to express it involves another aesthetic criteria present in programmers' discourse: elegance . Such an ideal is clearly rooted in the definition of elegance given by the Jargon File , also known as the hacker's dictionary:
elegant: adj.[common; from mathematical usage] Combining simplicity, power, and a certain ineffable grace of design. Higher praise than 'clever', 'winning', or even cuspy.The French aviator, adventurer, and author Antoine de Saint-Exupéry, probably best known for his classic children's book The Little Prince, was also an aircraft designer. He gave us perhaps the best definition of engineering elegance when he said “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” ( 4.4.7, 2003)
Leslie Valiant, recipient of the Turing Award in 2010, considers elegance as the explanatory power of simple principles, which might only appear a posteriori —a solution can only be qualified as elegant once it has been found, and very rarely during the process of its development ( Anthes, 2011) . Chad Perrin, in his article ITLOG Import: Elegance , first approaches the concept as a negation of the gratuitous, a means to reduce as much as possible the syntactic footprint while keeping the conceptual load intact:
In pursuing elegance, it is more important to be concise than merely brief. In a general sense, however, brevity of code does account for a decent quick and dirty measure of the potential elegance that can be eked out of a programming language, with length measured in number of distinct syntactic elements rather than the number of bytes of code: don't confuse the number of keystrokes in a variable assignment with the syntactic elements required to accomplish a variable assignment. ( Perrin, 2006)
Perrin also hints at the additional meaningfulness of elegance, as he compares it to other aesthetic properties, such as simplicity, complexity or symmetry. If simplicity inhabits a range between too specific and too general, he describes an elegant system as exactly appropriate for the task at hand, echoing others' definition of clean or simple source code. Elegance, he says, relies on strong, underlying principles, but is nonetheless subject to its manifestation through a particular, linguistic interface. While he touches at length on the influence of progamming languages in the possibility to write elegant source code, we will only address this question in  Programming languages   .
Donald Knuth adds another component required to achieve elegance in software: along with leanness of code and the suitability of the language, he adds that elegance necessitates a clear definition of the problem domain ( UNKNOWN AUTHOR, 2008) . Along with the appropriateness of the linguistic tooling, one can see here that the representation of the data which is then going to be processed by the executed source code also matters. Source code is not only about expressing dynamic processes, but also about translating the problem domain into formal static representations which will then be easy to operate on. Ideally, elegant code communicates the problem it solves and the machinery of its solution, all through a single lens.
This aspect of implying underlying principles is also present in Bruce McLennan's discussion of the concept. He also adds to this perspective a certain subjective feeling.He defines his Elegance Principle as:
Confine your attention to designs that look good because they are good. ( McLennan, 1997)
Such a definition relies heavily on the sensual component of elegance: while an underlying property of, at least, human activities, it must nonetheless be manifested in some perceptible way. Interestingly, he approaches elegance through the dual lens of structural and software engineering, this indicates that he also considers elegance as a more profound concept which can manifest itself across disciplines, connecting ways of making, and ways of thinking ( McLennan, 1997) .
On Stackexchange , user asoundmove corroborates this conception of achieving a simple and clean system where any subsequent modification would lead to a decrease in quality:
However to me beautiful code must not only be necessary, sufficient and self-explanatory, but it must also subjectively feel perfect & light. ( Overflow, 2013)
Connected to simplicity by way of necessity and sufficiency, the perception of elegance is also related to a subjective feeling of adequacy, of fitness. Including some of the definitions of simplicity we have seen so far, Paul DiLascia, writing in the Microsoft Developer Network Magazine, illustrates his conception of elegance—as a combination of simplicity, efficiency and brilliance—with recursion ( DiLascia, 2019) , as seen in    .
factorial_c

int factorial(int n)
{
  return n==0 ? 1 : n * factorial(n-1);
}
- The use of recursion, rather than iteration, in the computation of a factorial is particularly praised by programmers.
Recursion, or the technique of defining something in terms of itself, is a very positively valued feature of programming ( Abelson, 1979) , which we have seen an example of in    . In so doing, it minimizes the number of elements at play and constrains the problem domain into a smaller set of moveable pieces. Another example, provided in the same Stackexchange discussion is the quicksort  algorithm, which can be implemented recursively or iteratively, with the former being significantly shorter (see    )
recursion_iteration_csharp

public static void recursiveQsort(int[] arr,Integer start, Integer end) { 
    if (end - start < 2) return; //stop clause
    int p = start + ((end-start)/2);
    p = partition(arr,p,start,end);
    recursiveQsort(arr, start, p);
    recursiveQsort(arr, p+1, end);
}

public static void iterativeQsort(int[] arr) { 
    Stack<Integer> stack = new Stack<Integer>();
    stack.push(0);
    stack.push(arr.length);
    while (!stack.isEmpty()) {
        int end = stack.pop();
        int start = stack.pop();
        if (end - start < 2) continue;
        int p = start + ((end-start)/2);
        p = partition(arr,p,start,end);

        stack.push(p+1);
        stack.push(end);

        stack.push(start);
        stack.push(p);
    }
}
- The comparison two functions, one using recursion, the other one using iteration, intends to show the computational superiority of recursion. .  ( amit, 2012)
Going back to the personal factor in perceiving elegance, we can follow Mahmoud Efatmaneshik and Michael J. Ryan who, in the IEEE Systems journal, offer a definition of elegance which relies both on a romantic perception—including subjective perception: "gracefulness", "appropriateness" and "usability"—and practical assessment with terms such as "simple", "neat", "parsimonious" or "efficient" ( Efatmaneshnik, 2019) . In doing so, they ground source code aesthetics as a resolutely dualistic norm, between subjectivity and objectivity, qualitative and quantitative, a duality whose implications are developed in  Understanding computation   .
And yet, rather than subjectivity and objectivity being opposites, one could also consider them as contingent.nope! cmd. If clean , simple , elegant seem to overlap, it is because they all seem to point at this maximization of meaning while appropriately minimizing syntax, written by one programmer for another.

Smells

A complementary approach to understand what programmers mean when they talk about beautiful code is to look beyond the positive terms used to qualify it, and shift our attention to negative qualifiers. We have already touched upon terms such as clever, or obfuscated, which have ambiguous statuses depending on the community that they're being used in—specifically hackers and literary artists. Further examination of negative qualifiers will enrich our understanding of what constitutes good code; programmers have another way to refer to code that does not meet aesthetic criteria, by referring to material properties.
One of those hints comes from satirical accounts of how to write bad code. For instance, Green's post on How To Write Unmaintainable Code suggests new kinds of obfuscation, such as double-naming in    or semantic interactions in    . The core ideas presented here revolve around creating as much friction to understanding as possible, by making it " as hard as possible for [the reader] to find the code he is looking for " and " as awkward as possible for [the reader] to safely ignore anything. "  ( Green, 2006) .
green_unmaintainable

openParen = (slash + asterix) / equals;
- This listing shows variable names that masquerade as mathematical operators, greatly increasing reader confusion.
By looking at it from the opposite perspective of highly-confusing code, we see best how carefully chosen aesthetics, under the values of simplicity, clarity, cleanliness and elegance intend first and foremost to help alleviate human cognitive friction and facilitate understanding of what the program is doing. The opposite amounts to playing misleading tricks.
green_unmaintainable_2

for(j=0; j<array_len; j+ =8)
{
  total += array[j+0 ];
  total += array[j+1 ];
  total += array[j+2 ]; /* Main body of
  total += array[j+3]; * loop is unrolled
  total += array[j+4]; * for greater speed.
  total += array[j+5]; */
  total += array[j+6 ];
  total += array[j+7 ];
} 
\end{minted}
- This listing shows code that masquerades as comments, and vice-versa.
For instance, spaghetti code refers to a property of source code where the syntax is written in such a way that the order of reading and understanding is akin to disentangling a plate of spaghetti pasta. While technically still linear in execution, this linearity loses its cognitive benefits due to its extreme convolution, making it unclear what starts and ends where, both in the declaration and the execution of source code. Rather than using a synonym such as convoluted , the image evoked by spaghetti is particularly vivid on a sensual level, as a slimy, vaguely structured mass, even if the actual processes at play remain eminently formal ( Steele, 1977) . Such a material metaphor is used in a similar way in Foote and Yoder's description of code as a "big ball of mud":
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. ( Foote, 1997)
A broader approach to these sensual perceptions of code involve the reference to code smells . These smells are described by Martin Fowler as " surface indications that usually corresponds to a deeper problem in the system "  ( Fowler, 1999) . They are aspects of source code which, by their syntax, might indicate deeper semantic problems, without being explicit bugs. The name code smell evokes the fact that their recognition happens through intuition and experience of the programmer reading the code,nope! cmd, rather than through careful empirical analysis54 . This points to a practice-based skill system to evaluate the quality of source code, rather than to an evidence-based one, itself circling back to the qualifications of elegance discussed above, evaluated both as quantitative metric and as qualitative one.
-
In conclusion, this section has clarified some of the key terms used in programmers' discourse when discussing aesthetically pleasant code. Basing our interpretation of the gathered sources through discourse analysis, we specifically assumed a cooperative principle, in which all participants in the discourse intend to achieve writing the best source code possible. This analysis has confirmed and updated the findings of Piñeiro's earlier study: excellence in instrumental action forms the core of writing source code, but can also vary along different contexts of reading and writing. Across textbooks, blog posts, forums posts and trade books, the aesthetic properties of code are widely acknowledged and, to a certain extent, consistent in the adjectives used to qualify it (clean, elegant, simple, clear, but also clever, obscure, or smelly).
While there is a consistency in describing the means of beautiful code, by examining a lexical field with clear identifiers, this analysis also opens up additional pathways for inquiry. First, we see that there is a relationship between formal manifestations and cognitive burden, with aesthetics helping alleviate such a burden. Beautiful code renders accessible the ideas embedded in it, and the world in which the code aims to translate and operate on. Additionally, the negative adjectives mentioned when referring to the formal aspects of code (smelly, muddy, entangled) are eminently materialistic , indicating some interesting tension between the ideas of code, and the sensuality of its manifestation.
Moving beyond strict lexical tokens, we can see in the breadth of responses in a programmer's question of "How can you explain "beautiful code" to a non-programmer?" ( Overflow, 2013) that programmers also rely on multiple aesthetic domains to which they refer: from engineering and literature to architecture and mathematics. As such, they deploy metaphors for what beautiful code is. Moving from a syntactical level to a thematical level, to refer to Kintsch and Van Dijk's framework of discourse analysis, we now turn to an investigation of each of these domains, and what they tell us about source code.
icon to reference a footnote
icon to reference a footnote
icon to reference a footnote
icon to download the pdf of the thesis