TD toolkit: Prettier/Black

TL;DR

Welcome to my first in a series of articles that I intend to write to share some tools and techniques that I've gathered over the years of being a TD. My primary hope is that some find these articles useful, though I have a more self motivated intention of improving my writing abilities as well.

I recommend the use of Prettier and/or Black for any TDs who wish to follow established conventions. I hope, like me, you find these tools contribute to your development (not so clever pun intended!) as a programmer.

The TL; part starts here

I'd like to start off by saying that I will not be going into detail about linting as a concept. Indeed given the myriad of sources available, any attempts by me to quantify such a deep subject would be futile. Having said (written?) that, I will be elaborating on how linting has helped TDs such as myself to achieve a more optimized and standardized code style.

Our roots

Historically, within the spectrum of python and pipeline there never existed a single set of pre-established conventions. By and large, TDs used to be artists who simply adapted to more technical pursuits and perhaps picked up coding along the way. Indeed some of the most successful TDs that I've had the pleasure of interacting with, tended to be self taught. Adding this majority of self taught knowledge to a distinct lack of software development methodologies, one can imagine how pipeline repositories tended to look back in the day.

The fam's gettin' bigger

As pipelines started evolving and expanding to include more aspects, the role of a TD too expanded, to the point where more "traditional" developers could integrate into the team and contribute effectively. With the ingress of such talented "core" devs, also came ideals and methodologies with respect to how software development in general should be approached.

Method to madness

Coding conventions began to be adopted especially PEP8, agile methodologies began to be followed and newer standards were integrated to the point where any repo in pipeline nowadays would almost certainly be near indistinguishable from any traditional software repository.

To lint? or not to lint?

Pipeline code tends to change rapidly, everyday. This is in part due to the rapid nature of changing workflow trends within visual effects, and in part to do with a TDs basic desire to optimize or build on existing workflows. As one can imagine, with such rapid changes and minimal validation, things used to break.....a lot. Within a time sensitive field such as visual effects, any substantial delay in delivery caused due to these "technical" issues could potentially end a company. Enter TDD and linting to save the day.

I'm not lazy, i'm a programmer.

There is an old adage prevalent in software development.

A lazy programmer, is a good programmer

While it's important to understand and -at least, attempt- to follow some form of coding conventions. Such ideals do tend to take a backseat especially during high pressure delivery situations. Companies try to counter said lack of importance to convention by implementing validations, minimum coverage requirements etc. We are not here to debate the pros and cons of such validations, there are passionate advocates on both sides of that fence.

However, what if both parties could get what they want? What if a developer could just focus on the functionality of their code, without truly having to worry about line widths, indentation levels etc and the company still got standardized code which follows required conventions?

Enter.....Prettier

Prettier is an opinionated code formatter

As mentioned previously, a TDs role has expanded to include many aspects. One of these main aspects includes a healthy amount of developing in languages such as Javascript with HTML/CSS etc. As one can imagine, with a syntax such as HTML where white-space means nothing, it would be very easy to complicate the structure really quickly.

Prettier aims to eliminate such complexities by auto formatting any supported language with the majority accepted convention. ES2017 support for example. And it is a tool that I configure first whenever I begin a new project.

But what about Python?

Once I started using Prettier, it became an in-disposable part of my development environment, so much so in fact that I got used to and started expecting the slight visual jump whenever my code was auto formatted on save. However, switching over to PyCharm to develop my pipeline models in Django, I distinctly felt the lack of this auto formatting. I was dismayed to realize that Prettier at the time of this writing does not support Python.

I began searching for a viable alternative to Prettier for Python and ended up on Black's github page. The following is the most succinct summary that I have ever come across:

Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

And that was that. `pip install black`, setup File Watcher and the rest is history.