You have probably already heard the horror stories of code interviews where they ask you to reverse a binary tree on a whiteboard. (if not check this blog post that I profoundly disagree with)

Well, a few days ago I was in that exact situation. And I had no idea what the interviewer was talking about. So what are these binary trees and why is it so critical that you know how to inverse them? Let’s find out.

A binary tree is a very simple data structure that as the name suggests looks like an upside-down tree.

This structure is mainly used for searching. For example, if we needed to find 4 in this structure quickly, we would need only to make 2 binary decisions. If we scale this up to 1000 nodes, we would only need about 10 choices. There are other options still, like self-balancing binary trees but let’s keep it simple at the moment, and just focus on balanced binary trees.

Ok so now that we know what it is let’s start with inverting a binary tree. What do we mean by that? It’s actually very straightforward. We turn this:

      4
     /  \
    2    7
   / \  / \
  1  3 6   9


     4
    /  \
   7    2
  / \  / \
 9  6 3   1


We flip the entire structure horizontally. So 7 and 2 are flipped, and the 2 children are also flipped. All the way down.

As we are good OOP developers, we are first going to start with our tree. A binary tree is nothing more than a collection of points, called nodes, with 2 children: a left and a right one. So first we are going to create a Node object.

Binary1.php

(I’ve added value to the object as well, just to give it a practical use)

Now that we have the Node object it’s time to create a tree.

Binary2.php

At this point we have a data structure that looks like this:

This is all set up, time to move on to the swapping. If we break the problem down to its core, we just want to swap the children of a node. Like this:

Binary3.php

We take the Node and create (and return) a new Node with the children swapped. We now have:

At first, glance that looks like we completed the task, but if you look a tiny bit deeper, you might see that we only inverted one level. The lower levels are in the same place (but on the other side of the branch).

To switch those we actually just have to repeat this process till we run out of levels. Now that sounds like a recursive function.

Binary4.php

The first thing to note is that our function signature changed. We now also accept null values. Why? Well once we hit bottom, there aren’t any children left. getRight() will return null. This null will indicate that we are at the end of our loop.

Binary5.php

This is that check for when we run into a null value as described above.

Binary6.php

This is the recursive method. Every time we pass this, we go one level deeper. If we hit bottom, that if will take care of it and it stops. If not, we swap the values and bubble it back up to the level above.

That’s it. Inverting a binary tree is 10 lines of code. It’s actually pretty simple.

Cool, so when would I actually want to inverse a Binary tree? 

I have no idea. I’m sure some brilliant people on Reddit or Twitter will have a trove of useful functionality, but I sure can’t think of one.

In my opinion, this is just one of those job interview questions that solely exist so the interviewer can feel smart. You could argue that this is a simple test to see if the candidate can think recursively, but I believe that an open conversation about the interests of the candidate + maybe a small take-home test would give way more insights.

Clean code makes projects more comfortable to work with and improves shelf life. Its the antagonist of vile legacy codebases that are unmaintainable. Then why do we see it all the time?

What is a binary tree and why would I ever want to reverse it

We've all been there before, you submit a pull request and moments later you get a comment like: "Hey you should use a native function here, they are so much faster" or "You can declare this final, that way we save some processing power".

It's great that we as developers keep an eye on this, but how true are these thing. And are they still a thing in newer PHP versions?

Time to put some of these "good practices" to the test. I've selected 10-speed tricks that I've picked up over the years and we're going to check how relevant they still are in PHP7.2.

So how are we going to test this? I've set up a small project that we are going to be running natively (no Docker, no vagrant) in MacOs (version: 10.13.5). The PHP version is the latest version currently on brew (PHP 7.2.8).

The benchmark itself uses PHPBench and we are going to compare each "trick" to its standard alternative. They are separate methods that each will be running 1000 times over 5 iterations. So that means we will run each test 5000 times grouped over 5 results. That way we can minimise deviations and extract meaningful results.

But before we begin, please a word of warning. We are going to zoom in on these claims. Some of these results might seem pretty high but that is only because we only run very small pieces of code. The results might not be that extreme in your day to day code.

Are single quotes faster than double quotes? 

Let's start out with a classic. As single quotes are encouraged by PSR we all might be getting some small speed bonuses without knowing it. We will test with this code:

PHPSpeedQuotesA.php

PHPSpeedQuotesB

Turns out that single quotes are about 5% slower in this test.

Sometimes we like to use JSON or XML to setup validation or config files. Most people like to use JSON over XML due to readability reasons. But is it also faster?

A quick word of warning here, we will be using the native xmlrpc_encode en xmlrpc_decode functions. These are very experimental and not fully implemented. We could be using packages for this, something I would certainly advise in real projects, but that would skew the results too much (as we need to load them in etc). So here is the code:

PHPSpeedQuotesJson.php

PHPSpeedQuotesJsonResult

The native experimental functions that deal with XML are way slower in our tests.

Using loads of layered objects is way slower? 

This one will be a bit messy to display. We are going to new up some classes and send the parameters down 3 layers. There we execute the same function as we otherwise would.

I think we all know that the new-ing up of classes will lose us some time, but let's see how much time we lose.

PHPSpeedLayerTest.php

PHPSpeedLayerResult

Unsurprisingly the new-ing up of classes takes some time. In this case, it comes down to about 25% slower. This obviously doesn't mean you shouldn't be using classes anymore. Personally, I will always prefer maintainability over speed.

Native array functions should be faster than loops, right? 

This is a classic. It's said that native array functions are faster than for each loop because they are native C functions. This is the code we will be running:

PHPSpeedNativeTest.php

I'm going to be totally honest here and say that I've run this test a few times now, cause I couldn't really believe the results:

PHPSpeedNativeResult

Turns out that in this test the array_map method is slower than the foreach. This probably has something to do with the anonymous function.

$row[’id’] is 7 times faster than $row[id] ? 

I've never heard of this one. Apparently, it's a thing:

PHPSpeedQuotedArrayTest.php

Turns out it doesn't really make a lot of difference, at least not in the 700% range.

PHPSpeedQuotedArrayResult

The string fetching is even marginally slower in our test by 2%.

Error handling is an important part of any application, but it is said you should be a bit wary of using extensive amounts of try-catch blocks. Time to put it to the test.

PHPSpeedThrowTest.php

PHPSpeedThrowResults

Unsurprisingly we lose some time on the errorHandling. But personally, I would always recommend having more error handling over having less.

Most static analysis tools tend to either complain about unused vars or straight up to remove them for you.

As unused vars in your code serve no real benefit, it doesn't really make sense to keep them. That said, let's take a look at the cost.

PHPSpeedUnusedVarTest.php

PHPSpeedUnusedVarResult

So it is about 7% in our tests. But as you probably know, there is no real reason to keep those vars around.

Magic methods are slower than regular ones? 

I love to use value objects. And in those objects, I normally use __toString() to cast the object to a string. But I've had some remarks that you should just make them yourself to have a speed boost. Time to take a look at that.

PHPSpeedMagicTest.php

PHPSpeedMagicTest

Turns out magic methods are indeed a tiny bit slower, at about 12% in this test.

Final classes should be faster than non-final classes? 

A friend of mine (the very talented Wouter Sioen) declares his classes final on the creation and only changes it when they really need to be extended.

I'm pretty sure he does that due to OOP reasons, but maybe it's also a bit faster. That could make sense right?

PHPSpeedFinalTest.php

PHPSpeedFinalResults

In our tests, it is slightly faster to use final

That said, I think it a good thing to do anyway.

Do comments have an impact on your code? 

Ok, this is the last one. This has brought so many discussions in the past. Docblocks over return types, code should be self-documenting, ... You've seen the discussions before.

PHPSpeedCommentTest.php

PHPSpeedCommentResult

Some of these tests might surprise you, some might not. That said, please don't stare yourself blind at the results here. Speed is just one part of software development, and I personally think marginal gains don't out weight good developer practices.

At least you left here with some fun facts about pop stars.

We've all been there before, you submit a pull request and moments later you get a comment like: ''Hey you should use a native function here, they are so much faster'' or ''You can declare this final, that way we save some processing power''

So everyone is talking about this hip “new” kid on the block for PHP: Generics. The RFC is on the table and a lot of people are getting all excited about it, but you don’t fully see the excitement? Let’s explore what it’s all about!

Generics is not something new. Statically typed languages like Java and C# have had them for ages. There are even some dynamically typed languages like Dart that implement them in their core. And even languages that don’t support Generics for example Javascript can still support them with a 3rd party implementation, in the case of Javascript, this would be Typescript.

The basic idea is that you can reuse a class that is statically typed with different type parameters. OK, I understand that this might sound very confusing. So let's check out an example:

genericsPhpBefore.php

Yes I know, I’m explaining OO stuff with a car class. I know it’s super cliche, and I’m normally not a fan of getters, but just roll with it.

As you can see, we are creating a Car object with 2 parameters. The wheels and the engine. Now, this is all fine and dandy, but what do $wheels and $engine parameters represent? In this case, it’s the number of wheels and what engine it sports one would assume, as we send an integer and a string along.

But $car = new Car(‘pirelli’, true); would be just as valid.

This is of course one of the typical things of a dynamically typed language. But if we want to add some more uniformity in our class we could, thanks to PHP 7 and types:

genericsPHP7Before.php

Now it’s impossible to create an invalid object thanks to the strict types. OK cool, let’s make everything strictly typed then!

But what if we want to create an object that’s both statically and dynamically typed? This sounds absurd but let me give you a use case. You want an object that accepts a parameter on creation but it needs to always return that same type of parameter on its return.

So for example when I do $myCar = new Car('honda'); and later $myCar->getEngine(); I want to be sure that what I get back from getEngine is the same type as what I’ve put into the constructor (in this case a string).

Well… the thing is… at the time of writing, generics don’t yet exist in PHP yet. I know… what a tease. But luckily for us there is an RFC! So people are still loudly arguing whether or not they want to include generics into PHP and how it should look. But let us take a look at what the current proposed way of doing it is.

The use case described above could look like this:

genericsPHPAfter.php

As you can see, we now have brackets! So first up is this:

Here we say, we are going to create a new Car, with 2 parameters; an integer and a string. You could according to the currently proposed RFC just send:

but I like the explicit version better for explanation sake. Next up is:

This tells the class about what variable types it supports. And then we can use these virtual types just like normal types in the class. So in this case the WheelType will be an integer and the EngineType a string.

That’s a use case that will never happen! 

It is indeed a niche use case, but as PHP grows towards a hybrid of a dynamically typed and strictly typed language it does make sense to include some more features of strictly typed languages. While true, you will not use this every day, there is no harm in having it in the language. It would however be handy for people that write logging or collection packages. Take this piece of code for example:

GenericsPHPAfterEdge.php

You can now reuse this collection for whatever you want, but you will always be sure getValues() will return a collection of items that have the same type.

Even more fun is that you can instantiate a Collection like this: $collection = new Collection<Runnable >(); where Runnable is an interface. This way you could have, for example, a collection that you are sure of only has items with values objects in them that conform to the interface. For example:

GenericsPHPExample.php

The <T is Runnable> in this context would stand for: "you can enter whatever type you want here, but it has to adhere to the Runnable interface."

So what’s next? As I said before, the proposal is currently in draft. Once the proposal is finished it will go into a voting round and if there is a consensus about implementing it, it will be added, otherwise it’s back to the drawing board for Generics in PHP.

p.s. you can follow along with how the RFC is going here

What the hell are generics and would I want them in php?

Why is it that most legacy software projects are not really fun to work on? How can we stop that greenfield project to turn into one of those dull big projects? I would argue that it’s all in the foundation.

In 1982 James Q. Wilson and George L. Kelling wrote an article on a theory they had. It stated that once there is a building in a neighbourhood that shows small signs of neglect (a mailbox that’s overflowing with a few days worth of mail, trash on the street, a broken window that stays broken, ...) the entire neighbourhood devalues and opens itself up for more neglect.

People tend to care less about something that has a lower perceived value.

Small neglects can quickly damage the perceived value of the bigger system they are part of.

Now please note, this is as the name suggests, just a theory. And a highly criticised one at that! The theory is often criticised for promoting stigmatisation and “zero tolerance” attitudes.

Now I’m not really big on sociology, so I’m not going to give personal insights into how the broken windows theory might work in a social or political environment. But we can try and see if we can maybe link some of its ideas to software projects.

Let’s first start with looking at a piece of code. I’m going to take a piece of code from an open-source project (In this case the Slim framework build in PHP made by Josh Lockhart)

brokenwindowSmall.php

This is the resolve method from the CallableResolver class

Now it doesn’t really matter what the code does, but we can roughly see what is happening here. The code might not be perfect, you might even have seen something you would do in another way. But the ideas are quickly shown.

brokenWindowSmall2.php

This is functionally the same method, so it does the same thing. I’ve just removed a few good practices like the early return and some PSR rules. As you can see this code is a lot harder to understand.

I know most people don’t write code like that, and this is probably a bit over dramatised. You would not want the developer that wrote code like that in your team. But still, I would bet you have seen code like this before. Maybe even in a codebase, you work in.

If we apply the broken window theory to this code, we could argue that it all started with a small bit of neglect. Maybe it was Friday afternoon, we’ve sent the original code in and a colleague commented that it misses a small use case. So we’ve quickly added it in, but forgot a bit of formatting. “Whatever, It’s Friday and I have a paper aeroplane folding competition to attend! I’ll do it next week.”

You might think you or a colleague of yours will probably see this and fix it Monday morning. But let’s be real here. That part of code will not only not get fixed, but it will also probably get worst.

How can we prevent this from happening? 

The best way to keep these issues from appearing is to never let them in the codebase in the first place. It is mostly a mental thing.

For the people who’ve never been in the “Boy Scouts of America”. Statistically, quite a lot of people. They supposedly have a rule (I didn’t actually found the rule, but that might be because I only know about boy scouts from Wes Anderson movies):

Always leave the campground cleaner than you found it. If you find a mess on the ground, clean it up regardless of who might have made the mess.

Robert C. Martin, whom you might know better as Uncle Bob, argues in his book Clean Code that we could perfectly apply this mentality to programming. So every file you open, try and leave it a bit better than you’ve found it.

I would however suggest you do this in a separate branch/PR. What can get a bit tedious?

Of course, you write tests (not writing tests in 2017 is like using bronzer for contouring in your make-up). So you probably already have a build server in your stack. Now luckily for us, we can automate the code style, and run “tests” against it in much the same way. With the added bonus of not having to write any kind of “style tests”.

Scrutinizer is a popular one. It gives the option to assign a score to both the individual files and the entire project. The score is calculated on the rules you assign for your project (it ships with a standard ruleset). If your commit sinks the score, it’s time to refactor.

Some alternatives like Codacy and Sideci even allow for the option to automatically add comments to a pull request. So it feels like a human is giving actual code reviews. This can be very handy for one person teams. (Note however that this is nowhere as good a real review from an actual colleague, at least not for now).

Now if you want to go 1 step further, there is this cool tool called Grumphp. Grumphp hooks into your Git commit hook and runs its test before commit. If the tests fail, you can’t commit. As a picture says more than a thousand words; check out this cool GIF I stole from their Github page:

As you know, you can’t have an insightful blog post without at least one mention of Jason Fried. In one of his posts, Jason talks about how they work at Basecamp. Most of the article goes beyond the scope of this post (still a great read), but what really struck out for me was this part:

Once a six-week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six-week cycle. Ample time for context switching. We also use this time to firm up ideas that we’ll be tackling next cycle. More on this in a bit.

This is probably a hard sell to make to clients or your boss. But even if you could get to a “work 6 weeks on features do 2 weeks cleanup”, you could end up with a much cleaner and more workable project. Those practices allow for faster implementation of new features and most important of all: Happy developers.

I truly believe that the broken window theory can be applied to software projects. In my personal experiences, I’ve rarely seen a project start out as a total mess. If it ended up as a mess, it was gradually. I also believe that this is not necessarily the fault of developers working on the project, think of it more as frogs in a pot with gradually increased temperature of the water. One morning you just wake up and take a look at the project and realise that it has gotten really messy.

I think that the best way to counter these small neglects sneaking up in your codebase is by really analysing every pull request. Be it by manual code reviews from peers or by dedicated automated tools. In the best case both.

Another important thing to note is that senior developers are in no way immune to these mishaps. Skill level has in my opinion less to do with this kind of stuff. Everyone can have an off day, it is just important that these off days don't stick around in the project.

The broken windows theory or “why some projects are just destined to suck

Frederick Vanbrabant's

delirious rantings

What is a binary tree and why would I ever want to reverse it

What performance tricks actually work

What the hell are generics and would I want them in php?

The broken windows theory or “why some projects are just destined to suck