I’m starting a little mini-series about some of the “best practices” I’ve tried out in my real-life open source software development. These can be specific tools, checklists, workflows, whatever. Some of these have been great, some of them have been not so great, but I’ve learned a lot. I wanted to talk a bit about the usability and assumptions made in various tools and procedures, especially relative to the wider conversations we need to have about open source maintainer burnout, mentoring new contributors, and improving the security and quality of software.

So let’s start with a tool that I love: Black.

Black’s tagline is “the uncompromising Python code formatter” and it pretty much is what it says on the tin: it can be used to automatically format Python code, and it’s reasonably opinionated about how it’s done with very few options to change. It starts with pep8 compliance (that’s the python style guide for those of you don’t need to memorize such things) and takes it further. I’m not going to talk about the design decisions they made but the black style guide is actually an interesting read if you’re into this kind of thing.

I’m probably a bit more excited about style guides than the average person because I spent several years reading and marking student code, including being a teaching assistant for a course on Perl, a language that is famously hard to read. (Though I’ve got to tell you, the first year undergraduates’ Java programs were absolutely worse to read than Perl.) And then in case mounds of beginner code wasn’t enough of a challenge, I also was involved in a fairly well-known open source project (GNU Mailman) with a decade of code to its name even when I joined so I was learning a lot about the experience of integrating code from many contributors into a single code base. Both of these are… kind of exhausting? I was young enough to not be completely set in my ways, but especially with the beginner Java code, it became really clear that debugging was harder when the formatting was adding a layer of obfuscation to the code. I’d have loved to have an autoformatter for Java because so many students could find their bugs easier once I showed them how to fix their indents or braces.

And then I spent years as an open source project maintainer rather than just a contributor, so it was my job to enforce style as part of code reviews. And… I kind of hated that part of it? It’s frustrating to have the same conversation with people over and over about style and be constantly leaving the same code review comments, and then on top of that sometimes people don’t *agree* with the style and want to argue about it, or people can’t be bothered to come back and fix it themselves so I either have to leave a potentially good bug fix on the floor or I have to fix it myself. Formatting code elegantly can be fun once in a while, but doing it over and over and over and over quickly got old for me.

So when I first heard about Black, I knew it was a thing I wanted for my projects.

Now when someone submits a thing to my code base, Black runs alongside the other tests, and they get feedback right away if their code doesn’t meet our coding standards. It hardly any time to run so sometimes people get feedback very fast. Many new contributors even notice failing required test and go do some reading and fix it before I even see it, and for those that don’t fix issues before I get there I get a much easier conversation that amounts to “run black on your files and update the pull request.” I don’t have to explain what they got wrong and why it matters — they don’t even need to understand what happens when the auto-formatter runs. It just cleans things up and we move on with life.

I feel like the workflow might actually be better if Black was run in our continuous integration system and automatically updated the submitted code, but there’s some challenges there around security and permissions that we haven’t gotten around to solving. And honestly, it’s kind of nice to have an easy low-stress “train the new contributors to use the tools we use” or “share a link to the contributors doc” opening conversation, so I haven’t been as motivated as I might be to fix things. I could probably have a bot leave those comments and maybe one of those days we’ll do that, but I’m going to have to look at the code for code review anyhow so I usually just add it in to the code review comments.

The other thing that Black itself calls out in their docs is that by conforming to a standard auto-format, we really reduce the differences between existing code and new code. It’s pretty obvious when the first attempt has a pile of random extra lines and is failing the Black check. We get a number of contributors using different integrated development environments (IDEs) that are pretty opinionated themselves, and it’s been freeing to not to deal with whitespace nonsense in pull requests or have people try to tell me on the glory if their IDE of choice when I ask them to fix it. Some python IDEs actually support Black so sometimes I can just tell them to flip a switch or whatever and then they never have to think about it again either. Win for us all!

So here’s the highlights about why I use Black:

As a contributor:

1. Black lets me not think about style; it’s easy to fix before I put together a pull request or patch.





2. It saves me from the often confusing messages you get from other style checkers.





3. Because I got into the habit of running it before I even run my code or tests, it serves as a quick mistake checkers.





4. Some of the style choices, like forcing trailing commas in lists, make editing existing code easier and I suspect increase code quality overall because certain types of bug are more obvious.

As a an open source maintainer:

1. Black lets me not think about style.





2. It makes basic code quality conversations easier. I used to have a *lot* of conversations about style and people get really passionate about it, but it wasted a lot of time when the end result was usually going to be “conform to our style if you want to contribute to this project”





3. Fixing bad style is fast, either for the contributor or for me as needed.





4. It makes code review easier because there aren’t obfuscating style issues.





5. It allows for very quick feedback for users even if all our maintainers are busy. Since I regularly work with people in other time zones, this can potentially save days of back and forth before code can be used.





6. It provides a gateway for users to learn about code quality tools. I work with a lot of new contributors through Google Summer of Code and Hacktoberfest, so they may have no existing framework for professional development. But also even a lot of experienced devs haven’t used tools like Black before!





7. It provides a starting point for mentoring users about pre-commit checks, continuous integration tests, and how to run things locally. We’ve got other starting points but Black is fast and easy and it helps reduce resistance to the harder ones.





8. It reduces “bike shedding” about style. Bikeshedding can be a real contributor to burnout of both maintainers and contributors, and this reduces one place where I’ve seen it occur regularly.





9. It decreases the cognitive overhead of reading and maintainin a full code base which includes a bunch of code from different contributors or even from the same contributor years later. If you’ve spent any time with code that’s been around for decades, you know what I’m talking about.





10. In short: it helps me reduce maintainer burnout for me and my co-maintainers.

So yeah, that’s Black. It improves my experience as an open source maintainer and as a mentor for new contributors. I love it, and maybe you would too? I highly recommend trying it out on your own code and new projects. (and it’s good for existing projects, even big established ones, but choosing to apply it to an existing code base gets into bikeshedding territory so proceed with caution!)

It’s only for Python, but if you have similar auto-formatters for other languages that you love, let me know! I’d love to have some to recommend to my colleagues at work who focus on other languages.

// ==UserScript==
// @name        Book review header generator
// @namespace   tko-bookreview
// @description Takes any librarything book page and gives me a nice link to the book with cover and author details
// @include     http://www.librarything.com/work/*
// @version     1
// @grant       none
// ==/UserScript==

// Get all the data we'd like to display at the top of a review
var coverimage = document.getElementById('mainCover').outerHTML;
var title = document.getElementsByTagName('h1')[0].innerHTML;
var author = document.getElementsByTagName('h2')[0].innerHTML;
var librarythinglink = document.URL; 


// Trim down the title and author info
title = title.replace(/ *<span .*<\/span>/, '');

author = author.replace(/href="/, 'href="http://www.librarything.com');
author = author.replace(/<hr>/, '');

// Generate the code for this book
var reviewheader = '<a href="' + librarythinglink + '">' + 
   coverimage + '<br />' +
   '<b>' + title + '</b></a> ' +
   '<em>' + author + '</em>';

// Add code around this for embedding it into the page
var textbox = '<h4>Review Code</h4>' +
	'<textarea name="embedHTML" onFocus="this.select();" rows="5" ' + 
	'style="width: 250px;" wrap="virtual">' + reviewheader + '</textarea>';


// Find a good spot and add it to the page
var insert = document.getElementsByClassName('gap')[0];
insert.outerHTML =  textbox + insert.outerHTML;

you will probably find it easier to do a clean install from source instead.

Pumpkins chez Dan 2010

// ==UserScript==
// @name           Blog flickr set
// @namespace      tko-flickr-set
// @description    Make cut and paste code for blogging entire sets of flickr photos as thumbnails
// @include        http://www.flickr.com/photos/*/sets/*
// ==/UserScript==

var thumbsHTML = document.getElementById('setThumbs');

var allImages = thumbsHTML.getElementsByTagName('a');
var title = document.title.replace(/ - a set on Flickr/, '');

var code = '<h2><a href="' + location.href + '">' + title + '</a></h2>';

for (i = 0; i < allImages.length; ++i) {

	code += '<a href="' + allImages[i].href + 
	'" title="' + allImages[i].title + '">' +
	allImages[i].innerHTML + '</a>';

	if (i > 0 && (i+1) % 6 == 0) {

		code += '\n';
	}
}

// Insert after the date
var insertPlace = document.getElementsByClassName('vsDetails')[0];

var newBox = '<h4>Embed Code</h4>' +
	'<textarea name="embedHTML" onFocus="this.select();" rows="5" ' +

	'style="width: 250px;" wrap="virtual">' + code + '</textarea>';

insertPlace.innerHTML = insertPlace.innerHTML + newBox;

Instructions

1. Teachers don't have the time. This is especially true at the elementary level, as illustrated by Diane Scaiff's excellent summary of teachers work hours in Ontario. Adding stuff to the curriculum takes time that many teachers just don't have.
   
   
2. Schools don't have equipment. Computers are expensive to buy, maintain, and they are common targets for theft.
   
   
3. People think computer science is hard. Often they think it requires advanced math. You do not need significant math skills to program, despite this perception. When I was teaching basic programming to my sister's friends, we started with web quizzes. The only math was simple addition. But this perception intimidates a lot of people who haven't tried it.
   
   
4. Teachers don't have the knowledge and skills required to teach computer science. And, as stated before, they don't have time to learn and may be intimidated by the perception that computer science is incredibly difficult. This is especially true since many elementary school teachers feel that they are weak in math (at least according to the gentleman who started JUMP math tutoring).
   
   
5. People don't think kids will be able to do more "advanced" stuff. This irks me. Kids are a whole lot smarter and more capable than many people take them for.
   

1. Why else don't we teach younger children computer science?


2. What can we do to alleviate these problems?