Cstrike
2010-12-07 14:09:33
How to become a Reflection developer
This may be updated from time to time, and if so– you are responsible for what is on here
This may be updated from time to time, and if so– you are responsible for what is on here
No one has really laid any groundwork for the requirements, so I'll post them. Other reflection dev's can add their own stuff that they feel is necessary.
Thus far, you must meet all of these requirements for one of these blocks of what is needed:
Global requirements you must have:
- Need TortoiseSVN or a way to upload your SVN stuff to the repository. We will hook you up and teach you later how to commit if you get accepted and you don't know how to commit. It's easy.
If you cannot do this, we can make exceptions if you provide is with a way of doing so (ex: posting your updated code on the board). Of course we will place heavy emphasis on having TortoiseSVN, just the nature of the game.
Block 1:
[BANANA][LEFT]
- Understand SRL
- Can code Reflection comfortably
- Able to make new useful include functions, and will do so once promoted
- Have posted your examples in this sub-forum (doesn't have to be committed/accepted, as long as it shows you know the reflection core)
- Know the standards and apply with codes near or at perfect standards (See Nava2's post on standards, which I will provide by edit at the end of this file)
- Active SRL forum-comer (you don't need to have a stupid-high activity rating like 90%+ though)
- Must be able to use hooks with SMART functions like SmartGetFieldInt to do data grabbing from the SMART client.
- Should have a great attitude, if you've got a terrible one this is grounds for denying an application. Don't worry, this is reserved for people who troll the boards all the time and cause problems everywhere… don't freak out if you've got one or two people who don't like you. No big deal. Won't affect your app.
- Being on IRC is a big bonus to your app because we can talk to you easily, but is not required at all to be a dev.
- Provide links to your code[/LEFT][/BANANA]
OR
Block 2:
[BANANA][LEFT]
- Have your own hook updater
- and/or Understand the client in such a way that it will help us
We are heavily in favor of block 2 at the moment, but that does not diminish your chances for block 1
How to apply
Send one of us a PM. See who is active, if it looks like a reflection developer is completely gone (ex: Drags111), don't send them the app or you'll never hear from them again. Or you could send all of us a PM: mormonman, Naike, Narcle, Nava2, and/or pyroryan (in alphabetical order so no favorites).
What must you include on your app?
Doesn't need to be formal, just a "Hi I'm interested on being an applicant, here are links to some of my stuff or scripts that show my knowledge"
+ stuff here
Then a poll opens up on the dev boards and we vote on you, and will PM you with the response. Ideally we will try and vote on it within a few days to a week. Should only take a week for those who are busy, and it will obviously be slower during the exam/finals time than during the summer.
If you don't want to PM someone, post here :)
Thanks.
STANDARDS:
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".
