Niko, doko?

Java was first releases in 1996. After almost 30 years and more than 20 successive iterations of the language, it comes to no surprise that it has a few dusty corners and surprising quirks. One of them is the difference between == and .equals. If you come from more modern languages, such as Go, you might expect that new MyClass("a") == new MyClass("a")… but it is not the case! Reference equals (==) In Java == operates on references.

During my free time, I am developing javaimports , a goimports-like Java command line tool that auto-imports Java classes without relying on an IDE, a LSP or any kind of cache. I use it daily to write Java, pairing it with google-java-format to automatically format my code and add missing imports on save. Obviously, I need javaimports to run fast, which pushes me to look for ways to make my code, and Java command line applications in general, faster.

Over the past few years, auto-formatting utilities (that do code formatting for you) such as gofmt , black or google-java-format have become increasingly popular. While such tools undoubtedly provide some benefits when used from the start of a project, changing the code style of an entire codebase is hard. The larger it is, the harder it is to break through its inertia… Which begs the question: is it worth it?

As software engineers, our relationship with best practices is an evolving one. We start off unaware of what they are. One day, because someone told us or because we read about it somewhere, we discover them. This is usually where we start to revere them as some kind of holy scripture. The cleaner our code gets, the more obsessed we become. For many of us, it can take a while before we open our eyes again to the cold, hard truth: best practices are nothing but tools.

Writing code reviews, on GitHub or elsewhere, is a central part of a software engineer’s daily life. Yet, it is a task unlike any other: in addition to technical knowledge, a substantial amount of tact and subtlety is required in order to go past differences of opinion and establish a fruitful dialogue. This is of course true for both the one reviewing and the one being reviewed, but it is undeniable that, as the one initiating the discussion, the reviewer bears an even greater responsibility.

Honestly, when I need to write a quick and dirty script, my go-to language is Python. But the other day, as I realized I needed to write yet another small web scraper, I decided to forego Python’s BeautifulSoup to instead take a look at Go’s golang.org/x/net/html package. Needless to say, it is quite bare in comparison… But I also realized that it makes absolutely no concessions when it comes to strictly following the HTML specification1.

Go users out there are probably familiar with gofmt and it’s brother goimports (which actually uses gofmt under the hood). These are two little CLI tools (written in Go, of course), that have become core parts of many developers' Go workflow. Over time, I have personally grown very fond of these tools. They are undoubtedly great productivity boosters, but what I love about them is not so much their raw utility as their design.

Although I briefly mentioned the concept of range in my previous article about substitutions, I simply described them as a “set of lines”, on each of which the :substitute command would be called. But amongst the (much appreciated) feedback I received on reddit , some mentioned the fact that this somewhat hand-wavy explanation was not enough, and that I should elaborate. This in turn made me realize that everything about ranges was not clear for me.

I use Vim to edit text every day, and the good old :[range]s[ubstitute]/pattern/string/flags command is without doubt one of the commands I use the most. It is simple yet powerful, and when combined with the g flag allows me to replace everything I want on an arbitrary selection (or on the whole file using :%s/pattern/replacement/g). But I recently realized that, despite using it a lot, I was far from leveraging its full potential.