View Full Version : Novo's scripting guidelines!

11-03-2007, 12:49 AM
No... I'm not going to say my way is the best way to style. Basically, I've been working on a notes module on my server in how to make maintainable code. It's been getting bigger and all... But I think it could help the community by having them out here:

Be explicit:
Refactor your scripts,
and make sure they have the least amount of unrelated

Functions should show what they get,
and no shorthand.

Naming Convenction:
Variables should refer to be treated the same.

item and itemID are NOT interchangible.
item is the item-data-construct, and itemID is the
reference to the data.

Hide Information:
Do not show data structure. Keep how the information is
stored and what the information is SEPARATE.

There is no way to get item props without using:
(@"-Items").getItemProp( itemID, propName );

This shows that if the format of how the props change,
only that function needs to be changed.

Self-Explanatory Code:
When you do make a function, make sure you know
exactly what it does by reading it. If it is too
confusing, chances are... It's wrong. If some
information is specific or confusing, comment on it.

Variable Live Time:
When you use a variable, try keeping the first and
last use of the variable as short as possible. Having
a variable over a large live time makes it unneededly
difficult to track the changes in a routine.

Variable Life Span:
When you use a variable, try keeping the uses of the
variable as close to each other as possible. Having a
variable initiated at the beginning of a function when
it is only used near the end allows unneeded risk that
the variable changed.

Group Related Statements:
If two statements have a common theme, put them
together. This allows other people to easily grasp
the work you're doing. By putting together common
themes, you create an abstract idea of WHAT it is doing.

When working on a particular problem, keep in mind
that you're trying to solve a problem. Try and avoiding
programming the solution... But rather aim at solving
the problem. Basically, this means name your data
structures on the abstract implications rather than the
immediate method of solving.

Employees shows that it's a list of Employees
inputArray doesn't tell anything other than it's
an array.

Loose Coupling:
Try to keep all the systems independent from each
other. Don't try making the systems intertwine much.
To reduce coupling, try to avoid making function calls
to other npcs as much as possible. Loose Coupling can be
defined as how much dependencies you have: The lower,
the better.

The exception to this is the mediator / protocol
systems. The protocol mainly is used as a mediator
between two systems. For example, the -Items class
doesn't do much work on its own, however, it mediates
the data between the item-system and the GUI's. These
classes can be used for in a lot of other systems...
This is because the protocol system is made for this
purpose. ( all data that that -Items provide can be
obtained manually... But -Items makes this systematic. )

Keep GUI and Logic SEPARATE:
There is nothing more frustrating then having to
analyze an entire chunk of code because you embedded
code within your GUI. Try to keep the amount of logic out
of GUI's, and instead have Control-systems ( or protocols )
to acquire the given information.

The GUI in $Inventory basically gets all its data from -Items.
Through the use of public functions, $Inventory can acquire all
required data: item, icon, quant, worn, ... etc...
If the logic was all in the GUI, when the item system changes,
you would have to work into the inventory all the new systems.
With this method, you have a distinct place to work.

12-01-2009, 11:17 PM
I've been looking for this old gem. This should be stickied as it holds pretty helpful guidelines.

01-15-2010, 10:07 PM
Yet another bump for a should-be-stickied thread! :) Not a lot of threads help new programmers as much as this one.

01-16-2010, 12:32 AM
Sticky requested.