Hacker News Reader

Comment by _yosefk | Hacker News Reader

Long names are hard to read. This makes autocompletion dangerous (I had a terrible bug where I locked the wrong of two mutexes with long, descriptive names which were too similar visually.)

A good name is short enough to read as a sign in itself, it shouldn't be parsed as a sentence.

The more code reuse there is, the less you might be using the same name, as a sister comment says - but the more names you have, and a lot of long names is really hard to read. So I disagree with sister's "downside" of "it's bad for bad programmers". It's even worse for otherwise good ones who buy into this style. (Or maybe not, maybe they just read differently from me and say Rob Pike who objected "names which are short essays about the thing they name.")

View on HN

I'm a big fan of Apple's descriptive and remarkably consistent APIs, but the combination does make autocomplete errors easy to make and hard to notice. For instance:

  - tableView:didSelectRowAtIndexPath:
  - tableView:didDeselectRowAtIndexPath:

If you accidentally choose the latter, the behavior seems baffling: the first tap on an item does nothing, and every tap afterwards gives you the indexPath of the previously selected item. I'm embarrassed to admit how long I spent looking at indexPath values in the debugger and thinking "this can't be happening" before realizing what actually was happening.

I made the same mistake a couple of times! Felt so stupid once I found the bug :-/

I still prefer long descriptive method names though.

These days, I format the method so that each param goes into a newline (after Xcode autocompletes it) and this helps me catch such bugs.

All of the names in the selector are short and easy to read, there's just a lot of them. I don't even know what the method does or what any of the parameter types, but I can make what I'd assume is a fairly accurate guess:

    outputImageProviderFromBufferWithPixelFormat:

Some kind of pixel format enumeration, probably along the lines of "[Class name of the receiver]PixelFormat". Also, the function probably returns an "OutputImageProvider", or something like that (could be a id with a protocol associated, due to "provider"). This one is longer than the others, but that's just because it contains information about what the message will return.

    pixelsWide:

The width of the output image in pixels, hopefully an NSUInteger (but sadly, probably an NSInteger, and Swift is only making this discrepancy worse).

    pixelsHigh:

Same as above.

    baseAddress:

A pointer to the buffer referenced.

    bytesPerRow:

The number of bytes per row, probably size_t?

    releaseCallback:

Something to call when the provider is released, probably a block? Actually, judging by the next parameter, probably a function pointer. Wow, this must be an old API!

    releaseContext:

An argument to pass to releaseCallback.

    colorSpace:

A color space value. Possibly an enumeration of RGB, HSV, etc., or a more complex type.

    shouldColorMatch:

While I'm not sure what color matching actually is, I do know that this parameter enables or disables it, and is of type BOOL.

Reply on news.ycombinator.com