Deciding good names for methods are very important to write self-documented codes and always is good if you consider cost of managing source codes.
A few days ago, I found one weird codes in a product I worked on.
...bitRate32 = bitRate16;
For handling DNxHD, we have 3 different bitrates: Display BitRate, Actual 32bit BitRate, 8bit BitRate which is used by LLM.
Problem is that 32bit bitrate is now called 16bit bitrate. (Uh…. I don’t remember it accurately. )
So, I wrote codes for bitRate32, but another guy updated the codes because requirement was changed. He decided to use bitRate16 while keeping bitRate32. He assigned the 16bit bitrate to a variable for 32bit bitrate.
I’m pretty sure that 32bit one is retired, and he just decided to use that same variable while make it contain 16bit bitrate. Problem is that manageability of that code is not good. He had to change the variable name bitRate32 to something else. Why? Let’s say that someone wanted to change things around it someday. I would be perplexed why 16bit bitrate is copied to a variable for 32bit bitrate, and he need to spend his time to figure out if things are OK.
So, I explained this to him and I recommended to change it if he run into the same codes someday. However, he said, “It is what you prefer. It doesn’t matter. It just works!” So, I told him it is not my preference. He can change the variable name whatever he wants. The thing is to make the codes more understandable and manageable.
Any people who has background in CS would understand why I told so. People who have good amount of experience and suffered the difficulty of managing codes would also agree with me.
Although eventually he admitted my suggestion, but it didn’t look like that he understood it. He just wanted to prevent any inconvenient atmosphere between him and I.
He has his background in EE.
This is my little episode. For interview process, experience, what they expect, and what they actually know… about those, I have several things to tell you, but here I would like not to mention it.
Anyway… For naming methods or variables, I found one interesting and unfortunate one in Cocoa.
As you may know, Apple is the company which is very considerate in naming classes, methods, and so on. They are strong in detail. However, let’s pick this unfortunate one :
Ummmmm… it is like to say, “Accept TouchEvents, you Private!”.
However, what it does is to return the state whether the receiver, NSView, to accept touch events or not.
If you take a look at its counterpart, a set method, it becomes clear.
Usually Apple’s standard is : is…. or the member variable name itself to retrieve a value in a class.
Probably, the variable name is acceptsTouchEvents in NSView. So, they had no option but to write that way, probably.
So, at least you would feel less guilty when you decide to use unfortunate name for your variables and methods, thinking “It’s OK. Even Apple does that. Nobody is perfect.” :)