Unfortunate method names in Cocoa

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 :

- (BOOL)acceptsTouchEvents

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.” :)

4 responses to this post.

  1. 안녕하세요. 오랜만입니다.

    코코아의 getter/setter naming은 setter일 경우 set… 을 prefix로 붙인다는 것 외에는 smalltalk의 naming convention과 동일하다고 생각합니다. 저는 개인적으로 smalltalk의 naming이 더 낫다고 생각하지만, set…을 붙이는 애플의 컨벤션은 readability를 좀 더 고민한 흔적이라고 볼 수 있을 것 같습니다.

    물론, 헤깔릴 우려가 충분히 있을 수는 있겠지만,
    만약, “Accept TouchEvents, you Private!”의 의미라면

    – (void)acceptTouchEvents:(NSArray *)events

    가 되겠죠.

    smalltalk의 messaging style을 따르는 obj-c에서는 메쏘드 이름(또는 메세지 이름)을 읽거나 판단할 때 인자에 대한 고려가 반드시 필요하다고 봅니다. 영어에서도 같은 스펠을 가지는 단어가 context에 따라 동사가 될 수도 있고 명사가 될 수도 있는 것 처럼요. 제 생각일 뿐입니다만…

    Reply

    • Posted by jongampark on October 1, 2010 at 10:38 AM

      헉.. 어떻게 남기신 코멘트가 스팸처리가 되어 있더군요. 다행이 일찍 발견해서..
      남기신 답변에 동감합니다.
      작명이 때때로 어려워요. ㅋㅋ

      Reply

  2. Posted by Brad on November 21, 2010 at 2:05 AM

    Don’t forget the classic “appendBezierPathWithArcFromPoint:toPoint:radius:”. The arc it appends doesn’t go from point 1 to point 2 at all. ;-/

    There’s another NSBezierPath method called “addClip” which doesn’t “add” a “clip” (whatever that might mean)—it adds the *path* *to* the current clipping paths.

    People who can’t communicate shouldn’t be allowed to name methods in pseudo-English. They should be restricted to using “foo” and “bar”—the time-honored codewords signifying “I can’t communicate.” :-)

    Brad Keyes

    Reply

    • Posted by jongampark on November 21, 2010 at 6:49 AM

      :) Yeah.. It is funny.
      Problem is that there are so many unqualified programmers out there but pretend to be very good programmers. I noticed many methods of which names don’t mean anything or named wrongly according to what they do in source codes of products I have worked with.
      People don’t seem to care about it. I doubt where they got that kind of attitude.

      The method names you pick are problematic, though… :)

      Reply

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: