Spawn.canCreateCreep() should not return 0 on success
pmaidens last edited by
Spawn.canCreateCreep() is a totally counter-intuitive method. When the spawn can create the specified creep, canCreateCreep() returns a falsy response, and when the spawn cannot create the specified creep, it returns a truthy response. This method should be renamed cannotCreateCreep().
Yes, it doesn't work that way. It returns the same error codes as
Spawn.createCreepmethod. See the documentation. In most cases it is important to know the reason why the spawn cannot create a creep.
oneflame last edited by
I agree, in a way:
I think the boolean naming convention should be dropped, because either way, it doesn't make a lot of sense to write these methods with boolean naming conventions, and new users would have issues.
As a solution, perhaps using a "Call State" property instead, as a naming convention instead:
> Game.spawns.Spawn1.createState == 0; // Certainly assures that users are not reading this as a boolean expression.
Both ways of applying boolean naming conventions require a "learning curve", and are not intuitive:
> method.canDo() == 0; // Does not make sense as a boolean expression. > method.cannotDo() == 0; // Does not make sense as a boolean expression, either. > mehod.canDo() == 1; // Makes a lot of sense, and readable, but breaks exit code convention.
At some point there is going to be some refactoring/modification of the API, and it would help immensely to /forcibly require/ a "main" comment, or var apiModule = require("api-v.1.0.0"); or some such convention, that can let users know in advance their API level has been deprecated.
nugarin last edited by
There is a global constant OK, which is set to 0;
So suddenly everything makes sense
var canDo = method.canDo() == 0 ? true:false;//Misuse of the API. Docs DO include the number, but defined constant should be used. var canDo = method.canDo() == OK ? true:false;// Appropriate use of the published API, OK constant is defined