Coding Standards

GLua Coding Standards Last edited: 14th September 2020

Variable Names

Variable names must contain a prefix of their data type. For example: pPlayer, vVector, flFloat, fFunction.

Rules

• This applies to function arguments as well
• This does not apply to table indexes
• Do not use underscores unless you are using the same kind of variable name (e.g., in an iterator)

Prefix List

Prefix	Type
a	Angle
v	Vector
fl	Float
i	Integer
s	String
e	Entity
p	Player
o	Object
f	Function
t	Table
x	Any value

note

If you know what type the value will be, don't be lazy - just do it properly.

General Conventions

• Network strings and hook identifiers must follow the format: "Monolith.{ModuleName}.{Identifier}"
• Function names in the global Monolith scope must use UpperCamelCase
• Use American-English spellings - no non-English spellings are permitted
• For accessors and modifiers - define functions with Get/Set respectively
• Do not use C comments or operators - use Lua comments and operators only (--, --[[]])
  • This also applies to using not instead of ! - this is important
• Spacing: Include spaces between parentheses or braces only if there are parameters/arguments (( ) and { })
• Don't use unnecessary parentheses in statements and functions - get a linter
• When using the same function or variable more than once in a single scope, localize it
• Never use semi-colons (seriously, don't do it)
• Static variables that will never be modified should be defined with UPPERCASE_VARIABLE

Code Example

util.AddNetworkString( "Monolith.Module.PerformNetworkAction" )

hook.Add( "PlayerInitialSpawn", "Monolith.Module.DoStuff", function( pPlayer )
    local sVar = "Monolith"
    local flVar = 42.021269
    local tVar = { 1, 2, 50 }

    util.FindPlayer( "Flixs" ):Kick( "Idiot" )

    pPlayer.tTable = {
        oneString = sVar,
        oneFloat = flVar,
        oneTable = tVar
    }
end )

Comments

Comments should not be over-used. Use them only when utterly required. Using them on every single line will just annoy other developers.

If you're creating a function that needs documentation for other developers, use this template:

Documentation Template

--[[AddThing
    description:
        This is my certain setting
    args:
        sVar - variable name for the function
        sName - display name for the function
        bDefault - default boolean value for the function
        tData - extra data for the function
]]--

Code Repetition

When writing code, aim to have no code repetition. If you have some operation that is done repeatedly or some long conditional you check repeatedly, create a local function for it.

Module Encapsulation

When creating a module:

• Keep all your code contained within that module
• Use local functions when possible
• Create global functions for other modules to interact with your module (like how the inventory has functions for inserting, removing, finding, etc.)

Be Consistent

Code in a consistent and completely uniform manner. Do not get lazy. You are not the only one working on the project, and your insistence on coding in your own manner will cause problems when other developers need to understand your code.

Performance Tips

General Tips

• Don't localize values when they are only used once
• Localize static variables outside of functions - don't allow them to be called repeatedly for no reason
• If using a render hook for drawing info on an entity, use the entity range cache instead of regular postdrawtranslucent or postdrawopaque

Optimization Guidelines

• Avoid nested loops when possible
• For expensive operations over large collections (e.g., paydays for all 110 players), use a throttled timer to amortize the cost over time instead of doing it all at once
• Avoid using a think hook for each entity - instead use one throttled think hook to loop over the entities