automated tool to help students, machine learning, acknowledging pylint, etc.
applies style to software architecture (supe macro), but doesn’t quite define style
architectural styles define a semantic interpretation whereby compositions of design elements, suitably constrained by the configuration rules, have well-defined meanings
but he seems quite limited by OOP / unix style
refers to McConnell, 2004: “the details of a specific method of structuring a program are much less important than the fact that the program is structured consistently”
The religious tone by excellence, mentions “heretic”, “heed the warning”.
claims that K&R is the one and only rationale needed
“First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.”
also provides a linter file for emacs
three levels of knowledge representation:
“mixed coding style is harder to maintain than bad coding style” -> this is what brings us to the automatic linters
he explains that style is more than aesthetics, and helps understanding
there are uniquivocal rules (everyone agrees on) (e.g. naming conventions)
there are also competing, yet equivalent styles: no real answers, so the answer becomes “consistency” which is enforced by linters
Tools like indent are a staple of softeng: it’s not about what is beauty, but what is knowable about it, and thus enforceable
Aesthetic value is not the same as readability
this is from: Posnett, Daryl, Hindle, Abram & Devanbu, Prem, (2011) “A Simpler Model of Software Readability”,
Gabriel argues against clarity and conceptual beauty as primary goals of software in favour of what the author calls “habitability.”
Gabriel, Richard, (1996) Patterns of Software, Oxford
js as an important part of the web
linters have warnings about bad code logic (i don’t care), and bad code style (i care)
doesn’t state what are “commonly accepted rules”
teams know about mistakes, because they’ve customized it
baseline: for large projects, custom static code analyzers are used
some guy’s master thesis from prague
there is a large gap between knowing the rules and following them: so we need tools not just to detect, but also to take action
the guy argues that style should be built into the language grammar
Of course, you will never enforce any style globally unless people have literally no choice
the important part is that it comes from the language, therefore limitation on the power of community in the sense that the community should be able to crowd-decide what is best.
foundational paper written in 1974, it surveys the beginning of modern style concerns (expression, structure)
sets the stage for an empirically-backed style checking process
difference between typographic and structural style
github papers
good references for ground work in OSS user contributions
Our study exploits data from GitHub, a super-repositoryof software projects containing millions of projects. GitHubis free for open source projects and implements an in-houseissue tracking system where users can file issues and tag theminto self-defined categories. The issue tracking system is easyto use and is systematically provided to all projects hostedin GitHub.
Rhetoric and technical language are on opposite endsof a language complexity spectrum: the former is stylisticallynatural; the latter is terse and concise. Issue discussions embodythis duality, as developers use rhetoric to describe technical issues.The style mix in any discussion can define group culture andaffect performance, e.g., issue resolution times may be longer ifdiscussion is imprecise.
findings:
We find that experienced users conform to project-specific languagenorms, popular individuals use overall GitHub language ratherthan project-specific language, and conformance to project-specific language norms reduces issue resolution times
technical language vs. community language (both subject to perceived language complexity)
project-specificterms and perceived language complexity exist, andsomeprojects have more project-specific perceived languagecomplexity than others.
as for users,
they gravitate towards the project languagenormandpopular users (measured by the number of timesthey are @mentioned in issue discussions) are betterrepresented by the GitHub global language model thanproject-specific language models.
a speech community describes a group of people who use language in a way that is mutually accepted among the group, which requires communitative competence (they must speak in a manner that is standard within the speech community—norm conformity) — less structured, end users
a community a practice (wenger & lave) have shared practices, membership is internally constructed, co-construction of personal and group identities, with a shared social/instrumental goal. Kleinnijenhuis describes networks of practice — more structured, developers of project
GitHub discussions are a push-and-pull effort betweenthe push to use technical language that is relevant to theproject, and the pull to provide a narrative which frames one’sposition through rhetoric
Based on these anecdotes, we hypothesize that a complexproject with project-specific code style requirements may bemore likely to useESLintorJSHint, while a smaller projectmay opt forstandardJSbecause it is easier to set up.While highly configurable tools likeESLintandJSHintrequire more effort in configuration, they may nullify disputesover code formatting and facilitate code review.standardJSrequires less initial effort from project maintainers and maybe appealing to new contributors who are familiar with thecommon code style. However, since its adoption likely entailedless configuration effort, maintainers may need to spend moretime on code review or address more issues about code styling.
commercial projects and corporations are influenced by the OSS style of working
We find that people makea surprisinglyrich set ofsocialinferences from the networked activity information in GitHub, such as inferring someoneelse’s technical goals and vision when they edit code, or guessing which of several similar projects has the best chance of thriving in the long term.
In the end, communication happens at the end of transparency: when the information isn’t readily available, when it is unclear. also signs of attentions.
there are users (regulars) and commenters (only post without opening issues or source code changes)
commenters are less polite than users, and more negative
commenters are also more aggressive (but only aggressive, actually; there is few variation in their emotion)
We found that developers raisedissues around contributions over both the appropriateness of the problem that thesubmitter attemptedto solve and the correctness of the implemented solution.
I’m only interested in the first part (appropriateness)
They also resort to external stakeholders: dependent projects or companies
Tsay et al. [23]found in a study of contributions in GitHub that a number of social and technical factors influenced the probability of a contribution being accepted. When contributions were highly discussed, contributions were much less likely to be accepted.
in the end it’s just a typology of discussions, not sure how useful
similar to [https://doi.org/10.1145/2568225.2568315]