SRL Archive - Devs' Corner

As the randoms is starting to fall into place, I think next step is to agree on a standard for the reflection include?

Randoms

Ideas? Suggestions?

From: Nava2
I think a new list needs to be created, I'll start with the old ones, edited:

• Indenting will be two spaces per level. You can indent by selecting text in Simba and pressing Ctrl+Tab and move backwards by hitting Ctrl+Shift+Tab.
• Margins will be set to 80 characters. Try not to make too long lines. This is because of general coding standards set by the Unix Terminal.
• The begin statement appears on its own line. The end statement always
matches the begin statement by columns. Example:
• Do not combine two or more statements on a single line. Write each on its own line.
• Use semicolons at the end of the lines where appropriate. PascalScript allows lines without semicolons but you should use them everywhere, except after var, begin, then, else repeat, do and before else.
• Use spaces after commas and arithmetical signs.
Example:
• There shall never be white space between an open parenthesis and the next character. As well, there will be a space between logical operators and conditions in conditional statements.
Example:

if ((x = 5) and (y = 5)) then
  DoThis;

• Object Pascal language reserved words and key words shall always be completely lowercase. Never capitalize words that SCAR displays in bold. It's completely unnecessary and looks ugly!
• Routine names shall always begin with a capital letter and be camel-capped for readability.
Example:
• Routines shall be given names meaningful to their content. Routine name DoStuffWithSyAndSy is not meaningful, but name OutputProgressReport is.
• Where possible, procedure and function formal parameters of the same type shall be combined into one statement
Example:
• All formal procedure and function parameter names will be meaningful to their purpose.
• All functions should always return some value. Do not rely on SCAR initializing procedure return value automatically! This means: If its a Boolean result, set it to false initially, if its an integer set it to 0/-1, and a string would be ''.
• Variables will be given names meaningful to their purpose. These names will start with a lowercase letter and be Camel Capped for readability. That includes local and loop control variables, although in this case single character names are acceptable. For loop control variables, try to use the variables: i, j, k, l, and h.
• Boolean variable names must be descriptive enough so that their meanings of True and False values will be clear.
• Variable declarations start in next line after var statement and are indented.
Example:
• Use of global variables is discouraged. However, they may be used when necessary. Global variable naming rules are as follow:
Forms and controls are prefixed with their individual prefixes. Examples: frmMainForm, lblUser, txtPassword, imgPreview etc. DTMs will be marked with dtm prefix as in dtmFishingSpot. Character sets will be marked with chr prefix as in chrChatChars. Bitmaps will be marked with bmp prefix as in bmpFishingNet. Include global variables will be marked with g prefix then include initials as in gOsiStartTime. Normal global variables will be marked with g prefix as in gNumFishCaught.
• Type names that are reserved words shall be completely lowercase as in string. For other variable names, the first letter shall be uppercase, and the rest shall be camel-capped for clarity as in Integer.
• The most likely case to execute in an if/then/else statement shall be placed in the then clause, with less likely cases residing in the else clause(s). This improves performance as well as readability.
• For all condition statements, conditions will be encased in a set of parenthesis. This is general coding standard and allows for more obvious reading.
• If multiple conditions are being tested in an if statement, conditions should be arrange from left to right in order of least to most computation intensive. If condition statement is complex, replace it with function or Boolean variable with a meaningful name. This improves readability and makes code self-documenting.
• Use of informational file header is encouraged for all script and include files.
Use Script > Script Properties from Simba menu to enter script information.
• All variables, functions, procedures, and constants should be properly commented. One can choose their own style, but use of {} should be put forward over //.
• Constants Constants should be used as often as possible. This allows for easier readability and self-explanatory code. Constants should be prefixed with a descriptive meaning, usually associated with the File or the Function. They will follow the format: *FILE*_*FUNCTION*_*VALUE*. They will be camel capped, and the *FILE* token can be left out if it is part of a script and only if it a local constant. If the Constant is used globally in a script it will be prefixed with "gbl".

Comments, ideas?

Comments, ideas?

I dislike having lowercase vars, many people don't do them as well.

Such as
iTime, I, H ect.


Everything else looks fabulous :D

camel capped vars

~RM

Nava's got it. Those are basically the same as MSI's standards also.