HeroScript Code Standards
These are our current HeroScript standards. You may encounter older HSL code which does not exactly conform to these standards, but just like updating and revising the wiki, it's an on-going process
HeroEngine reserves names beginning with the underscore (_) and prefixed by (HE_) for our own usage. Single word identifiers are rarely appropriate. Names of GOM definitions may not contain two underscore (_) characters in a row.
HeroEngine's Data Object Model is a flat namespace, consequently class names tend to be more verbose.
First letter of each word should be capitalized.
example: FooBar InventoryContainer
While the engine does not enforce abstractness (i.e. HeroScript does not have the equivalent of a pure virtual class), it is often useful to make classes that conceptually are abstract in nature and we generally preface their names with abstract to indicate the intent.
Class Method Scripts
The engine knows how to tie classes with the associated behaviors (scripts) by virtue of the script being named the same as the class name + "ClassMethods". The class method script should utilize the same case rules as Classes (i.e. the first letter of each word in uppercase).
Scripts that lack the addition of "ClassMethods" in their name are "free floating" and are used to implement procedural programming patterns (see Scripts below).
Much like Class Method Scripts, scripts should have the first letter of each world in uppercase.
Class Attributes (fields)
HeroEngine's Data Object Model is a flat namespace, consequently if you have a field named "Foo", there is exactly one and only one definition for a field of that name no matter how many classes might have the field as a member. With multiple-inheritence, no matter how many times a child class might inherit the field "Foo" ultimately the instantiation has only one field named "Foo".
As a result, field names tend to be more verbose. The standard we use in new files is that the first letter in a field name is lowercase, the first letter of any subsequent words in the identifier is uppercased.
example: myNewField fooBar
One nice thing about the way our Data Object Model functions is that the case as defined in the DOM is used to automatically case correct all references to the field in code.
Methods are also in a flat namespace and signature space (i.e. HeroScript does not support overloading).
As a result, method names tend to be more verbose. The standard we use in new files is that the first letter of each word is capitalized.
// example: method PathSystemGetPath( callback_node as NodeRef, parameter_set_handle as ID, from_pos as Vector3, to_pos as Vector3) as ID
Local Variables (variables on the stack)
Local variables are all lowercase and words are separated by underscores (_).
The name of the prototype from which the singleton for a system node is instantiated should be in all uppercase.
Beyond the normal common sense of commenting code that requires explanation, you get the most milage out of HeroSense (Intellisense like behaviors) if you comment above a method declaration for WHAT the method does and below it with the most important parameters. (Up to 4 lines before/after the method signature will be displayed).
A fairly good example is found in the Server Script
We found the standard described at http://www.possibility.com/Cpp/CppCodingStandard.html to be a good starting point to thinking about the types of things one should consider in a standard. You may likewise find it useful when codifying your own standards.