Hacker News Reader

>Picking the proper names for software constructs is also part of that category. I'm always impressed at how choosing a slightly wrong-one can have a huge impact down the line.

Similarly I'm often shocked at just how critical name disambiguation is. There's a shocking number of extremely similar concepts when writing code which, when given the same name ends up causing bugs.

A good example is 'file' which can be used to refer to a file handle, file name, file object of some other kind, a 'file' representing an aggregate of information on person, and often it ends up referring to directories, devices and links as well.

Throw path in there for good measure. Often times I see path in code and have no idea if it's expected to be a directory, file, relative path, etc...

It's a good example. It also makes me think of "users" tables instead of "accounts".

Unless it's a financial application...

Absolutely on naming. The python module "optparse", which was standard for quite some time, did not have any way to specify that a flag must be passed. As soon as the newer version "argparse" came out, this could be specified. All the documentation pointed that "mandatory option" was a contradiction, not realizing that they were the ones who had labeled it as an "option" in the first place.

We are in precisely the middle of this. We have documents in our product that encapsulate an essential step in a workflow, but for some unholy reason, someone decided to call them "items."

Now day in and day out, I have to deal with classes like ItemViewer, ItemListController, etc etc, and half the time I have no idea what the responsibility, location or relationship of any given class is supposed to be. So much time just getting contextual background before I start working in an area of code. Couple this with early bad coding decisions around encapsulating responsibility and lack of testing coverage and I've got a relatively miserable 2-3 years ahead of me.

> someone decided to call them "items."

I prefer to call my stuff "things."

I like "entities" -- I feel so smart when I use that.

The only other name left is "entries", right?

Heh. Except for: element, action, slot, task, goal, task command, subject, target, source, destination, object, actor, path, key, memo, manifest, sender, receiver, self, this, thing, data, value, register, ... I think you enumerated them all.

An "entry" at least implies there is a list somewhere (as would "element"). Both "item" and "entity" are more like "thing". I could see adding "object" to the list.

"entry" is a fantasticly sinister name if you're writing the sql directly in your application though. object would be hilarious in java assuming the compiler lets you do that.

Indeed. For example, I am deeply amazed at how in Flux and many of its derivatives Actions are not executable behaviours, but messages describing an action to be performed, while ActionCreators are the actual, well.. "actions".

I've thought about this particular issue quite a bit as well, but I haven't been able to come up with a great solution, because RAILS_ENV/RACK_ENV is ubiquitous and auto-detected by tools. So you can have multiple deployment targets running the same mode, but then you can't differentiate them by default in tools like New Relic, Slack, Honeybadger, etc. You can put a lot of effort into building custom solutions to this, but since there is no standard it's easy to run into brick walls. In the end I've found it to be more work than just adding a new RAILS_ENV setting across all the config files. Ugly but pragmatic.

I think the lesson here is to not fuck it up in the first place. When inventing the new framework "Foo", call the variable FOO_DEBUG, not FOO_ENV.

As you've observed, it's not really possible to go back and fix this kind of mistake after it's been made.

I would encounter this with the graduates of these 90 day coding schools when interviewing them. There would be total shock and incomprehension when I asked them to click through their github and revealed the secret key they'd checked into the public repository....

Another good example is 50% of the method names in the Android SDK.

As someone who has done no Android development, could you elaborate?

Maybe it's just me but, when I see things like this, I lose confidence in the method naming process on the Android SDK:

glEGLImageTargetRenderbufferStorageOES

http://developer.android.com/reference/android/opengl/GLES11...

They capitalized Render but not buffer. Also: what does this even mean?

---

readExceptionWithOperationApplicationExceptionFromParcel

http://developer.android.com/reference/android/database/Data...

Do they really need to put the word Exception in this name twice?

---

getGestureStrokeSquarenessTreshold

http://developer.android.com/reference/android/gesture/Gestu...

What's a Treshold? (Yes, that's how they spelled it).

---

Ok, so the standard way they spell it is N-U-L. One L: getAllButNulLegal

http://developer.android.com/reference/android/net/UrlQueryS...

But wait: readMessengerOrNullFromParcel

http://developer.android.com/reference/android/os/Messenger....

---

Ok, so the standard way they spell it is C-A-N-C-E-L-E-D. One L: registerOnLoadCanceledListener

http://developer.android.com/reference/android/support/v4/co...

But wait: onGestureCancelled

http://developer.android.com/reference/android/gesture/Gestu...

---

There's also this: http://blog.danlew.net/2015/04/18/is-your-user-a-goat/

1) The OpenGL standard specifies functions that are capitalized like that, as "renderbuffer" is a noun.

2) NUL is a character, while NULL is a pointer. These APIs are using the correct name for each scenario.

3) Checking if the user is a monkey (or now a goat) is a running gag. I don't think that is a naming mistake.

4) The usage of "exception" in that name is clearly different each time, though maybe it requires knowing Objective-C for that to feel "correct" (as the developer who named that function clearly is writing Objective-Java there ;P).

The spelling mistakes and inconsistencies are "awesome", though :(.

(I wanted to add this to my other reply, but it's too late for that.)

Is there a method naming convention in Objective-C where the phrase "withExceptionXYZ" in the method declaration means "this method may throw an instance of ExceptionXYZ"?

This is from https://android.googlesource.com/platform/frameworks/base/+/... :

    public static void readExceptionWithOperationApplicationExceptionFromParcel(
            Parcel reply) throws OperationApplicationException {
        int code = reply.readExceptionCode();
        if (code == 0) return;
        String msg = reply.readString();
        if (code == 10) {
            throw new OperationApplicationException(msg);
        } else {
              DatabaseUtils.readExceptionFromParcel(reply, msg, code);
        }
      }

I don't know Objective-C at all. Would this method name truly feel correct in that language?

Thanks.

I parsed saurik's comment as a joke based on Objective-C enjoying long names containing the word "with". Objective-C is relatively unique among programming languages in continuing the method name when specifying parameters, and "with" is a usual way of specifying them. For instance, one of the constructors for NSString is named "stringWithContentsOfFile:encoding:error:", and the way you'd call that method is something like [NSString stringWithContentsOfFile:@"file.txt" encoding:NSUTF8StringEncoding error:NULL].

However, in this context it's not used that way, because you're not taking an OperationApplicationException. Instead, yes, this appears to be a variant of readExceptionFromParcel that instead sometimes throws an OperationApplicationException. That use of the word "with" would not feel correct in Objective-C -- nor would the use of an exception, probably, since they are rarely used in Objective-C.

Ah. I just wasn't able to understand saurik's joke. Thank you for clarifying these things. Good stuff.

Aha. Android SDK names aren't as bad as I thought!

Nice comment.