Written and published in 1983 on a Usenet board, The story of Mel, the Real Programmer recounts the tale of Mel Kaye, an individual who wrote software on the 1959 ACT-1 compiler and has become a recurring reference in programmer’s lore. The moral of the story focuses on Kaye’s ability to write both excellently efficient and completely inscrutable code. This obfuscating aspect of a code that only its writer can read, while being considered in this context a laudable feature of model programming work and informing ideals of programmers, slowly began to phase out in the 1970s. With the growth of the commercial software market, more and more private companies started to constitute what is today a large part of the technology industry, composed of teams of multiple programmers working on the same codebase on the long-term. This evolution, from the individual programmer implementing ad hoc and personal solutions to a group of programmers coordinating across time to build and maintain large, distributed pieces of software, brought the necessity to harmonize and standardize how code is written. In response, style guides started to be published to normalize the visual aspect of source code, and became a recurring topic in both the software development and computer science research; particularly, debates about programming style implementations and best practices have remained significant, if under-examined, parts of a given programmer’s practice in a commercial context.
In the first part, I will address the origin of style in programming and, consequently, the need for style guides in contemporary, commercial programming practices, inscribing it further into both the sociology of style and the sociology of organizations. In particular, I will highlight continuities and breaks between style guides for human languages and style guides for programming languages, specificaly in terms of objective efficiency and subjective perception. Building on this dichotomy, the second part of this article highlights the specific technical intermediary objects involved in those discussions and implementations, which exist in this field at both a macro- and micro-level. Both GitHub and linters are significant components of the creation and implementation of style guides and will thus occupy a central role in this analysis. After developing on the research methods used in this study, which are centered qualitative discourse analysis of issues and pull requests, I will develop on the findings of this research, summing up discursive and structural differences between the three targeted repositories. I will conclude by focusing on the place of tools, read-only documents and read-write documents, as well as invisible communities, in the development of style guides and how these can inform our understanding of daily programming practices.
The problem of style is a problem which echoes Simmel’s statement regarding the observation that “the practical existence of humanity is absorbed in the struggle between individuality and generality”. Simmel’s investigation on style, which will serve as the foundation for our definition of style, focuses on works of fine art, but his study applies equally to works of craftmanship, in particular as detailed by Ruskin. Indeed, Simmel draws a distinction between works of fine arts, displaying the idiosyncracy of its maker, and works of fine arts, industrially produced and replicated, between which the copy cannot be told apart from the original. The work of fine art, according to him, is “a world unto itself, is its own end, symbolizing by its very frame that it refuses any participation in the movements of a practical life beyond itself”, while the work of applied arts only exists beyond this individuality. While these two kinds of work exist at the opposite extremes of a single continuum, the work of craftsmanship exists in between, as a repeated display of its maker’s subjectivity, destined for active use rather than passive contemplation. So while style can be seen as a general principle which either mixes with, replaces or displaces individuality, programming style doesn’t stand neatly at either extreme. conclude with a definition of style.
Source code, as the product of programming work, finds some of its roots in craftmanship, as a practice both analyzed by scholars and claimed by practicioners. Programming work has developed since the 1950s from an invisible labour to a fully organized and codified practice, through individual, glorified work. While computers were originally referencing female clerks implementing male mathematicians’ algorithms on mainframe computers, the development of programming as a recognized practice brought about with it the figure of the individual programmer, equally obsessed and talented, echoing the portraits of the genius artist in the Renaissance. This individual, free-form implementation of specific computational problems came to an end with the rise of commercial software, and led to a re-examination of the practices and processes of software developers. This re-examination was spearheaded by the work of Edsger Dijkstra whom, in his 1972 publication of Notes On Structured Programming, set forward clear practices for writing source code which would be meant to achieve two aims: be readable by someone else than the original author, as well as being more reliable and error-free.
The emergence of style in computer programming is therefore concomitant of the development of the software industry. A self-proclaimed highly complex undertaking, the understanding of source code by someone who hasn’t written it (or, being the writer, hasn’t read it in a while) quickly showed itself to prove difficult; as a response, corporate literature rose in order to serve as a reference for best practices. This phenomenon of explicitly written rules, dependent no longer on their writer, but rather on the organization to which the writer belongs, echoes the formalization of knowledge as it happened during the transition of societies from oral communication (and their constituting organizations) to a written one. Additionally, the written codification of hitherto implicit, idiosyncratic rulesets, has had the result of further preventing modification of said rules, and elevating them from a “personal” reach to a “universal” one. However, the technical context fort those studies of the impact of literacy is that the written word, once put down, is significantly harder to modify than the spoken word. The digital word, the word stored on and communicated via computers, however presents differences from either its oral or written counterpart. First, it can be as easily modified as it can be retrieved. Since one of the basic operations of the computing machine is the act of copy and the act of retrieval, it is important here to remember that anything that can be said on a digital medium always holds within itself the possibility of variation, illustrated on the most obvious-level by the ubiquity of “copy and paste” actions offered as a default by any word processor application on a modern computer. Second, source code written in programming languages is executable. This means that, beyond the linguistic act of writing a statement, this writing is automatically executed and enforced, without stating the need for personal or social performance as a requirement. So while written code still exists within “chains of acts of writing”, once its validity has been confirmed and merged into active code bases, its enforcement is significantly easier than that of guides and protocols written in human languages.
Along with the low barrier to reproducibility and enforceability of code, a second difference between organizations centered primarily on machine languages and organizations in which code only constitutes a technical background is the porosity of the distinction between public and private.
Now comes the paragraph on the sociology of work, how language and writing is important in it, but also how OSS is actually different because everyone can fucking do what they want.
introduce the style guide
in the end it’s affected by github’s:
: Nather, Ed (2003-09-12) [1983-05-21], The story of Mel, a Real Programmer, FOLDOC
: ref needed
: ref needed
: ref needed - formal institutions (goody?)
: objets intermediaires
: simmel, the problem of style
: ruskin, seven lamps
: sennett, the craftsman
: clean code, martin
: wendy huy kyong chun
: computer power and human reason
: the lives of artists
: ref needed
: frankel, 2006