If you've ever heard somebody use the term object calisthenics before, that might have sounded really complicated and medical, but it's really not. It just refers to exercises, or in other words, simple guidelines for simpler code. And it doesn't get that much more complicated than this. The only issue is, some people think of it more as a rulebook, meaning under no circumstances can you break these rules. And that's simply not the case. Instead, think of them as very good rules of thumb. Learn them, try to follow them, and when it makes sense, break them. So without further ado, let's dig into these, and we'll start with one of the more simpler ones. Don't abbreviate your code. So here's what I mean. If you've ever done something like this, imagine you have a Translator class. Never under any circumstances create a class name or any variable name like this.

So here's what I mean. If you've ever done something like this, imagine you have a Translator class. Never under any circumstances create a class name or any variable name like this. Now it's interesting, you wonder why we do this, especially when we're first getting into all of this stuff. We feel this need to abbreviate everything, as if the bottleneck of our project is that we have to type a few extra letters in some cases. It doesn't matter. And even more importantly, if you are interested in workflow and speed, well, using this abbreviation would still be slower than writing it out manually. And that's of course due to muscle memory. So there is literally zero benefit to using an abbreviation like this, so don't do it. And the same goes true for things like this. This is a big offender. For each xn people. I did this a lot when I was first getting into code, because once again, for some reason,

And the same goes true for things like this. This is a big offender. For each xn people. I did this a lot when I was first getting into code, because once again, for some reason, I needed a one letter variable name to speed up my flow. But what I didn't realize is, yes, it's a minor infraction. But the problem is, when you have 1000 of these little issues here, they add up very quickly into a poorly built app. So in this case, if you want to get their name, especially maybe six months down the line, if there's a number of lines within this loop, it may take you just a second to remember what x is equal to. So why bother naming it x, especially when any editor worth its salt has good auto completion. So in this case, if we changed it to person, you could still type P and then press tab to fill in the rest. So once again, there's zero reason to abbreviate. In fact, the only reason you should ever have

if we changed it to person, you could still type P and then press tab to fill in the rest. So once again, there's zero reason to abbreviate. In fact, the only reason you should ever have an x or a y variable is if you are genuinely referring to x and y coordinates. Okay, so what about some other abbreviation offenders? We've reviewed class names and variables. But of course, this will apply to method names as well. So imagine that you have a UserRepository. Well, you could call it UserRepo. Again, not the end of the world. However, why are we calling it repo? Do we really need to save a few characters? Or can we just be explicit? Go with UserRepository. Now imagine within here, you have a method that fetches a user by their billing ID. So maybe you have something like this. And actually, on this note, this is about the only occurrence when I'm okay with an abbreviation. And what I mean by that is,

user by their billing ID. So maybe you have something like this. And actually, on this note, this is about the only occurrence when I'm okay with an abbreviation. And what I mean by that is, of course, ID itself is an abbreviation for identifier. However, the difference is, it's so widely and universally known in our community that there's really no benefit to doing identifier over ID. So in that case, I'm perfectly fine to keep it like this. So on the surface, this looks pretty good. We don't really see any important abbreviation here. However, one problem is, this is a method for fetching a user by their billing ID. It's not by their user ID, or username, or email address. So that means in usage, especially once again, a year from now, well, we have a repository. And I want to fetch the user. So fetch looks like the one I want, but I don't actually remember what I pass to it.

especially once again, a year from now, well, we have a repository. And I want to fetch the user. So fetch looks like the one I want, but I don't actually remember what I pass to it. It really feels like I should pass the user ID here. But of course, that's not correct. Now, it's true that an IDE will give you some intellisense to let you know that you need a billing ID. But that still sort of gets around the issue here. The problem is, fetch is sort of still an abbreviation. What are we really doing here? We're fetching a user by their billing ID. So yes, we don't want to do something like this, fetch a user by their billing ID. That's too verbose. But maybe we could do something like this instead, fetch by billing ID. Now, because we're referencing billing ID within the method name, if you want, you could even shorten the variable name down to ID, since it's obvious what that refers to in this situation.

Now, because we're referencing billing ID within the method name, if you want, you could even shorten the variable name down to ID, since it's obvious what that refers to in this situation. But that one would be up to you. Now, yes, we have a few more characters, but we're doing a much better job of describing and illustrating the public API here. Now, on this note, there is an extension to this rule. And by the way, these rules or guidelines come from a book called The ThoughtWorks Anthology, written by Jeff Bay. So research that if you want to dig into this stuff a lot more. Anyhow, there is an extension to this rule that says your names, whether they are variable or method or class names, should not exceed two words. So if we are honoring that, this example right here breaks the rule. However, from my point of view, this still perfectly describes what it does. So I'm okay with ignoring that part. But

So if we are honoring that, this example right here breaks the rule. However, from my point of view, this still perfectly describes what it does. So I'm okay with ignoring that part. But this extension is still important to keep in mind. The benefit is that when you force your method names not to exceed two words, well, you might come across some issue where it's not describing what your method does well enough. And if that's the case, it might be an indication of a code smell that you're doing too much in this method. So you're trying to extend the method name to describe it a little bit better. And that's how we break the rule and realize that maybe we need to do a little bit of refactoring. So as an example of that, imagine that we have an Order class and you have something like method prep and ship and notify user. Well, we're trying to make this method name very specific because we're doing so much in here, presumably. So if we honor that rule

and you have something like method prep and ship and notify user. Well, we're trying to make this method name very specific because we're doing so much in here, presumably. So if we honor that rule where it says you can't have more than two words, well, you might end up with something like order_prepare or order_process that dreaded process word. And now we come into this situation once again, where process doesn't do a great job of describing what it is that does. So notice how these are sort of clashing with one another, once again, indicating that we could better represent this in a different way. We should do some kind of code refactoring. All right, so moving on, what else? Another issue would be being too explicit. And this is a mistake that I've made a lot myself. So sticking with class Order, maybe we want to ship the order. So you call it this. And you think everything is great. But now think about it. In usage, we would have an order variable.

lot myself. So sticking with class Order, maybe we want to ship the order. So you call it this. And you think everything is great. But now think about it. In usage, we would have an order variable. So if we want to ship off the order, we'll notice that this immediately comes across as redundant. So when we defined it up here, maybe it felt okay. But when we use our code, and this is important, try to design and build your objects by writing the usage first. And this is one big benefit to TDD or BDD. It makes you actually think about how you will consume these objects before you build them. And that can be really beneficial. So in this case, no abbreviation here, but we're being too verbose. We already have a class Order and an order object. So we can get away with calling it ship. And now notice that the usage is that much better. All right, so that does it for the first episode in our series. When you're ready, let's move on to another guideline.

ship. And now notice that the usage is that much better. All right, so that does it for the first episode in our series. When you're ready, let's move on to another guideline.