What promises prescribed not to do

Promises clearly outline what not to do while implementing a promises paradigm. We saw most of these rules in Chapter 2, The JavaScript Asynchronous Model. Let's take a look at these from the promises paradigm in order to refresh our memories.

The following two practices must be taken into account while implementing promises, regardless of what implementation you are using:

• Avoiding getting into a callback hell
• Avoiding use of unnamed promises

Avoiding getting into callback hell

We are already aware what callbacks are and how to handle them. Callbacks are a great way to implement an asynchronous model, but they have their own cost. They are unmanageable at some point, and that point comes in when you start your descent in callbacks. The deeper you pe in, the more difficult it becomes to handle, thus leading you into a callback hell scenario.

All of the promises implementations have sorted this problem very simply and wisely.

A handy way to tackle callback hell

Avoiding the use of unnamed promises

As we saw from Chapter 2, The JavaScript Asynchronous Model, the use of unnamed promises can cause huge problems and will cost more time than the normal function of writing and testing. In some instances, it's good and recommended that you do not give the name of your function, but it's not good practice to leave your promise unnamed.

If someone thinks anonymous functions are hard to deal with, then unreasonably named functions are hard to understand and maintain. I recommend that you come up with a proper, predecided naming convention, and it should be done well before writing the actual code. I prefer to use CamelCase notation in Microsoft style, in which the starting name of the function is in lowercase and the connecting name is in uppercase.