Coding Standards: UI/Business/Data Layer Standards
Coding Standards: UI/Business/Data Layer Standards
The Need for a Standard Now that we are in a world where developers are not isolated, but mostly work on group projects with other developers, the need for coming up with a consistent way of doing things has become imminent. Hence, the birth of coding standards. Strict adherence to this coding standard would facilitate everyone during code reviews, troubleshooting of issues and also enable newer developers to easily understand the code when projects are handed over to other teams for maintenance purposes.
2. Use tabs, NOT SPACES, to indent. Indentation should be a matter of style. However, you should always use tabs to indent and, in the following situations, some form of indentation should always be used: Method bodies should be indented from their method delimiters (Sub...End Sub, function{}, etc.) The bodies of If...Then...Else, Select...Case and all looping structures should all use indentation of some kind. Continued lines should be indented, for example: MsgBox Wow! Youve done something drastically wrong and I would & _ suggest contacting a senior manager as quickly as possible!, _ vbExclamation + vbOKOnly, _ Error!
3. Curly brace placement Curly brace placement is a matter of preference. Put the opening brace either on the same line as the constructs beginning statement, or on the line below. In any case, begin the constructs constituent code at least one line below the constructs beginning statement.
try { } catch { // exception handling } finally { // clean up } // do something try { } catch { } finally { } // do something
// exception handling
// clean up
Dont do this
try { // do something // do something else } catch { // exception handling } finally { // clean up }
4. Commenting Use XML documentation commenting (/// complete HTML API documentation. Use in-line commenting (// 5. Other When possible, declare variables used in a single place at the top of a method and instantiate them right before they are used. Counter variables and variables used in the foreach construct may be declared and initialized inline.
RijndaelManaged CryptoStream StreamWriter Stream try { // create a new instance of the RijndaelManaged class rmCrypto = new RijndaelManaged(); // create a CryptoStream, pass it the output stream, and encrypt // it with the Rijndael class cryptoStream = new CryptoStream( targetStream, rmCrypto.CreateEncryptor(m_Key, m_IV), CryptoStreamMode.Write); // create a StreamWriter for easy writing to the output stream streamWriter = new StreamWriter(cryptoStream); // write to the stream streamWriter.Write(encString); } catch { // error handling } finally{ streamWriter.Close(); rmCrypto; cryptoStream; streamWriter; targetStream = new Stream(); or ) <summary> ...
cryptoStream.Close();
Use the #region statement to group related pieces of code together and collapse when not in use.
#region Private properties // Private properties... private long m_securityUserID; private string m_domainAccount; private string m_userEmailAddress; #endregion
HTML/ASP.Net tags should be in lowercase. <html> HTML/ASP.Net attributes should be lowercase with quotes around the values. <font color=red>
Database Standards
1. Tables Table names should use all uppercase and words separated by underscores (ie. FEEDBACK) Table names should be in the singular form. For example, use EMPLOYEE instead of EMPLOYEES Column names are all lowercase and words are separated by underscores (ie. feedback_id) Do not incorporate the data type in the name of a column. This will reduce the amount of work should it become necessary to change the data type later. All primary keys must be integers, preferably an identity field named <table_name>_id. GUIDs may also be used, if the key is needed to be globally unique. Constraints should be named as follows: Primary Key PK_<TableName> (ie. PK_FEEDBACK) Foreign Key FK_<TableName>_<ReferencedTableName> (ie. FK_FEEDBACK_TEMP_FEEDBACK) Unique UNQ_<TableName>_<FieldName> (ie. UNQ_FEEDBACK_feedback_id) Default DF_<TableName>_<FieldName> (ie. DF_FEEDBACK_created_by) All foreign keys should be indexed. Indexes should be named IDX_<TableName>_<FieldName> (ie. IDX_FEEDBACK_feedback_id) If the data type of a field is bit, the name should have a suffix of flag. (ie. active_flag) All fields that have a suffix of _id should be integers. Dont use char or nchar unless you know the data will always be the same size. For example, a state code will always contain 2 characters (TX).
2. Stored Procedures Names All stored procedures show be named <APPLICATION or SECTION>_<Function>. The application or section should be in all caps and should be used to differentiate between different pieces of functionality. The function portion should be in camel case, much like .Net methods above. Eg., CONFIGURATION_GetConfigSection Variables All parameters should be named @p_<type><VariableName>. Eg., @p_iFeedbackID Declare all local variables at the top of the stored procedure. Datatype prefixes should be as follows: Data Type strings (char, nchar, nvarchar, varchar) tinyint, smallint, integer, bigint smalldatetime, datetime bit decimal float Prefix str int dt bln dec flt
mny num
Readability For any conditional or loop construct, use the following indentation style: IF @strVariable BEGIN Statement Statement END ELSE BEGIN Statement Statement END
1 2
1 2
If the conditional code only contains one statement, dont use begin and end. IF @strVariable Statement 1 ELSE Statement 1 Use tabs when indenting, not spaces. Error Handling Use the following error handling for all insert, update and delete statements: IF @@ERROR <> 0 BEGIN RAISERROR(An error occurred while adding a <TableName> record., 16, 1) RETURN END Maintenance History Include the following template at the top of the stored procedures: /****************************************************************** Name: <Stored Procedure name> Description: <Stored Procedure description> Arguments: Returns: <Input/Output parameters and brief description> <brief description of return values>
Modifications: Date Developer Description -------------------------------------------------------------------------------------------------<Date> <Developer Name> <Description> ******************************************************************/ Cursors
Use cursor functionality cautiously. In other words, if you dont have to use a cursor, dont. If you do need a cursor, make sure the cursor type is LOCAL and FAST_FORWARD. This is the fastest cursor type because it is forward-only and read-only. Security Give execute permissions to each stored procedure to the application SQL account. Applications should interface with data through stored procedures only. In other words, dont give direct table access to the application login. General Always add SET NOCOUNT ON to the top of the stored procedure and add SET NOCOUNT OFF at the very bottom of the stored procedure. Dont leave any print statements used for debugging in the stored procedure. Dont leave commented code in the stored procedure. Do not prefix stored procedures with sp, which is a prefix reserved for identifying system stored procedures. 2. DTS Packages All DTS packages should include a description. DTS names should be named <Database>_<Table>_<One Word Description>. For example, Common_ASSOCIATE_INFO_Update. 3. Jobs All jobs packages should include a description. Jobs names should be named <Database>_<Table>_<One Word Description>, and match the name of the DTS package it runs. For example, Common_ASSOCIATE_INFO_Update. All Jobs should notify an operator AT LEAST on failure. 4. Roles All database roles should be in the form db_<Database>_<Role>. For example, db_common_readonly. 5. General All database objects should be owned by dbo. Use sp_changeobjectowner, if needed.
3. Folder Structure The folder structure should match the menu system as much as possible. 4. Images All images should be in the includes\images folder, with a subfolder to hold the tool specific images. Example: includes\images\header includes the images for the header.