SRP Editor Settings
Without being presumptuous, it is assumed that the SRP Editor will be the code editor of choice. While this itself is not a requirement, there are settings that should be employed to make it easier for stored procedures to comply with various protocols.
| Setting | Value | Comments |
|---|---|---|
| Tab Width | 4 | The width itself is not essential, but since all SRP FrameWorks code is already based on a width of 4, it will just make it easier if all stored procedures maintain the same width. |
| Tabs as Spaces | Checked | This has been debated by coders for ages, but our philosophy is that the code should look the same regardless of what code (or text) editor is used. Since various editors can display tab characters with varying widths, the ability to see someone else's code as that coder intended becomes compromised. Using spaces in lieu of tabs prevents this problem. This feature eliminates the hassle of having to press the space bar multiple times. Just press the Tab key and it will automatically move the cursor forward the proper number of spaces. Similarly, Shift+Tab does the reverse. Shift+Backspace and Shift+Delete also remove spaces as if they were tabs. |
| Edge Column | 120 | The purpose of using the edge column is to enable the developer to note when a line of code or a comment is going to appear too far to the right. While it is important to capitalize on horizontal space, extending too far requires the developer to use the horizontal scroll bar to see everything. 120 columns works well for most medium-end wide screen monitors. The Edge Indicator should be set to anything but "None". |
| Autocomplete | Service Metadata Only | To be more specific, Service Metadata Only would be the minimum setting. The other option would be Including Keywords since this would also include Service Metadata. Since SRP FrameWorks is moving toward a service oriented architecture, enabling the SRP Editor to provide service metadata autocomplete options will be critical for protective development. |
Stored Procedure Standards
The following standards will be broken down into sub-categories. Within SRP FrameWorks there are different types of stored procedures. Some standards apply to all of them but others are unique to each type of stored procedure so these will be documented per sub-category.
General Standards
Please see the Naming Standards article on how stored procedures should be named. The following guidelines apply to how the code itself should be formatted.
| Item | Comments |
|---|---|
| Variable Naming | Variables should be verbose, although not to the point of being unwieldy. The key is to make sure that any developer reading the code will have a good idea as to what the variable is used for. This also applies to variables used to control loops. Thus, For i = 1 to NumItems is not recommended. The variable "i" by itself does not help the developer to know what is being iterated. Quite often this variable is used within the code itself, such as a pointer within a dynamic array. Labeling this variable properly will make it easier to read the code as well as debug it. In some cases a variable can be short only if it is a throwaway variable (i.e., has no value within the code itself.) This can happen when the developer needs to call a function but the return response is not needed, such as when the Set_Property function is used. |
| Variable Casing | Verbose variables should be easy to read. Therefore, camel casing is recommended so that each word within the variable can be identified. For instance, NumItems is easier to read than NUMITEMS or even numitems. While Basic+ is a typeless language, there will be situations where it will be useful to name the variable for the type of data it will contain. Thus, it is also acceptable to employ a lower case type prefix. Thus, intNumItems informs the developer that this variable will only contain integers that represents the number of items. |
| Label Naming | Labels (aka. GoSub Labels) should be verbose, with each word separated with an underscore. In this sense, labels are named just like stored procedures. This makes it easier to distinguish labels from variables, which are also verbose. |
| Label Casing | The first letter of each word in the label should be uppercased. For instance, GoSub Calculate_Surface_Area. |
