HeroScript Code Standards

From HEWIKI
Jump to: navigation, search

Contents

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

Names

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.

Class Names

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

Abstract Classes

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.

 example:
 AbstractPathSystemHandler

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).

 example:
 FooBarClassMethods

Scripts

Much like Class Method Scripts, scripts should have the first letter of each world in uppercase.

 example:
 BarFoo

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

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 (_).

 example:
 user_account_name

System Nodes

The name of the prototype from which the singleton for a system node is instantiated should be in all uppercase.

System nodes

Comments

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).

HeroSenseMethodSignatureComments.gif

A fairly good example is found in the Server Script _PathSystemClassMethods.

HeroScriptComments.gif

Reference

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.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox