I've hinted at symmetry multiple times during this series. It's the last practice I want to cover, but much like rule of three, symmetry gets into the craft of programming, it can take a long time to master. That's because symmetry varies between code programmers even over time. In a way, it underlines all of the other practices and it is by far the most satisfying when applied code, which has symmetry is code programmers talk about, they read it and say, that's clean.

which has symmetry is code programmers talk about, they read it and say, that's clean. Ken Beck defines symmetry in code as the same idea, expressed the same way everywhere it appears, and he demonstrates the depth of symmetry in a simple code snippet. Let's take a look here. We have the process method within a Job class, and we can see nearly all of the practices we've discussed have been applied.

and we can see nearly all of the practices we've discussed have been applied. The code's formatted. There's no dead code. It's not nested, it's not a big block. It doesn't have any return types or primitive obsession, and it seems to have good names, but Kent Beck says, this lacks symmetry in reading over the code. We may notice this line doesn't seem to match its siblings. Technically, the line above

We may notice this line doesn't seem to match its siblings. Technically, the line above and below are method calls, whereas this is property access compared to the surrounding lines. This feels pretty low level, so we could say that it lacks symmetry in its levels. Let's change it to also be a method call. We could say something like incrementCount. This helps achieve symmetry at its level. Everything now is a method call.

This helps achieve symmetry at its level. Everything now is a method call, but now we lack symmetry in its name. As we talked about in the practice of naming the others, leverage their context. They read nicely within the process method, process input, process output, but process incrementCount sounds overly technical. In addition, it's a compound name, incrementCount. Everything else is a singular name, input output.

In addition, it's a compound name, increment count. Everything else is a singular name, input output. We want the name to have symmetry as well. We could shorten it to increment. This makes it a simple name like the other methods, but it still doesn't flow as well within the context process increment, it's still just a bit too technical. Kickback lands on tally. In doing so, we immediately feel the symmetry not only in its simple name, but how it flows within the context.

In doing so, we immediately feel the symmetry not only in its simple name, but how it flows within the context. It relays more on a human level what the underlying code is doing. Now, it's pretty easy to read symmetrical code. We recognize it as being consistent and more intuitive. Writing symmetrical code, on the other hand, that's much harder. It takes time. You can't jump right in. Symmetry is something we should always keep in mind,

It takes time. You can't jump right in. Symmetry is something we should always keep in mind, but actually apply last. The good news is once you start to apply symmetry, it becomes easier to shape the code into its pure form. Again, there are no hard rules, but I have a few strategies that might help start the process. The first thing we can do is check the code for syntactic symmetry,

The first thing we can do is check the code for syntactic symmetry, and this is consistency in the syntax itself. For example, consider it at a low level using the and operator versus the textual AND. And while these two examples do have a slight technical difference, working within a code base that used them interchangeably would lack symmetry. Another example, and one of the biggest knocks on PHP is its inconsistency.

Another example, and one of the biggest knocks on PHP is its inconsistency with function arguments. For example, the first argument you pass to array_filter is the array, and the second argument you pass is the callback. But for array_map, you pass the callback first and the array second. This lacks symmetry and as many PHP programmers in the community have already,

This lacks symmetry and as many php programmers in the community have already, griped can make the code hard to work with. Another form is semantic symmetry, and this deals mostly with the naming of things, but as we saw in the practice of naming, it's not simply about the names we use. They need to fit within the context, the context of the surrounding code, but also the broader code base. Take this outline of a class for a TaskRepository.

of the surrounding code, but also the broader code base. Take this outline of a class for a TaskRepository. It has the four basic methods, create, find, update, and destroy, and these follow the repository pattern. Traditionally, that pattern outlines crud behavior, and CRUD stands for create, read, update, and delete. Even though we have those four same methods, the naming doesn't align exactly with the repository pattern. Now, maybe this was a decision within your code base,

with the repository pattern. Now, maybe this was a decision within your code base, but generally we would want these names to align with the pattern, so we'd rather see, read and delete for the method names. These method names now have symmetry with the pattern and as such, become more approachable to a broader number of programmers. The final form to check for is systemic symmetry. Within our code base, a reader should grow

The final form to check for is systemic symmetry. Within our code base, a reader should grow to expect what's next. This applies not only to the structure of our code, but the design patterns within it. As I've mentioned plenty of times now, we often prematurely abstract the code or force a pattern effectively playing design pattern. Bingo. Doing this makes our code asymmetrical. The way something's done in the code code over here is not

Bingo. Doing this makes our code asymmetrical. The way something's done in the code over here is not the same way it's done over here. As a reader, that makes it really hard to get a feel of the code base. It also makes it hard to apply symmetry because we don't know if we should make the code look like it is over here or over here. The goal of systemic symmetry and symmetry in general is to help the reader gain a feel.

The goal of systemic symmetry and symmetry in general is to help the reader gain a feel of the application from anywhere in the code base. That way they can understand it everywhere. Just as Ken Beck said the same idea applied the same way everywhere.