The following lists the violations that can be produced by MQ-Precise while analyzing Message Broker code. They are broken down below into the categories standards, performance, correctness and other. For a complete list of the rules please follow this link. Queue names should comply to a set length, should be in uppercase, should not contain underscores, cannot start with SYSTEM. Enforcing a queue names adds to consistency and prevents any issues at run time with MQ names that affect functionality. If the environment is to be used, then the Variables part of the tree should be used.
|Published (Last):||3 November 2004|
|PDF File Size:||11.86 Mb|
|ePub File Size:||6.43 Mb|
|Price:||Free* [*Free Regsitration Required]|
Coding conventions not only help improve code readability, they also discourage the use of wasteful and error-prone programming practices. Coding guidelines can also encourage the development of secure software that has better performance. Finally, should source code need to be shipped as a product, coding conventions can help ensure a quality in presentation. Topics include file naming and organization, file layout, comments, line wrapping, alignment, white space, naming conventions, frequently used statements, and useful programming practices.
In general, ESQL files longer than lines are cumbersome to deal with and should be avoided, by ensuring that a single ESQL file implements the message flows that relate to each other, and by abstracting reusable code into separate ESQL files.
They also serve to create local name spaces so that procedures and functions can be reused, and yet be distinguished by the schema they are in. In short, broker schemas are organizational units of related code that address a specific business or logical problem. Therefore, related ESQL files should be placed in their own schema.
View image at full size. They are not globally reusable and can only be used within the same broker schema. They are implicitly constant. They are globally reusable and can be called by other functions or procedures in ESQL files within any schema defined in the same or another project. A module defines a specific behavior for a message flow node. A module must contain the function Main , which is the entry point for the module.
The constants, variables, functions, and procedures declared within the module can be used only within the module. In general, the names assigned to various ESQL constructs should be mnemonic and descriptive, using whole words and avoiding confusing acronyms and abbreviations. Of course, you need to balance descriptiveness with brevity, because overly long names are hard to handle and make code harder to understand.
The following table provides naming conventions for ESQL broker schemas, modules, keywords, correlation names, procedures, functions, variables, and constants.
An ESQL file should always begin with a file-header comment that provides the name of the file, a brief synopsis of the purpose of the file, the copyright, and author information. The example below illustrates one possible format for such a header, but any suitable alternative that clearly conveys the same information is acceptable.
The header is 80 characters in length. The description text should consist of complete sentences, wrapped as needed without using hyphenation. List each author on a separate line. Every module definition must be preceded by a module header comment. A module header contains descriptive text that consists of complete sentences, wrapped as needed without using hyphenation:. Every procedure definition must be preceded by a procedure header comment. A procedure header contains descriptive text that consists of complete sentences, wrapped as needed without using hyphenation.
The parameter descriptions need not consist of complete sentences -- brief, descriptive phrases should suffice. However, they should be preceded by a hyphen and properly aligned with one another:.
Add comments to ESQL source code to clarify program logic and convey information that is not immediately obvious from inspecting the code. Do not add too many comments -- they can become redundant, complicate code maintenance, and get out of date as the software evolves. In general, too many comments indicate poorly written code, because well written code tends to be self explanatory. Implementation comments can be written in single-line, block, or trailing forms, as described below.
A single-line comment is a short comment that explains and aligns with the code that follows it. It should be preceded by a single blank line and immediately followed by the code that it describes:. Block comments are used to provide descriptions of ESQL files, modules, procedures, and functions. Use Block comments at the beginning of each file and before each module, procedure, and function.
You can also use them anywhere in an ESQL file. Block comments inside a function or procedure should be indented at the same level as the code they describe. Precede a block comment by a single blank line and immediately follow it by the code it describes. Because shorter comments with expressive code are always preferable to lengthy block comments, block comments should be rarely used within a procedure or function.
Example of a block comment:. Trailing comments are brief remarks on the same line as the code they refer to. Indent these comments to clearly separate them from the relevant code. If several trailing comments relate to the same segment of code, align the comments with one another. Trailing comments are usually brief phrases and need not be complete sentences:.
Lines of ESQL source code should be wrapped and aligned according to the following guidelines:. The ESQL sample below illustrates a case where an indentation of eight spaces should be used instead of the usual alignment to avoid deeper indentations that would result in confusing code. Finally, the ESQL samples below illustrate line wrapping and alignment practices. The first is preferable because the line break is inserted at the highest level possible.
Put declarations right after the broker schemas or at the beginning of modules, functions, and procedures. One declaration per line is recommended:. The authors would like to thank Steve Chai chai ca. United States. A schema name reflects the file system name leading the location of files in this schema.
Each level in a schema name is mapped to a directory name. To be supported by any file system, schema names should consist of lower case alphanumeric characters. The names should be prefixed with the reverse of the company URL.
A module name should consist of more than one alphanumeric character, start with an upper case letter, and have mixed case, with the first letter of each internal word and all letters of acronyms in uppercase.
It must match any label assigned to a compute, database, or filter node in a message flow that uses the module. If more than one such node in a message flow uses the same module, add additional characters to the node labels in order to differentiate between them. ESQL keywords should be uppercase, although they are not case sensitive. A field reference or correlation name should start with an uppercase letter and have mixed case, with the first letter of each internal word and all letters of acronyms in uppercase.
A variable name should start with a lowercase letter and have mixed case, with the first letter of each internal word and all letters of acronyms in uppercase. Since a variable name should start with a lowercase letter, it should not start with an acronym. Trivial variable names such as i or x can be assigned to temporary variables of limited scope and importance at your discretion. A procedure or function name should consist of more than one alphanumeric character, start with a lowercase letter, and have mixed case, with the first letter of each internal word and all letters of acronyms in uppercase.
The first word of the name should be a verb.
Using ESQL in WMB/IIB
Sometimes while writing transactional code in ESQL, we encounter need for committing certain database operations irrespective of success or failure of parent transaction. For example, writing information to a log; updating a sequence number in a table based on some business logic etc. Recently we encountered such a situation in a healthcare project I was working, where a sequence based on table was used by multiple processes batch and real-time by incrementing and then updating the sequence with new number based on some business logic. Since batch process may take longer time to complete transaction than real-time, database locks were occurring on the common resource Sequence table.
Subscribe to RSS