Moderator
M
Moderator
12th Dec 2015
IcemanBo: Too long as NeedsFix. Rejected.
15:50, 17th Feb 2013
Magtheridon96:
I think this covers most things :v
IcemanBo: Too long as NeedsFix. Rejected.
15:50, 17th Feb 2013
Magtheridon96:
- wanttoregister should be WANT_TO_REGISTER because that's how constant booleans are written in JASS.
- All your struct member names should be camelCased. (reptypename -> repTypeName, repname -> repName, etc...)
This is JASS convention and it would make them easier to read. - I think it would be more suitable to make a single rep change event and have a boolean as event response data to tell you whether it's increasing or decreasing.
This way, you satisfy people who just want to detect whether the rank is equal to something or not while still keeping the people who want specific code to run for each type of change happy (Optional change, just throwing in my opinion) -
JASS:
if saver[this][GetUnitUserData(u)] == 0 or u == null then return false else set saver[this][GetUnitUserData(u)] = 0 set hunit[this] = hunit[this] - 1 set origown[this] = null return true endif
JASS:if saver[this][GetUnitUserData(u)] == 0 or u == null then return false endif set saver[this][GetUnitUserData(u)] = 0 set hunit[this] = hunit[this] - 1 set origown[this] = null return true
- The documentation should be updated because at least one of the API elements is incorrectly listed (struct reputation -> struct Reputation)
- Can't the API listing just be the function definitions with descriptions that go under to avoid annoying scrolling? :/
JASS:/* * static method create takes string name returns Reputation * - Description. * * static method createEx takes string name, integer something returns Reputation * - Description. * */
(Also, not everyone knows the func(args, args2, args3) notation - remove should be named destroy to comply to Struct method naming standards :/
Whenever a user calls something that is not "destroy", he is going to expect the instance to remain unrecycled. - Player(15) and Player(12) should probably be configurable in the globals block at the top.
- In the addToFaction method, you would benefit (readability and efficiency) if you were to cache the unit user data into a local integer.
- In the addToFaction method, you can discard the "else" and return false at the end of the function.
I think this covers most things :v