In Ruby, there is an unspoken rule that a method returning a Boolean gets a ? at the end of its name, like empty?. It is, after all, an unusual rule that you don’t see in other languages. If you mainly use another language and come across this rule, I think it could look strange.
Ruby is said to aim for human-centered code. I used to have no idea what human-centered code was supposed to mean, but thinking about it now, I suspect it means finding a way to code happily under Ruby’s philosophy that “there are many ways to solve a task.” Maybe the rule above is also a convention that settled after people stepped outside the mold and tried this and that in search of naming that is comfortable for a person to read.
These days, code is often treated as if there were a single correct answer. In that atmosphere, if you step even slightly outside the mold that is considered correct, people say it’s code that needs fixing. In extreme cases, some people insist the code is wrong as a whole and has to be rebuilt from scratch. Rules that are considered correct are not bad in themselves. It’s just that the biggest problem is that everyone’s correct answer is different. When something feels different from my own correct answer, I reject it out of anxiety. I think this happens because we project “my correct answer” onto work that was done as a team.
I too once felt uncomfortable with the rule of putting a question mark on Boolean methods. It felt like I was coding the wrong way, and I felt anxious thinking it wasn’t the correct answer. But after I accepted it instead of rejecting it, I realized it reads well, and I grew attached enough that it still comes to mind now, even though I no longer use Ruby. If I had rejected it back then as not the correct answer, I still wouldn’t know what was good about it.
Maybe discomfort is something that can be removed easily with just a little effort to understand. For one abstract methodology there are countless concrete ways to carry it out, and if there are 100 teams, I think there are 100 correct answers. Like Ruby’s philosophy that there is more than one answer, I think the “our team’s answer” that is built at the end, by trying to understand each other and removing discomfort along the way, is the “human code” that can be written with a happy heart.
How about talking with the teammates you work with today about what kind of code each of you likes and how you want to build things, and making “human code” that everyone can be satisfied with?
