Minor
Code Rules in Minor Severity
Category | Severity | Name | Description |
---|---|---|---|
|
|
|
The rule "Boolean checks should not be inverted" means that when writing code for SQL Server, boolean checks should not be written in a way that inverts the logic of the check. For example, a check for a value less than 10 should not be written as "value greater than or equal to 10". This is because inverting the logic of the check can cause confusion and make the code harder to read and understand. Additionally, it can lead to errors in the code and can be difficult to debug. Therefore, it is best practice to write boolean checks in the most straightforward way. |
|
|
|
This code rule states that any CATCH clauses used in a SQL Server script should not simply rethrow the exception, but should also do something else, such as logging the error, or performing some other action. This helps to ensure that exceptions are handled properly, and that errors are not simply ignored. |
|
|
|
The "Code elements must not be unused" rule states that all code elements must be used in a SQL Server database. This includes all variables, functions, stored procedures, views, and other objects. Unused code elements can lead to errors and unexpected behavior, and can also make it difficult to troubleshoot issues. This rule ensures that all code elements are used in a meaningful way and that all objects are properly maintained. It also helps to ensure that the code is efficient and well-structured. |
|
|
|
The "Column references should not have more than two-parts" rule states that when referencing columns in a SQL Server query, the column name should not contain more than two parts. This means that a column name should not contain any dot notation or any other type of delimiter which would create multiple parts. For example, a column name such as "dbo.users.name" would not be allowed, while "users.name" would be allowed. This rule is in place to ensure that queries are as simple and efficient as possible. Having multiple parts in a column reference can lead to confusion and can make it difficult to read and understand the query. It can also lead to errors if the wrong column is referenced. |
|
|
|
The Empty Statements should be removed code rule in SQL Server states that any empty statements in a SQL script should be removed. Empty statements are those that do not contain any content and are not required for the code to execute. Examples of empty statements include blank lines, comments, and empty IF, WHILE, and BEGIN/END blocks. Removing empty statements can help reduce the complexity of the code and make it easier to read and understand. Additionally, it can help reduce the number of errors that may occur during execution. |
|
|
|
The "Jump statements should not be redundant" rule states that SQL Server code should not contain redundant jump statements. Jump statements are commands that cause an immediate exit from a loop or block of code. Examples of jump statements include "BREAK", "GOTO", and "RETURN". Redundant jump statements are those that are unnecessary, as they do not add any value to the code and can lead to confusion. The use of redundant jump statements should be avoided in SQL Server code, as they can lead to unexpected behavior and can make the code difficult to understand. |
|
|
|
The "LIKE clauses should not be used without wildcards" code rule for SQL Server dictates that any LIKE clause used within a query should include a wildcard character. Wildcards are special characters used to represent one or more characters in a string. The two most common wildcard characters are the percent sign (%) and the underscore (_). For example, a LIKE clause used to search for all customers whose last name starts with "Mc" would be written as "LIKE 'Mc%'". Without the wildcard character, the query would only return results for customers whose last name is exactly "Mc". |
|
|
|
The "Lines should not be too long" code rule for SQL Server states that lines of code should not exceed 80 characters in length. This is to ensure that the code is easier to read and understand. Longer lines can make it difficult to read and understand the code, and can also make it difficult to debug or modify the code. By limiting the length of lines, code is more manageable and easier to work with. |
|
|
|
The "Local variable and parameter names should comply with a naming convention" code rule states that all local variables and parameters used in a SQL Server database should be named in accordance with a specific naming convention. This helps to ensure better readability and maintainability of the code. For instance, a naming convention might require that all local variables start with a lowercase letter, and all parameters start with an uppercase letter. Additionally, the naming convention might also include rules for how to name objects, such as tables, stored procedures, etc. By following a naming convention, it becomes easier for developers to quickly identify the purpose of a variable or parameter. |
|
|
|
The SQL Server code rule "Methods must not be empty" requires that all methods in a SQL Server program must contain code and not be left empty. This rule is in place to ensure that all methods are properly defined and implemented, and that they are not left empty or incomplete. This rule also helps to ensure that all methods are properly tested and debugged, as an empty method would not be able to be tested or debugged. This rule is important for maintaining code quality and ensuring that all methods are properly implemented. |
|
|
|
The code rule "Multiple variables should not be declared on the same line" states that when declaring multiple variables in a SQL Server script, each variable should be declared on a separate line. This helps to improve readability and maintainability of the code, and can also help to detect errors, such as typos, more easily. Additionally, when debugging code, it can be easier to identify which line a specific variable is declared on. |
|
|
|
The "Naming conventions must be applied" code rule for SQL Server requires that all database objects, such as tables and columns, must be named according to a specific set of conventions. These conventions are designed to improve the readability of the code and to make it easier to identify the purpose of each object. The conventions may include the use of upper and lower case letters, underscores, and other formatting rules. Following these conventions will help ensure that the code is easier to read and maintain. |
|
|
|
The rule "Non-standard comparison operators should not be used" states that any comparison operators other than the standard ones provided by SQL Server should not be used. This includes operators such as <, >, =, !=, <>, etc. These operators should only be used for comparing values in the same type, and not for comparing values between different types. This rule is important for ensuring that queries are properly formed and that data is accurately compared. |
|
|
|
The rule "Objects should not be duplicated (same name and same type)" states that within a SQL Server database, objects should not have the same name and type. This means that if an object of a certain type (e.g. table) with a certain name already exists, then an additional object of the same type and name should not be created. This is important to ensure that the database is organized and efficient, and that objects are not unnecessarily duplicated. |
|
|
|
The rule "Reserved keywords should not be used as identifiers or object names" in SQL Server means that any words that are part of the SQL Server language should not be used as identifiers or object names. This includes words like SELECT, INSERT, UPDATE, DELETE, WHERE, and ORDER BY. Using these words as identifiers or object names can cause confusion and lead to errors. It is best to use more descriptive names for identifiers and object names to avoid any potential confusion or errors. |
|
|
|
The "Scripts must be commented" rule for SQL Server code states that all scripts must include comments that explain the purpose of the code and the actions it is taking. This is important for the readability of the code, as well as for maintenance and debugging. It is also important for ensuring that the code is understandable by other developers who may need to work with it in the future. The comments should be clear and concise, and should include any assumptions that have been made when writing the script, as well as any potential pitfalls that may be encountered. By following this rule, developers can ensure that their code is well documented and easily understandable by others. |
|
|
|
This SQL Server code rule states that scripts should not exceed a certain size. This is to ensure that scripts are manageable and maintainable. It also helps to reduce the risk of errors and improve performance. Scripts that are too large can be difficult to debug and can cause performance issues. By limiting the size of scripts, developers can ensure that scripts are manageable and maintainable. This rule should be enforced to ensure that scripts are well-structured and optimized for performance. |
|
|
|
The "String literals should not be duplicated" code rule for SQL Server ensures that string literals are not used multiple times in a query or stored procedure. This rule helps to reduce code complexity, as well as improve readability and maintainability of the code. It also helps to minimize the amount of code that needs to be written, as well as reduce the chances of errors being introduced as a result of duplicate strings. For example, if a query contains the same string literal multiple times, it can be replaced with a single reference. This can help to improve the performance of the query, as well as reduce the amount of code that needs to be written and maintained. |
|
|
|
The "Tabulation characters should not be used" rule in SQL Server states that tab characters should not be used to define or separate elements in a query, such as keywords, identifiers, literals, or operators. Instead, spaces should be used as the separator. This is to ensure that the query is readable and consistent across different platforms. |
|
|
|
The "Triggers should not PRINT, SELECT, or FETCH" rule states that triggers should not use the PRINT, SELECT, or FETCH commands when executing code. These commands are used to display data from a database, and should not be used in triggers because they can cause unexpected results. Instead, triggers should use the INSERT, UPDATE, and DELETE commands to modify data in a database. This rule ensures that triggers are used properly and do not cause unexpected results. |
|
|
|
The "Unused Local Variables Should Be Removed" code rule for SQL Server requires that any unused local variables be removed from the code. Unused local variables are variables that are declared but not used in the code. This rule is designed to help keep code clean and efficient by removing unnecessary variables that are declared but not used. Removing unused variables can help improve the readability of the code and reduce the amount of memory and processor resources used by the code. This rule can be enforced by a code analysis tool or manually by a developer. |
|
|
|
Using hardcoded IP addresses in SQL Server code is considered to be security-sensitive because it can easily be exploited by malicious actors. This is because hardcoded IP addresses are static and can be easily identified by hackers, which makes them vulnerable to attack. Additionally, hardcoded IP addresses can be used to bypass authentication and authorization checks, allowing malicious actors to access sensitive data or gain unauthorized access to a system. To prevent this, developers should avoid using hardcoded IP addresses in their code and instead use dynamic IP addresses that change regularly. Additionally, developers should always use secure protocols and encryption when communicating with external systems. |