Php

Despite testcases, syntax errors still find their way into our commits. - Maybe it was a change in that bash script that wasn't covered by tests. Too bad our deploys relied on it. - Maybe it was just a textual change and we didn't think it was necessary to run the associated code before pushing this upstream. Too bad we missed that quote. Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to change because in the - Best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, as you already moved onto other things. - Worst case: your error goes unnoticed and hits production. Git offers commit hooks to prevent bad code from entering the repository, but you have to install them on a local per-project basis. Chances are you have been too busy/lazy and never took the time/effort to whip up a commit hook that could deal with all your projects and programming languages. That holds true for me, however I recently had some free time and decided to invest it in cooking up ochtra. One Commit Hook To Rule All.

In loosely typed languages such as JavaScript or PHP, using `==` to compare values is bad practice because it doesn't account for type, hence `false == 0 == '' == null == undefined`, etc. And you may accidentally match more than you bargained for. If you want you can limit unintended effects & bugs this may lead to, it's often wise to use `===`. In the process of converting legacy codebases to use these triple equality operators, I find that as a rule of thumb you can almost **always force triple equality** in case of comparing variables against **non-numerical strings**. There's just never a case where you want the text `'Kevin'` to pass for the boolean `true`, or the number `3`. And if that can still happen in your legacy codebase, you'll want to limit those risks rather sooner than later. Even if that breaks things that now accidentally, work.

PHP's strrev is not safe to use on utf-8 strings because it reverses a string one byte at a time. So if a character consists of multiple bytes it cannot be preserved as an entity in the reversed result. There is no Multibyte String alternative to strrev either.

> "Simplicity is prerequisite for reliability." [Edsger W. Dijkstra](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html) As our experience grows, we learn from past mistakes and discover what's truly important in reliable systems. When designing systems, simplicity is an often heard mantra, but it isn't getting applied nearly as much as spoken of. I'm guilty of this too. I think it's mainly because engineers love to, well, engineer :) and will naturally try to [outsmart problems by throwing more tech at it](https://teddziuba.com/2010/12/the-3-basic-tools-of-systems-engineering.html).

This article in 50 words: I used to prefer spaces vs tabs, now I don't care so much, think it's more important that you can easily switch on a per-project basis. Have some thoughts on how conventions should be established, and I'll demonstrate bash code that can convert your codebase to a new standard.