Jenalya wrote:o11c wrote:indentation with 4 spaces
Having in mind the first line of an NPC needs a tab, how to use this in a comfortable way? Are you going to change that? That'd be great!
Unfortunately I cannot change that: in particular, because the name of an NPC may contain a space.
Jenalya wrote:o11c wrote:Check for troublesome arrays
A troublesome array is defined as an array that is not
- initialized all at once
- initialized by appending elements to the end, for use in a menu
What should be done with those?
Nothing needs to be done, merely document them. I want this information at hand when I design the new scripting language to minimize conversion pains.
I wouldn't be surprised if there were no troublesome arrays at all. If there are only a couple it might be worth refactoring the code to remove them, but that might be a high-level decision which is beyond the scope of this proposal.
Jenalya wrote:o11c wrote:remove break; instead use end; (requires changing the java converter)
What would be the effect of that?
No effect, they are identical internally. But I'm trying make all functions have the same name internally and externally, which is not really possible the the function has multiple external names.
The only other example is that "save" is an alias for "savepoint", but this is believed to be unused.
Jenalya wrote:o11c wrote:newline between if (condition) and conditional_command; ?
Generally yes, but I think at the beginning of NPCs to determine to jump to which label depending on some variable, it's clearer without a newline.
That sounds like a good single exception: "newline between if (condition) and conditional_command, except when conditional_command is a goto at the beginning of a major script block (usually only at the beginning of a script), in which case if there are multiple if statements on adjacent lines, the gotos shall be aligned"
Jenalya wrote:o11c wrote:capitalization of temporary variable names and labels?
Do you mean with capitalization This or THIS?
When I started scripting, I learned by reading existing scripts and adopted to name
labels with something like "L_Labelname", what about making that a convention as well?
Yeah.
My tendency is to use lower_case_with_underscores for most variables, UpperCamelCase for special variables, lowerCamelCase for the not-quite-special variables like bAgi, CAPS_WITH_UNDERSCORES for global constants, CAPS_followed_by_lowercase (or CAPS_FollowedByCamelCase?) for local constants.
Labels should always start with L_, except those that act as a subfunction, which should start with S_. There must not be a fallthrough or goto to a subfunction label.
Current practice for labels is L_CamelCase: for labels and I don't think that is worth changing, although I personally would prefer L_lower_case:, especially for things like L_close:
Labels shall be outdented. Which, since the main script body only has one level of indentation, means it starts in column 0.
The one ambiguous case with lower_case_with_underscores is if there is a number as part of the variable name: my_option1 or my_option_2. When there are already underscores in the name 2 looks less unbalanced but without existing underscores I instinctively choose 1. Note that db/const.txt has e.g. NIBBLE_0_MASK and the scripts have quite a bit of both (sometimes on the same line: in npc/010-2/loratay.txt:46: @agostine_msg0$, L_agostine_0)
Also, what should labels within a subfunction label use? I was thinking LS_ or SL_; loratay currently uses L_SUB_ ... or perhaps this should be refactored out into a standalone function?
Jenalya wrote:o11c wrote:Personally, I dislike code like:
(snip)
I experienced having hard coded numbers all over the code is bad...
Though using constants for values used only once in the script might be exaggerated, but I suggest to have constants at least for values that are used several times, e.g. the amount of an item needed to fullfill a quest.
Yeah, I know magic numbers are a Bad Thing, and I never thought my concerns were enough for an argument. At least you can stop and think "is this variable meaningful?"
But note also that this ties into the "set variables to 0 at end of script" - it might be better to put them in db/const.txt as MY_NPC__SOME_CONSTANT or MY_QUEST_SomeConstant
What about guidelines regarding saving playervariables with using bitmasking or setting used playervariables to zero and set a flag for it after a quest is finished?
I consider this a high level concern which is beyond the scope of my proposal. But, such high-level concerns (including bitmasking in general) could be added as a separate section in the "scripting standards" document.
Wombat wrote:I like tabs and how things have been with scripting. Why can't we use the standards we've used for years? I don't like changing how scripting is done.
Because we don't
have a standard. Most, if not all of these items are inconsistent between files.
Also I found this ironic:
irc wrote:10:23:45 < Wombat> it doesn't have proper tabs since I did it on another computer
Tabs are intrinsically problematic and if I could remove the required ones, I would.
Wombat wrote:Also, a great many of your points aren't contrasted against others. If it is a change proposal, it helps to know what is changing.
There is not much of a "change" proposal here as much as "stop having 4 different indentation and variable naming style", some "add" and "remove" stuff, and my vaguely-planned ideas about commenting and documentation. Can you you be more specific?
Wombat wrote:They also assume the reader understands what you are saying.
This topic, to specify the standard, is intended for developers who know what they are doing, as they are the ones
maintaining the code.
Wombat wrote:Many script writers for the game don't understand programming.
Jenalya wrote:Generally I like the idea to have some coding style conventions very much. But we should take care not to create a deterrent environment for new contributors with creating requirements only few people can meet.
Jenalya wrote:When I started scripting, I learned by reading existing scripts ...
For new/inexperienced script writers, I think this would
improve the situation by
- Making all existing scripts consistent with each other (and with themselves!)
- Having an official "scripting standards" document (and/or "how to script")
argul wrote:o11c wrote:
- Set dynamic and local @variables to 0 before close;
(Would be good coding style indeed, but would need refactoring lots of already-there code.)
Can't the game engine handle this and prevent memleaks or staying variables?
@variables persist until the player logs out (or the server restarts).
Only a few quests actually use this feature (which would not be changed, as they would be documented as "temporary", not "dynamic" or "lexical"), most are only used within the function ("local"/"lexical") or to/from subfunctions ("dynamic") and waste (not leak) memory if they are not cleared.
(Keep in mind that there are also memory leaks in tmwA, such as about 1300 bytes every time a spell is cast (which is TMW code, not from eA
), if I understand it correctly; also some larger one-time leaks during initialization. Decreasing wastage means it will be longer until the leaks get bad enough to crash the server)
argul wrote:What is
unnecessary?
I know there was a hunt for these earlier and my memory was from playing before that, but I can think of a couple of categories:
- next; before close;
- next; not after a mes; line (such as after a menu; see npc/xmax/2010/santa.txt and npc/032-1/miriam.txt; there might be more if there is a larger menu but these are the only ones within 2 lines, when grepping for a larger gap there are too many false positives)
- next; between lines that are not logically separated (I guess this one is a higher-level concern)
Former programmer for the TMWA server.