Naming conventions

[wibblymat]

I think we need to come up with naming conventions that our whole team can agree on. I personally dislike the practice of adding 'Promise' to the name of functions that return promises, especially as it becomes the norm for functions to return promises. I certainly wouldn't see us do this for other return types.

I don't really think it adds anything, and in many cases can be more confusing - I would expect globPromise to be a Promise rather than a function that returns one, for example. And I would expect processPromiseWrapper to be a method that takes a 'processPromise' (whatever that might be) and wraps it, whereas it is actually something that promisifies process.

On the flip side, I know that my natural style is at the minimal end of the spectrum, and I'm sure plenty of people feel that my names are not descriptive enough.

This is totally a discussion for after I/O though!

[jeffposnick]

We're using the goog.* namespace for all the things we export into the global scope.

Within the actual helper code, I don't believe that there are any methods with Promise in the name, and everything is JSDoc-ed to indicate what it returns, etc.

Some of the build infrastructure still does use Promise in the method names, but I'm on board with not doing that moving forward.