1Written 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 (Nather, 2003). The story focuses on Kaye’s ability to write both excellently efficient and completely inscrutable code. Code which only its writer can read, considered as model programming work and informing ideals of programmers, slowly began to phase out with commercial software.
2The 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 (van den Boogard, 2008). In response, style guides started to be published to normalize the visual aspect of source code, and became a recurring topic in both software development and computer science research (Kerninghan & Plauger, 1974).
- 1 The sources for this article are all taken from comments from issues on three different GitHub repo (...)
3In light of this tension between individual technical prowess and the social existence of source code, this article examines the communication processes involved in the construction, distribution and implementation of style guides for the JavaScript programming language within a contemporary software development environment—the collaborative platform GitHub1.
4While style guides and written documents have been enforced in formal, more traditional professional institutions heavily involved in writing (Christian et. al., 2011), GitHub presents a couple of specific aspects. First, as the most popular repository of open-source software, it is the locus of semi-formal participation and allows the copying and modifying of any project (forking). Second, large-scale private companies interact with distributed non-profit organizations and individual contributors in order to collaborate on software products, both free of charge and for-profit, which can then be modified by other users of the platform.
5JavaScript is one of the most popular programming languages in the world2, and on GitHub3. However, the language itself lacks a clear, original style standard, and therefore has been the subject of various discussions on what a style guide should enforce and how it should enforce it. The active discussions taking place on the GitHub platform therefore represent a wide variety of opinions, skill levels, and institutional belongings. In this light, this article aims at investigating which discursive strategies are used by programmers around the formation and implementation of style guides? How are those strategies affected by the specificity of a socio-technical environment such as GitHub? How are users of these style guides involved in these negotiations? The answers to these questions will help qualify the nature of linguistic exchanges in a complex, digital-first, working environment and uncover the arguments and attitudes towards writing code.
6To do so, I propose to look at three GitHub repositories, each representing different approaches to style guides: the JavaScript style guide as published by the Airbnb company, the popular, independent StandardJS and the exclusively format-oriented Prettier. A guiding criterion for narrowing our research field was to use the common indicators of stars (Borges & Valente, 2018) and forks (number of users having copied the repository to their own account, possibly to modify it further, and to submit these changes back into the original repository). For the JavaScript language, the top three most popular repositories are airbnb/javascript (100,000 stars, 19,500 forks), prettier/prettier (37,400 stars, 2,500 forks) and standard/standard (24,000 stars, 1,900 forks) in December 2020. Additional JavaScript style guides include the IdiomaticJS style guide, the Google JavaScript Style Guide and the style presented by Douglas Crockford, but do not meet either the popularity criteria, or do not exist primarily on GitHub.
7These repositories, while sharing the same effective outcome of providing a style reference for other JavaScript programmers, present differences in their approaches to achieving that goal, and in their organizational practices. The airbnb/javascript repository is the public-facing result of the guide used internally at the Airbnb company, a startup company privately valued at USD31 billion in 2019. It consists of a main document, README.md, the first page displayed on any GitHub repository, as well as configuration files for linters, a piece of software which automatically modifies the layout of one’s source code. The standard/standard repository is a non-profit open-source organization aiming at providing a non-modifiable, non-extensible way to programmatically enforce both stylistic choices and technical error-checking through the use of the standard software, a command-line utility which aims at automatically checking the style described on an additional RULES.md document. Finally the prettier/prettier repository limits itself to the strict formatting of source code and providing a command-line utility to automatically enforce and apply those changes, which spun off from internal work at Facebook but not officially used by the company.
Table 1. Style guides
Name
|
Organization
|
Stars
|
Issues
|
Forks
|
Project description
|
airbnb
|
Airbnb
|
100,000
|
2,244
|
19,500
|
Configuration files that can be loaded in linters
|
standard
|
StandardJS
|
24,000
|
1,517
|
1,900
|
Software tool to check the code for syntactic and semantic inconsistencies with one given style guide
|
prettier
|
Prettier
|
37,400
|
9,017
|
2,500
|
Software tool to automatically enforce the exclusively syntactic style guide options
|
State of the examined repositories on 2020/09/01
8This study focuses on the issues sections of each of these repositories. Traditionally used to keep track of bugs and technical enhancements for project maintainers, an issue can be created by and commented on by anyone with a GitHub user account but can only be closed (or « resolved ») by the original author of the issue, or by project maintainers. While originally designed as a bug-tracker, research has shown that they are now the locus of more complex discussion, involving affective rhetoric and over-arching design inquiries, beyond specific technical fixes (Bissyandé et. al., 2013 ; Tsay et. al., 2014).
9The methodology employed here to analyze (1) how different actors negotiate the adoption of both subjective and objective stylistic norms, and (2) the influence of the technical environment in which those discussions take place, is based on the discourse analysis of individual issues in each examined repository.
10This approach will focus mainly on the most commented issues, highlighting the discursive strategies and patterns of the participants; since the least-commented issues are related to specific issues and bugs which stand outside of the field of argumentation. Specifically, we aim at linking the meanings of the corpus not just to existing social realities (Bourdieu, 1982), but to kinds of communicative competences embedded in technical realities. Habermas provides a typology of arguments deployed through communicative action (Habermas, 1984). Among these are theoretical discourse (based on logic), practical discourse (based on situational appropriateness), aesthetic criticism and explicative discourse; we will see how effective each of these are, and particularly how practical discourse is influenced by the socio-technical environment in which the communication takes place. Additionally, we use here Habermas’s notion of a negotiation as a bargain: in which both parties give up something in order to reach satisfaction, and contrast it with discussion, of which the result can be the change in stance of one, or both, parties. Regarding the restriction of the analysis to the exclusive locus of issues, we will consider that a read-only document (such as README.md) is relevant to our analysis insofar as it addresses a specific user, with a specific voice: if this linguistic interaction doesn’t imply discussion, it certainly implies discourse.
11Several studies have previously looked into the discourses on open-source communities (Berry, 2006), mostly through the use of large-scale computational techniques. The proposed approach examines specifically the nuances and implicit assumptions within the arguments deployed by the user, working under the hypothesis that, while broad strategies have been identified for issue resolution (Kavaler et. al., 2017), a more detailed and micro-level approach in the specific field of style guide adoption might provide insights in the daily practices of programmers, and to what extent they implement, re-appropriate, or hijack (“détournent”) the broad strategies of technical resolution assumed by GitHub (De Certeau, 2011).
- 4 This data was gathered via GitHub’s API; the script to generate the data can be found here: https:/ (...)
12The gathered corpus consists of 12780 issues and pull requests, totalling 53673 comments. From these, we discarded the least commented issues, under the assumption that meaningful and diverse discursive interaction takes place after 15 or more comments, which leaves a core corpus of 80 issues for airbnb/javascript, 82 issues for standard/standard and 444 for prettier/prettier4. While these were the main point of focus, this study included cursory browsing of lesser issues, particularly the chronologically earlier ones.
- 5 Here, Jakobson’s phatic function of language proves particularly useful.
13As a complementary to the studies mentioned above, our approach is qualitative: reading the most commented issues through the lens of Habermas’s arguments typology and evaluating them on multiple dimensions—the reference they resort to (the spatio-temporal, and causal contexts), the subject’s stance (speaking as an individual or on behalf of a group), the user’s background (shown by their status as either Member, Contributor or User, or by the other repositories of the corpus they might contribute to), and the ways that communication is initiated or concluded5. Reaction emojis, used to express passive agreement or disagreement with a message, are considered qualifying markers, not creating new meanings in and of themselves.
14A limitation of this study is that the surveyed population might just be a motivated subset of users, putting emphasis on the correct automation of the correct style of their code. While the findings here might not therefore represent the broader software development communities, they nonetheless embody heightened forms of socio-technical interactions, which might be more faintly manifested in other developers.
15In the first part, I will address the origin of style in programming and its need in contemporary, commercial programming practices, inscribing it further into both studies of style as social phenomenon, drawing on Simmel and Granger, as well as the anthropology of the written word, with Goody and Fraenkel. Building on this dichotomy, I then highlight the intermediary objects (Jeantet, 1998) that are code linters. I will conclude with an analysis of the GitHub development platform as a whole, its affordance for read-only and read-write documents, as well as its hosting of invisible communities, in the development of style guides.
- 6 Incidentally, this opposition between the individual artistic style and the mass-production is expl (...)
16The problem of style might be that « the practical existence of humanity is absorbed in the struggle between individuality and generality » (Simmel, 1991). Simmel’s investigation of the topic focuses on the dichotomy between works of fine art and mass-produced works of applied arts6. Simmel draws a distinction between unique objects displaying the subjectivity of its maker, and the industrially produced and replicated objects, which are only meant to serve practical ends.
17As these two kinds of work exist at the opposite extremes of a single continuum, we can insert a third approach: that of the crafted object. It exists in-between, as a repeated display of its maker’s subjectivity, destined for active use rather than passive contemplation (Sennett, 2009). So while style can be seen as a general principle which either mixes with, replaces or displaces individuality, style in programming doesn’t stand neatly at either extreme. The work of Gilles-Gaston Granger, and his focus on style as a structuring practice can help to better apprehend style as a relationship between individual taste and structural organization (Granger, 1988); we will see how discussions around style guides are often the result of tensions between individual preferences and the process of structuring (programming) texts.
18Historically, the emergence of style in computer programming is concomitant with the development of the software industry, starting in the structural shift of the 1970s (Djikstra, 1972), while retaining the personal, emotional attachment stemming from its relationship to craftsmanship. A self-proclaimed highly complex undertaking (Knuth, 1997), the understanding of source code by someone who hasn’t written it (or, being the writer, hasn’t read it in a while) is particularly difficult.
19Programming style guides are then textual documents with both social and technical components. On the social side, they are only useful if unconditionally adopted by all members working on a particular code-base, since « all code in any code-base should look like a single person typed it, no matter how many people contributed.»7; on the technical side, they are reference documents which should provide an answer to the question of what is the preferred way of writing a particular statement (e.g. var vs. let, or camelCase vs. snake_case). Beyond aesthetic preferences aimed at optimizing the clarity of a given source code, style guides also include a technical component which aims at reducing programming errors by catching erroneous patterns in a given codebase (e.g. variable declaration before initialization, loose reference to the function-calling context). This technical component, because it can be judged by an objective standard (i.e. bugs in a program), is however seldom the reason for internal disagreements within teams.
20Finally, while coding style hasn’t been explicitly shown to influence metrics by which programmer productivity is usually assessed (Cox and Fisher, 2008), it has nonetheless been linked to an improvement in program comprehension (Oman and Cook, 1988), and is regarded as a marker of quality work in the software development community8.
21This phenomenon of explicitly written rules, dependent no longer on their writer, but rather on the organization to which the writer belongs, presents similar patterns as those highlighted in the formalization of knowledge as it happened during the transition of societies from oral to written communication (Goody, 1986). For instance, 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 for those studies of the impact of literacy is one in which the written word, once put down, is not easily modified.
22The digital word, stored on and communicated via computers, presents two important differences. First, it can be as easily modified as it can be retrieved. Since one of the basic operations of the computing machine is copy and retrieval, anything that can be said on a digital medium always holds within itself the possibility of duplication, modification and, therefore, variation (Manovich, 2001). Second, source code is executable. Beyond the linguistic act of writing a statement, the result of this writing act can be automatically executed and enforced, without the need for social performance. Written code exists within these “chains of acts of writing” (Fraenkel, 2006), and 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 (Brousseau & Moatty, 2003). Fraenkel’s concept will be considered in the context of the digitization and the automation of such writing acts: whether by the process of closing an issue, labelling it under a certain category, or automatically executing the rules of a style guide, without further human intervention.
23We will see that intermediary objects (Vinck & Jeantet, 1995) play a crucial role in the productive activity of writing source code: as objects that lie in between several elements (source code, compilation process, IDE), several actors (programmers in the same team) and successive stages of a work process (drafting code, reviewing it, and committing it to production) , this study will rely on their concept to highlight the very active role that linters play in these negotiations.
24A final relevant element constituting our research field is the code linter. Present in every examined repository, and beyond the JavaScript ecosystem, a code linter is a software which, given a set of syntactic rules, and is able to, if granted permission from the user, modify one or multiple source code files to match said rules. This programmatic element, which can be seamlessly integrated into more complex workflows, represents both a transfer of agency from the human to the non-human, as well as an improvement in the systematic enforcing of style rules. For instance, linters can be distributed as plug-ins for Integrated Development Environments, in which code is written, in test suites, in which code is tested, and in continuous integration pipelines (including GitHub’s), in which code is built and deployed as executable. In certain configurations, linters can be continuously, and invisibly, operating on the code.
Figure 1a. Screenshots of a source code excerpt before its processing by a linter
Courtesy of the author.
Figure 1b. Screenshots of a source code excerpt after its processing by a linter
Courtesy of the author.
25Due to the overwhelming presence of automatic tooling in modern development (Hilton et. Al, 2016), programming style guides make configuration files for linters one of the most essential parts of their project, effectively connecting human-readable texts with their machine-executable counterparts. The most popular of those linters in the JavaScript ecosystem is eslint, with over 13 million weekly downloads9. As a tool in a programmer’s workflow, these linters with their associated configuration files are those intermediary objects (Latour & Woolgar, 1986), non-human actants contributing essentially to labour and knowledge-creation. Previous research in the sociology of work focused on how these intermediary objects affect the work processes (both conception, discussion and realization), particularly in establishing a framework within which work can take place (Vinck, 2009); coupled with the automated normativity of code (Lessig, 1999; Galloway, 2006), these linters represent a significant part of the impact of a style guide, as executable software enforcing a given style guide, itself provided as a configuration file for the linter, or being directly embedded in an executable, and therefore not easily modifiable.
26Another difference between organizations whose main product iscentered pecode and are , and ich softwarecodonly constitutetechnical infrastructure enabling normal operationsbackground is the pobetween the public and the private. That is, when organizations maintain, or depend on, open-source software, the delimitation of which individual contributes to the organization’s product becomes more fluid and temporary than in more traditional organizations (Hendry, 2008). In its most radical form, open-source developement is entirely non-hierarchical and horizontal (Benkler, 2006), a structure in which anyone can comment on the product and suggest modifications, even though actual contribution remains subject to additional social and economic constraints (Dabbish et. al., 2012). This configuration dse set of mutually-beneficial work relations constitutes the background of our research field and is accentuated by the specificity of the GitHub platform.
27As all platforms, GitHub connects multiple actors and provides the backdrop for economic, social and cultural practices (Gillespie, 2010). Economically, GitHub provides a way to store, retrieve and modify text files (often source code) for distributed teams of contributors, grouped into projects (repositories), themselves administered by either personal or organizational accounts. Any public repository is accessible to anyone, and these projects can then be built upon and add to the value of a given commercial product. Socially, GitHub requires user registration to contribute to any of those repositories, and maintains a transparency policy which makes available all of a user’s contributions on any public repository. These contributions overwhelmingly take the form of commits (direct modification of text files), pull requests (requests to an organization to integrate suggested changes to a text file), and issue creation and comment (asking or answering a question on a project repository). Culturally, user interactions on GitHub depend on agreed-upon practices and discourses, specifically when a user raises an issue, responds to it, or concludes (closes) it (Tsay et. al., 2014).
28GitHub is also a combination of read-write texts and read-only texts. The read-only texts consist of the main text files of the repository, while the read-write texts are composed of all the discussions and suggestions taking place in the issues and pull requests sections. Drawing from literary theory, this distinction allows us to identify the more authoritative text and the more negotiable ones (Barthes, 1970).
29We now turn to the analyses of the three repositories, in order to highlight which kinds of strategies are deployed by the parties taking part in discussions over style guide design and implementation.
30As pointed out by a user, the airbnb/javascript issues page presents itself as much as a question-and-answer platform rather than as a traditional bug-reporting and fixing platform10: « Hi! First off, thanks for this package. Also, I’ll preface this with: I’m not 100% sure I’m using the react/whitespace option correctly, so this is more of a question than a bug report. » (mylestan, user)
31The airbnb/javascript style guide consists in a main README.md, with all the style rules immediately available at first glance, along with an eslint configuration file as the result of the closed-source work of a private company. Discussions of said style guide take the form of bug reports on eslint11—the underlying linter for the JavaScript language, which takes as a input a configuration such as airbnb/javascript—, individual projects12 or the guide itself13, even though issues that are labeled as “bugs” represent less than 1% of the total issues opened. In this case, bugs are understood as external inconsistencies between the eslint output and airbnb/javascript’s guidelines. What would be deemed inconsistencies internal to the guide itself are labeled as editorial, reflecting a broader concern with communication and understanding of concepts, individual perspective, and paradigms over strict technical implementation issues. These labels can be created by the repository owners, but GitHub provides defaults14.
32Indeed, the unique aspect of airbnb/javascript is its dependency on the internal, well-organized structure of a private company. The constitution of the rules are, therefore, not up to debate. Such an implicit, private, out-of-reach existence of the origin of the guide is made explicit both by the creator of the publicly available guide, for whom the pronouns we and our do not refer to the open-source community of commenters and contributors, but rather to the internal team at Airbnb15, as well as references by both parties in discussions to the practices of the company ( « airbnb pushes for […] » (KayakinKoder, user)16, « I’d like to see this covered by Airbnb’s standards » (rdsedmundo, user)17) or to the codebase from which the style guide emerged18 (see figure 2).
Figure 2. ljharb’s emphasis on airbnb’s ownership of the style guide through the pronoun “our”.
33On a chronological level, we see that discussions focusing mainly on style conventions (mostly issues #1-#40, the earliest of the repository) are those in which most of the interactions happen between Airbnb employees and take place as multi-sided discussions on how to improve the guide through group decision (« I vote we go with parseInt because it’s explicit. », hshoff, member)19 or on bug- and tool-fixing20. What we see here is a private company using the tools and infrastructure of open-source processes embedded in GitHub to improve their productivity by writing internally consistent code (Kalliamvakou et. al., 2015), while, in a second moment, asking community members for their inputs without promising to implement them21.
34From this early period of a public interaction between fellow members of the same private organization, to the current situation of a large-scale interaction of distributed individuals and organizations over one of the most popular JavaScript style guides, the discursive strategies of both the maintainers and of the commenters and contributors have shifted. This is due in part to the fact that the creation of the styleguide is not collaborative, in the open-source sense of the term. Since a negotiation leading to a possible change of mind of the maintainer isn’t possible, the alternative chosen by the Airbnb team is the didactic explanation of non-negotiable rules, shifting the interactions from a negotiation to an explanation, in which the outcome of the exchange is ultimately the alignment of the user to the views of the maintainer (see figure 3).
Figure 3. The maintainer of the project explains the rule, labels it and offers to address any issues encountered.
35One other example is featured in the explanation of an early issue opened on the style guide about the broader need for style guides; the creator responds with a pedagogical métaphore filée of painters and fine artists rather than logically, rationally approaching the need for consistent codebases22.
36Along with this desire for the maintainers of the project to explain, rather than discuss, the conclusion of this particular argumentation also sheds light on the forking mechanism as used in a discursive situation; forking by an unsatisfied user acts as an end-all conclusion to the debate, in which another discussion is created, taking as its axiom the contentious proposals evoked in the base branch (see figure 4)23.
Figure 4. The author of the issue concludes the discussion by pointing participants to their fork.
37Additionally, a particular aspect of airbnb/javascript is the progressive inclusion of why such a rule has been decided in the read-only README.md24. By coupling exhaustivity with justification, the main task remaining for the maintainers of the project is to continue the explanation of why things are the way they are25.
38The case of prefer-default-exports highlights the pattern of a maintainer repeating the same justification for recurring questions (« […] a default export is what a module is, and named exports is what a module has[...] »26, « it’s either what the module is, and thus the default export, or it’s something the module has, and thus a named export »27, « As to your specific question - a default export is what a module is, and a named export is what a module has »28, ljharb, collaborator). Bug reports are presented as misunderstandings from the commenter’s point of view, asking the maintainers, not to justify their style choices, but rather to explain how one can write code that would better match the style guide29. If that explanation fails, as in the prefer-default-export examples above, another strand of conversation is started by one of the core maintainers, user ljharb—himself a former Airbnb employee, and then member of TC39, the technical committee in charge of the design of ECMAScript, of which JavaScript is an offshoot. These conversations essentially consist in him providing ad hoc explanations when external users are confused about the purpose of a rule or, even further, in re-organizing their code30. In this case, ljharb not only acts as a community manager rather than a project maintainer per se, but also eschews any discussions based on subjective preferences by providing a technical solution to any question asked, therefore showing that the airbnb/javascript style guide is not only exhaustive, consistent, but also implementable (see figure 5).
Figure 5. The main collaborator ljharb justifies the style guide as both a reasonable and technically efficient solution.
39This shift, from the stylistic to the technically feasible, is a recurring pattern which we’ll also observe under different manifestations in the standard/standard and prettier/prettier projects.
40In airbnb/javascript, then, the technical environment of GitHub issues have been repurposed from actual bug-tracking for Airbnb’s employees, towards a didactic platform focused on explicative discourse, in a balance of both closed-source documents and open-source practices. The combination between one canonical document—uneditable beyond those with privileges, despite GitHub’s pull request mechanism—which exhaustively covers almost all controversial use-cases in the language, along with a skilled maintainer explaining issues to the commenters individually, and, ultimately, the recourse to the process of forking as a concluding argument.
41Contrary to airbnb/javascript, , standard/standard puts forth the standard software, an immediate, “out-of-the-box” solution which applies the project’s rules to any file where the program is executed31—while airbnb/airbnb only describes, standard/standard implements. The overall approach comes out of a more traditional open-source pattern, initiated and spearheaded by a single individual, feross, which then turned into a proper GitHub organization once enough community traction had been garnered32, as opposed to the original, single-user project.
42The self-stated goal of standard/standard of « no configuration »33 has led its maintainers (mainly feross, along with rotating members such as linusU and rstacruz) to inflect their discourse under the influence of technical efficiency, rather than rule justification as airbnb/javascript does. Indeed, the rules themselves are both stated by feross as well as discussed by the community—groups of users, members and contributors—for each release of the package. By leaving open the possibility of modifying their style rules, and subsequently making them immediately enforceable by their standard binary, the discursive focus isn’t so much the number of discussions of so-called “religious” issues, known for the amount of devotion and heat that they attract (e.g. semicolons, « I was so caught up in negative thought loops that I did not think to research for community-forked modifications of "standard" that bless the use of semicolons. », PythonProdigy, contributor34, along with parentheses35, indentation36), but rather on technical implementation, alternative possibilities and community support, in a form of practical discourse. This approach to creating whole new style guides when one disagrees with a stylistic opinion emphasizes that the most productive issues of standard/standard are those based on a discussion around implementation, rather than a negotiation around style itself, again a prevalence of practical discourse over a theoretical, or aesthetic one (see figure 6).
Figure 6. A contributor brings up the main point that a style guide’s existence is to not have to deal with opinions.
43The first category of arguments laid out in the standard/standard repository is related to the actual, technical feasibility of the arbitrary37, but not nonsensical, rules laid out in the README.md. The status of feross as « benevolent dictator » (jprichardson, member)38 nullifies most of the arguments (e.g. « All very subjective though. I think @feross will just have to pick something :) » 39), the remaining of which can sometimes be thoroughly assessed (« The reason being is that with only a single argument, the function is much easier to read without parens. Some folks who don't like this might argue about expansion and having a bigger diff when adding arguments down the road. », KevinGrandon, contributor)40. Given this status of most rules being somewhat indiscutable, upon what does the agreement of standard/standard rules rely? The status of the project as a convenient wrapper (i.e. a seamless intermediary object in a developer’s workflow) around eslint poses that core technology as one of the final assessments of the validity of a given argument (e.g. « Probably better off making your case at eslint first, then coming back here » (dcousens, member) 41). While this effectively avoids bikeshedding42 in cases where the ultimate goal is to settle with one choice rather than debating multiple of them, this technological dependency also prevents some changes wished for by the community (see figure 7)43.
Figure 7. The standard/standard creator defers the resolution of the discussion to its technical impossibility in the underlying eslint software.
44If the ease-of-use of the standard/standard package does not convince a commenter to abandon their stylistic preferences, then the strategy of the maintainers to solve this negotiation is to redirect them towards another part of the ecosystem, be it the direct configuration file which implements all of the style rules44, or the adoption of other packages maintained by the standard organization45, bypassing the forking argument seen in airbnb/javascript (see figure 8).
Figure 8. One of the standard/standard members points an unsatisfied user towards appropriate forks of the project.
45Different from the dismissive tone of the airbnb/javascript maintainer’s repository, this redirection is an acknowledgement of the fact that opinions matter less than building a community, in line with the open-source ethos of group participation (e.g. the use of the we pronoun by feross46). This emphasis on community-building as a part of the overall strategy of standard/standard also affects their discursive strategy (see figure 9).
Figure 9. standard’s owner feross highlights the project’s approach to community in setting the stylistic guidelines.
46With a set of rules overwhelmingly decided upon by feross, some rational argumentations for the modification of these rules, the reliance on eslint as a ground for whether or not a rule can be applied, and the redirection of unsatisfied, or unconvinced community members towards other packages of the standard ecosystem (such as standard/standardx, standard/semistandard or standard/doublestandard) the last remaining kind of argument deployed for the adoption or rejection of style rules is the extent to which the community is using the existing rules.
47On the one hand, this project has garnered visibility and is deeply embedded in an institutional network of projects using the standard/standard guide47, including GitHub itself, and such a network provides credibility by association; these have been documented in order to further grow the community of users48.
48In practice, the biggest role that the community has in the negotiation of style guides is in whether or not any change in the guide would be a breaking change, and for how many projects using standard/standard, a requirement also known as backwards compatibility in the software industry. Used by project maintainers ( « This is one of those decisions that we can’t revisit. Nearly every repo that uses standard would break, and that’s not acceptable – even with major version bump. » (feross, member)49, « Although personally I agree with the fundamental reasons that you argue for this. As it stands, this would be so much of a breaking change, it will never be accepted. » (dcousens, member)50). The closing argument is then the number of existing projects which would have to refactor their code in order to comply with the new rule, and is often the last comment to take place on an issue before that issue is closed51.
49The discursive strategies that the commenters and maintainers deploy in standard/standard revolve around issues of convenience, which have enabled a certain form of technical path-dependency52. The figure and work of feross, both agreeable and engaging in his exchanges and unilateral in his decisions, include in their discourse references to technical limitations in order to bypass subjective issues. Indeed, while the affordances of eslint are inherently digital, the adherence of a silent majority of standard/standard users is represented in a quantified manner, through unit tests resulting in a percentage of organizations and packages failing or passing said tests. Such an approach seems to manifest itself as the reification of community choices in order to increase its effective discursive power. Effectively, they rely on the extensive adoption of the rules—as they feature prominently the fact that standard/standard is used by organizations such as GitHub itself, NodeJS and Gov.uk—, while airbnb/javascript relies on their extensive applicability.
50Prettier is developed by Facebook employees, itself the maintainer of the react project, the most popular front-end development framework by the end of 201953. Along with this institutional backing and internal success54, prettier/prettier presents three specificities which differentiate from airbnb/javascript and standard/standard. First, it doesn’t offer a clear and accessible style guide itself, and its README.md only contains one example to show the kind of work prettier/prettier does. Second, what it does is essentially different from the two previous examples, since it analyzes the source code, parses it and its inconsistencies and entirely reformats it according to internal rules—neither airbnb/javascript nor standard/standard offer default reformatting solutions. Finally, its parsing capabilities are not restricted strictly to JavaScript, unlike other Such a language-independent approach (dealing directly with AST, short for Abstract Syntax Trees, a context-free structure) might explain its popularity across different languages, while the two other projects focus mainly on JavaScript. So, while presenting itself as a code formatter rather than as a style guide55, it is one still, through its enforcement of rules, much more thorough than its alternatives.
51Along with the absence of a clear, read-only, style guide announcing, if not explaining, the individual style decisions, the maintainers of the project (e.g. jlongster, vjeux, founders of the project while Facebook employees) tend to engage in conversations about the possibility to change existing styling rules56.
Figure 10. An open discussion of stylistic changes by a project contributor.
52This willingness to change the behavior of their tool, along with its automation power and the founders institutional capital might explain the fact that the prettier/prettier repository has about four times more issues in total than the two other repositories examined, with more thoughtful, thorough and rational explanations57, including detailed description of desired behaviour58. Still, these strategies do not always suffice to overcome personal preferences : « The solution is simpler than it looks: don't use Prettier » (odahcam, collaborator)59. In particular, prettier/prettier distinguishes itself by allowing contributors to open up discussions and negotiate changes not through pure discursive argumentation, but rather by offering implementations of an alternative60, including alternatives which concern “religious” issues61—in effect, long and elaborate argumentation always require code examples62.
Figure 11. User Jessidhia arguments the ternary discussion with a code snippet.
53The process seems to be as follows: prettier/prettier formats a given code, the developer who might not agree with such a formatting result opens up an issue, argues for her opinion through the presentation of practical use-cases and actionable pull-requests and, depending on the technical soundness of the solution and the large size of the user base already using the package, might get their change accepted. Finally, while the thoroughness and politeness of most replies on this repository point towards a healthy community, it should be noted that the verbosity of some of the contributions are perceived as intimidating for comments who consider they English level sub-par ( « I didn’t read the whole conversation above because you guys really know how to speak English well slightly_smiling_face Makes me envy a bit » (seahindeniz, commenter)63). While prettier/prettier is the location of the most discussion of the three projects examined, the room left for discussion incidentally creates a space in which only those with communicative competence are heard.
54Without a reference document, and with the recurring statement that “readability” and “preference” are subjective arguments, prettier/prettier also relies on technical arguments to solve debates, sometimes even before they happen. The seamlessness of the Prettier’s work, as both a visible output and invisible process, can eschew style debates altogether: « Hi @jlongster, just would like to chime in and let you know that your project has hit the jackpot and solved something that even (the self-proclaimed) Standard and Semi-Standard couldn’t solve for me […] Easy team-wide style enforcement that’s based on an unbiased 3rd party algorithm to produce a one and only definitive way to indent absolutely each line of code »64 (gsklee, user). This immediacy of programmatic action, and its adoption in return, is reminiscent of the power of interfaces in their ambiguity, in which a self-implementing tool acts as its own rationale (Galloway, 2012). Once again, the negotiation over the stylistic validity of the automated style guide is superseded by its immediate technical applicability.
55Indeed, most of the official discourse of prettier/prettier (through its website and through oft-referenced conference talks) presents the project not as a style-guide per se, but as an AST-parser and printer. These definitions again steer the debate towards technical argumentation, rather than adoption by the community (such as standard), or explanation of practical rationale (such as airbnb); explicitly mentioning AST representation often becomes the grounds for the final stylistic decision ( « it will be interesting to figure this out because the way it formats it now is because of how the AST is structured, which is based on operator precedence » (jlongster, member)65), and sometimes even used as counter-examples66.
56prettier/prettier’s argument is that it is both opinionated and efficient, which has led to the early development of a “no-options” philosophy67. This position has moved from a read-write text, discussed by both maintainers and commenters, to a read-only text on the official website68. sbsequently, it has been used as an argument to respond negatively to requests for personal additions (« @JoshMcCullough We won't add options unless extremely necessary. Please read https://prettier.io/docs/en/option-philosophy.html »69 [diuailibe, member]), alongcwith a request of responding through programming languages, rather than human languages70. While standard/standard shares this approach of « no-options », their justify it by broadening the scope of what is considered acceptable (standard/standardx, standard/doublestandard), therefore growing the community, and not relying on the fact that only one single project should exist. Thus practices found in the airbnb project echo Goody’s investigations of the immutability and canonization of written texts. Because the tool gets its value and usefulness from its invariability—and the communities which depend on its invariability71—, discussions around the tool itself can be made moot.
57A final feature of the prettier/prettier discussions stems from both their exhaustiveness, the popularity of the project and the maintainers’ decision to no longer accept options72. This results in several seemingly intractable discussions with over 100 comments, while the majority of other issues have less than 10 comments each73. These issues bring up the original tension between subjective and objective criteria of a style guide, in which each writer has an opinion74 on what is the best way to solve a given dilemma75, either as emotional, subjective statements76 ( « This issue is ridiculous. Just fix that » [thalesfsp, user]77), or along with examples78 and suggestions of pull requests.
Figure 12. Prettier commenter providing both a normative and subjective opinion.
58The pattern we see here is that, due to the popularity of the project, first-time users weigh in on complicated debates, engage in the conversation with other commenters for a couple of replies, and then drop out of the discussion altogether. Coupled with the original intent of the maintainers to integrate community-argued changes, these issues remain open for all to chime in.
59On the one hand, these discursive strategies seem to parallel the pattern of the dreaded bikeshedding79, in which anyone can chime in, and including linguistic patterns such as « just my two cents », « IMHO » (“in my humble opinion”), « just gonna weigh in here », apparently. As such, they don’t appear very productive due to repeated arguments80 and they seem to affect the maintainer’s ability to discuss ( « The Prettier issue tracker naturally attracts and concentrates code style discussions. They’ve been moved from basically everywhere to here. I think this is a big factor to the maintainer burnout I’ve seen lately » [lydell, contributor] 81).
60On the other hand, however, the overall quality of arguments presented (combining use cases, opinions and responses to previous proposals) has led to a switch in the discursive strategy in which the discussion is summed up by the maintainers (« Summarizing a bit, it seems we have a handful of motivating examples and another handful of solutions now. », rattrayalex, member)82 in order to provide moderation to the debate or to be pursued exclusively by the maintainers (« I've temporarily limited conversation the issue from spam/off topic so we can discuss between @prettier/core developers, I would like to hear everyone here, this problem has been present for a very long time and we need to give an official answer. » alexander-akait, member83). The result is that the prettier team, emerging from community-created discursive noise inherent to any popular open-source projects, engages less in terms of justifying the existing style, but in gauging how feasible an alternative is, once this discursive noise reaches a particular threshold, acting as a filter to turn quantitative input into a qualitative theoretical argument.
61Style guides existing on GitHub have to tend to the specific issue of convincing individual users with strong subjective preference of adopting their recommendations in the midst of a technical environment which favors copying and customization. Starting from an approach of arguments based on the typology of communicative competence, we’ve highlighted that, beyond emotional and subjective statements as well as social justification of institutional origin or belonging, rational statements and commands are being affected by the technical milieu in which programmers write, read and work.
62Particularly, we can see that there are multiple strategies which closely involve either source code examples, or executable code. Source code examples acts as a prime argument when human languages fail to communicate the objectivity of their statement, and is often required by all parties of a discussion to base their statements on. Still, those comments are often overlooked: the requirement of readability, crucial to a decision in style guides, re-appears in all its subjectivity when it comes to reading the source code example provided, pitting the argument in multi-sided subjective perspectives. In airbnb/javascript’s case, when re-written code can act as an argument to the validity of the style guide, it is because previous code didn’t comply, and became compliant again through the maintainers work.
63If source code seems to be a novel type of objective argument and yet remains trapped in subjective appreciation, executable code can act as its own argument. standard and prettier both rely on the fact that their style guides work, that they are efficient in what they do. Any change must first and foremost comply with the feasibility of the argument, no matter how sound the conceptual proposal is. As we’ve seen, prettier/prettier can replace a didactic guide by an efficient tool, while airbnb/javascript has to rely on a strict didactic approach, on top of providing an eslint configuration file, leading us to the consideration that code as actionable words is perhaps the most efficient in the adoption of a project, and therefore shifting a process of negotiation in which all parties are equal, to one in which the maintainer has a larger bargaining power and, more often than not, only accepts to discuss why such a decision has been made, and not whether it should be changed.
64In terms of GitHub as a platform, we’ve observed a multiplicity of approaches, preventing a unilateral interpretation of how technical environments can entirely shape the nature of a discussion. GitHub’s platform seems to be able to provide multiple kinds of discussions, ultimately geared by the social role of the maintainers and the ability to toggle between references to read-only (canonical) texts rather than keeping the discussion within read-write (discussion) texts.
65Furthermore, GitHub does provide the interesting case of a highly-networked, highly-transparent working environment. This study has examined the role of a quantified community in argumenting for or against a particular stylistic choice, particularly present in standard/standard’s strategy; it is necessary to mention the entangled nature of cross-references to other projects hosted on GitHub. Beyond naming existing alternatives84, being able to reference another style guide on an issue85, or to mention explicitly the name of a maintainer of one given style guide on a different one86, facilitates the interactions of maintainers87 and allows for an intricate web of intertextualities, allowing discussions happening on a given repository to act as arguments for another repository, or vice-versa. This added layer of complexity is beyond the scope of the current study, but offers a promising field for future research.