Eyal N works on some code which relies on "bit matrices": 2D arrays of bits. Since they are working in C, in practice this means that they have one giant array of bytes and methods to handle getting and setting specific entries in the matrix.

One day, Eyal sat down to do a remote pair-programming session with a co-worker. It started out alright, but the hours ticked by, the problem they were dealing with kept showing thornier and thornier edge cases, and instead of calling it a day, they worked late into the night.

If there’s a hell for programmers, it probably involves C-style strings on some level. C’s approach to strings is rooted in arrays, and arrays are rooted in pointers, and now suddenly everything is memory manipulation, and incautious printf and memcpy commands cause buffer overruns. I'm oversimplifying and leaving out some of the better libraries that make this less painful, but the roots remain the same.

Fortunately, most of the time, we’re not working with that sort of string representation. If you’re using a high-level language, like Java, you get all sorts of perks, like abstract string methods, no concerns about null termination, and immutability by default.

Generating SQL statements is a necessary feature of many applications. String concatenation is the most obvious, and also the most wrong way to do this. Most APIs these days offer a way to construct SQL statements out of higher-level abstractions, whether we’re talking about .NET’s LINQ, or the QueryBuilder objects in many languages.

But let’s say you’re doing string concatenation. This means you need to have lots of literals in your code. And literal values, as we know, are bad. So we need to avoid these magic values by storing them in variables.

Don't you just love it when some part of your app just suddenly and magically STOPS working all of a sudden?

Our submitter David sure does (not). While working on his Android app, much to his surprise, he noticed that after one build, it wasn't displaying pop-up toast style notifications.