So how we guys could proceed with changing something like this in the whole application? Do you have some specific steps? Is this something done by a single person, or this is something done by every person when he gets something like this in his way ?
@victorjeman The idea is that we agree on a style that we want to use going forward for all new stuff and when you're doing some work in some existing code that has the old syntax you can tidy it up as you go along.
Generally the code review process is for raising stylistic points such as this as the unit tests etc are for catching bugs and unexpected behaviour
The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it."
What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?
@flaviotulino Yeah, when nobody is using it, it's easy to forget it exists. You are right, if it has the same functionality it's ok. But can we defer ES6 Promise? Deferring API is not so intuitive but it is useful sometimes when code goes mad.