CODING STANDARDS
CODING GUIDELINES
General coding guidelines provide the programmer with a set of best practices which can be used to make programs easier to read and maintain. Unlike the coding standards, the use of these guidelines is not mandatory. However, the programmer is encouraged to review them and attempt to incorporate them into his/her programming style where appropiate.
Line Length
It is a good practice to keep the lenghts of source lines at or below 80 characters. Lines longer than this could not be displayed property on some screens and tools.
Spacing
The proper use of spaces within a line of code and enhance readability. Good rules of a thumb are as follows:
-->A keyword followed by a parenthesis should be separated by a space.
-->A blank space should appear after each comma in an argument list.
-->All binary operators should be separated from their operands by spaces.
-->Blank spaces should never separate unary operators such as unary minus, increment("++"), and decrement("-") from
their operands
-->Casts should be made followed by a blank space
Example:
Bad:
cost=price+(price*sales_tax);
print("The total cost is:"+ cost);
Better:
cost = price + ( price * sales_tax ) ;
print ("The total cost is:" + cost) ;
Wrapping Lines
When an exression will not fit in a single line, break it according to these following principles
-->Break after comma;
Example:
Calculate_loan(Parameter1, Parameter2, Parameter3,
Parameter4, Parameter5 ) ;
-->Break after an operator
Example:
log in total_apples = num_my_apples + num_his_apples +
nume_her_apples ;
-->Prefer higher-level breaks to lower-level breaks
Example:
Bad:
longName1 = longName2 * (longName3 + LongName4 -
longName5) + 4 * longName6;
Better:
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longName6;
Align the new line with the beginning of the expression at the same level on the previous line.
Example:
total_windows = number_attic_windows + number_second_floor_windows +
number_first_floor_windos ;
Program Statements
Program statements should be limited to one per line. Also, nested statements should be avoided when possible.
Example:
Bad:
number_of_letters = word.lenth ; b = new JButton [ number_of_letters ] ;
Better:
number_of_letters = word.length ;
b = new JButton [ number_of_letters ] ;
Bad:
strncpy ( city_name , string , strlen ( string ) ) ;
Better:
length = strlen ( string ) ;
strncpy ( city_name , string , length ) ;
Bad:
if (! strcmp ( string1 , string2 ))
{
print (“The strings are equal!” ) ;
}
Better:
status = strcmp ( string1 , string2 ) ;
if (status == 0)
{
print ( “The strings are equal!” ) ;
Use of Parentheses
It is better to use parenthesis liberally. Even in cases where operator precedence unambiguously dictates the order of evaluation of an expression, often it is beneficial from a readability point of view to include parenthesis anyway.
Example:
Acceptable:
total = 3 - 4 * 3 ;
Better:
total = 3 - ( 4 * 3 ) ;
Even better:
total = ( -4 * 3 ) + 3 ;
Inline Comments
Inline comments promote program readability. They allow a person not familiar with the code to mor quickly understand it. It also helps the programmer who wrote the code to remember details forgotten over time. This reduces the amount of time required to perform software maintenance tasks.
As the name siggests, inline comment appear in the body of the source code itself. They explain the logic or parts of the algorithm which are not readily apparent from the code itself. Inline comments can also be used to describe the task being performed by a block of code.
Inline comments should be used to make the code clearer to a programmer trying to read and understand it. Writing a well-structured program lends much to its readability even without inline comments. The bottom line is to use inline comments where they are needed to explain complicated program behavior or requirements.
Avoid using Spanish words and also bad words in comments
Do not keep testing comments inside the code
----------------------------------------IMPORTANT-------------------------------------------------------------
DATABASE LANGUAGE STANDARDS
General Coding Rules
The standard "Who" functionality shold be implemented to enable full accountability for data manipulation. This information is used to track the changes made to a particular record.
The "Who" information is stored in applications tables in the following columns:
CREATED_BY (Not Null, Required)
CREATED_DATE (Not Null, Required)
UPDATED_BY (Not Null, Required)
UPDATE_DATE (Not Null, Required)
All modules that act upon standard applications tables must unclude WHO information maintenance. All tables and the modules which maintain operate on them must also maintain "WHO" information
COMMIT points for transactions should be carefully chosen and based on the business requirements for each module.
DMS Statement
Avoid using a "SELECT (*)" in SQL queries.
Queries should be kept as simple as possible and the driving table (i.e the most selective) for a query should be the last table listed in the "FROM" clause of the "SELECT" statement.
Using functions on indexed columns results in the optimizer ignoring the index and performing a full table scan. In queries that return a large portion of the table data, it may be a performance advantage to shut down the index and perform a full table scan. The simplest method if intentionally shutting down an index is to add zero if one if the indexed columns is numerical, for example:
WHERE mus.org_id = bom.org_id + 0
Codign for Efficiency vs Coding for Readability
There are many aspects to programming. These include writing software that runs efficiently and writing that is easy to maintain.
These two goals often collide with each other. Creating code that runs as efficiently as possible often means writing code that use tricky logic and complex algorithms, code that can be hard to follow and maintain even with ample inline comments.
The programmer needs to carefully weigh efficiency gains versus program complexity and readability. If a more complicated algorithm offers only small gains in the speed of a program, the programmer should consider using a simpler algorithm.
Altough slower, the simpler algorithm will be easier for the other programmers to understand.
UNIT TESTING DURIN DEVELOPMENT
Software can be broken down into modular units which autonomously achieve a specific function. Interacting with one another, these modules are combined to create a complete program. Unit testing looks at software from a modular level, ensuring that the smallest functioning units of software project are operating as specified. It is especially helpful in identifying defects early in the overall development process as individual modules.
General coding guidelines provide the programmer with a set of best practices which can be used to make programs easier to read and maintain. Unlike the coding standards, the use of these guidelines is not mandatory. However, the programmer is encouraged to review them and attempt to incorporate them into his/her programming style where appropiate.
Line Length
It is a good practice to keep the lenghts of source lines at or below 80 characters. Lines longer than this could not be displayed property on some screens and tools.
Spacing
The proper use of spaces within a line of code and enhance readability. Good rules of a thumb are as follows:
-->A keyword followed by a parenthesis should be separated by a space.
-->A blank space should appear after each comma in an argument list.
-->All binary operators should be separated from their operands by spaces.
-->Blank spaces should never separate unary operators such as unary minus, increment("++"), and decrement("-") from
their operands
-->Casts should be made followed by a blank space
Example:
Bad:
cost=price+(price*sales_tax);
print("The total cost is:"+ cost);
Better:
cost = price + ( price * sales_tax ) ;
print ("The total cost is:" + cost) ;
Wrapping Lines
When an exression will not fit in a single line, break it according to these following principles
-->Break after comma;
Example:
Calculate_loan(Parameter1, Parameter2, Parameter3,
Parameter4, Parameter5 ) ;
-->Break after an operator
Example:
log in total_apples = num_my_apples + num_his_apples +
nume_her_apples ;
-->Prefer higher-level breaks to lower-level breaks
Example:
Bad:
longName1 = longName2 * (longName3 + LongName4 -
longName5) + 4 * longName6;
Better:
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longName6;
Align the new line with the beginning of the expression at the same level on the previous line.
Example:
total_windows = number_attic_windows + number_second_floor_windows +
number_first_floor_windos ;
Program Statements
Program statements should be limited to one per line. Also, nested statements should be avoided when possible.
Example:
Bad:
number_of_letters = word.lenth ; b = new JButton [ number_of_letters ] ;
Better:
number_of_letters = word.length ;
b = new JButton [ number_of_letters ] ;
Bad:
strncpy ( city_name , string , strlen ( string ) ) ;
Better:
length = strlen ( string ) ;
strncpy ( city_name , string , length ) ;
Bad:
if (! strcmp ( string1 , string2 ))
{
print (“The strings are equal!” ) ;
}
Better:
status = strcmp ( string1 , string2 ) ;
if (status == 0)
{
print ( “The strings are equal!” ) ;
Use of Parentheses
It is better to use parenthesis liberally. Even in cases where operator precedence unambiguously dictates the order of evaluation of an expression, often it is beneficial from a readability point of view to include parenthesis anyway.
Example:
Acceptable:
total = 3 - 4 * 3 ;
Better:
total = 3 - ( 4 * 3 ) ;
Even better:
total = ( -4 * 3 ) + 3 ;
Inline Comments
Inline comments promote program readability. They allow a person not familiar with the code to mor quickly understand it. It also helps the programmer who wrote the code to remember details forgotten over time. This reduces the amount of time required to perform software maintenance tasks.
As the name siggests, inline comment appear in the body of the source code itself. They explain the logic or parts of the algorithm which are not readily apparent from the code itself. Inline comments can also be used to describe the task being performed by a block of code.
Inline comments should be used to make the code clearer to a programmer trying to read and understand it. Writing a well-structured program lends much to its readability even without inline comments. The bottom line is to use inline comments where they are needed to explain complicated program behavior or requirements.
Avoid using Spanish words and also bad words in comments
Do not keep testing comments inside the code
----------------------------------------IMPORTANT-------------------------------------------------------------
DATABASE LANGUAGE STANDARDS
General Coding Rules
The standard "Who" functionality shold be implemented to enable full accountability for data manipulation. This information is used to track the changes made to a particular record.
The "Who" information is stored in applications tables in the following columns:
CREATED_BY (Not Null, Required)
CREATED_DATE (Not Null, Required)
UPDATED_BY (Not Null, Required)
UPDATE_DATE (Not Null, Required)
All modules that act upon standard applications tables must unclude WHO information maintenance. All tables and the modules which maintain operate on them must also maintain "WHO" information
COMMIT points for transactions should be carefully chosen and based on the business requirements for each module.
DMS Statement
Avoid using a "SELECT (*)" in SQL queries.
Queries should be kept as simple as possible and the driving table (i.e the most selective) for a query should be the last table listed in the "FROM" clause of the "SELECT" statement.
Using functions on indexed columns results in the optimizer ignoring the index and performing a full table scan. In queries that return a large portion of the table data, it may be a performance advantage to shut down the index and perform a full table scan. The simplest method if intentionally shutting down an index is to add zero if one if the indexed columns is numerical, for example:
WHERE mus.org_id = bom.org_id + 0
Codign for Efficiency vs Coding for Readability
There are many aspects to programming. These include writing software that runs efficiently and writing that is easy to maintain.
These two goals often collide with each other. Creating code that runs as efficiently as possible often means writing code that use tricky logic and complex algorithms, code that can be hard to follow and maintain even with ample inline comments.
The programmer needs to carefully weigh efficiency gains versus program complexity and readability. If a more complicated algorithm offers only small gains in the speed of a program, the programmer should consider using a simpler algorithm.
Altough slower, the simpler algorithm will be easier for the other programmers to understand.
UNIT TESTING DURIN DEVELOPMENT
Software can be broken down into modular units which autonomously achieve a specific function. Interacting with one another, these modules are combined to create a complete program. Unit testing looks at software from a modular level, ensuring that the smallest functioning units of software project are operating as specified. It is especially helpful in identifying defects early in the overall development process as individual modules.
Comentarios
Publicar un comentario