Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JavaScript naming convention for promises? [closed]

I feel it would be useful to have a naming convention for JavaScript variables which hold a promise. I don't generally like or advocate naming conventions beyond programming language standards, but in the style of programming where promises are passed around as function arguments it's often hard to tell at a glance whether a variable holds a promise or the "real thing".

I've personally used promiseOfFoo and pFoo, but I find the former a bit verbose, and the latter gives me flashbacks from Hungarian.

Is there a commonly used convention?

like image 696
jevakallio Avatar asked Jan 10 '13 21:01

jevakallio


People also ask

What are bad naming conventions in JavaScript?

Naming Convention for Variables JavaScript variable names are case-sensitive. Lowercase and uppercase letters are distinct. For example, you can define three unique variables to store a dog name, as follows. However, the most recommended way to declare JavaScript variables is with camel case variable names.

What is the naming convention for JavaScript?

Names are case-sensitive, lowercase and uppercase are different. Start variable names with a letter, use camelCase for names. Variable names should be self-descriptive, describing the stored value. Boolean variables are usually prefixed with is or has .

How are JavaScript promises handled?

The Promise object supports two properties: state and result. While a Promise object is "pending" (working), the result is undefined. When a Promise object is "fulfilled", the result is a value. When a Promise object is "rejected", the result is an error object.

What is the problem with promises in JavaScript?

Apart from how the API is structured - promises have another major flaw: they treat unintentional native runtime exceptions and intentional rejected promises - which are two drastically different intentions - in the same "path".


1 Answers

This depends more on how you're going to use them, doesn't it?

If your code looks like:

var imageLoading = loadImage(url); // returns promise imageLoading.done(showImage);  // imageLoading.done // imageLoading.error // imageLoading.then // imageLoading.success // imageLoading.fail // ... whatever your library supports 

Then, I might suggest naming the promise something like a present-tense verb...

BUT if you're building a library which depends on deferred objects

// accepts a promise var showImage = function (promise) {     promise.done(function (img) { /* ...... */ }); }; 

Then there's nothing particularly wrong with naming the variable as a noun, so long as there's an understanding as to which methods take promises and which don't.

var image = loadImage(url); // returns promise showImage(image);           // acts on promise 

Now your interfaces are really clean, and you can write code which looks 100% procedural. ...buuuut, you need to know which functions/methods use promises and which use objects.

If you are passing promises as callbacks, inside of object methods, then you can happily name them promise or tweetLoading or dataParsing or whatever makes sense within the context of that particular situation.

For the definition of showImage, the parameter I chose is flat-out called promise, so that if you're doing work on that function, or you needed to debug a chain of stuff, you could see the second you looked at it that it took a promise object.

like image 199
Norguard Avatar answered Sep 19 '22 16:09

Norguard