Novo's scripting guidelines!

[Novo]

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:

NPC Code:

---

  Be explicit:

    Refactor your scripts, 

    and make sure they have the least amount of unrelated

    scripts.

    

    Functions should show what they get, 

    and no shorthand.

    

  Naming Convenction:

    Variables should refer to be treated the same.



    e.g.:

      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.

  

    e.g.:

      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.



  Problem-Oriented:

      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.

    

    E.g.:

      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.



    E.g.:

      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.

---

[Codein]

I've been looking for this old gem. This should be stickied as it holds pretty helpful guidelines.

[xXziroXx]

Yet another bump for a should-be-stickied thread! Not a lot of threads help new programmers as much as this one.

[Bell]

Sticky requested.