DGIVEDUKYIV_2011_7 - papers
8
pages
English
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
8
pages
English
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
- cours - matière potentielle : curriculum
- exposé - matière potentielle : from ‘experts
- mémoire - matière potentielle : the people
- exposé
- expression écrite
- mémoire
- cours magistral
- cours - matière potentielle : classes
- cours - matière potentielle : among immigrant youth
- national government funding
- outside school
- racism
- diversity
- social capital
- w.
- young people
- children
- process
- individuals
Introduction
Standards & Guidelines:
EIS Programming Guidelines - Banner
The main intention of this standard is to define the content of code developed by the department. This standard is not intended to cause violation of the look and feel of any vendor product being maintained or implemented by the department. When enhancing vendor products or writing interfaces to vendor products, follow discernable standards of the product with complete documentation of any exceptions.
This document contains the standards that apply to all software developed for use with Georgia Tech’s SCT Banner system. These standards apply to any new or modified code being implemented or maintained by the department for use with the SCT Banner product. These standards apply equally to whatever language the analyst chooses to use. These standards should be used and enforced by the analyst responsible for cross-testing each module.
All languages may not be individually addressed. The appendices of this document will attempt to provide coding examples of the most common languages being used by the department.
Documenting Code
Headers
Developers must include standard headers in all new code.
The following header is required:
/*******************************************************************
NAME
Name of module. Include the name used to store the module in RCS as well as the text descriptive name of the module.
AUTHOR
Original Programmer's name and date.
PURPOSE
Brief description of what this module does. Include applications for which this module is used.
RESTRICTIONS
List conditions needed for running this program. May the program run from a job submission routine or from the command line? May the program be run during normal business hours? Must the job run through completion before it can be run again? Is table locking a factor?
Page 1 of 8
07/17/2003
REVISION HISTORY
Standards & Guidelines:
EIS Programming Guidelines - Banner
History of bug fixes or changes made to this file. Include date, name of person making the modification, comment text, and reference to Change Control number or tracking identification (ie, REMEDY) where appropriate.
Commenting Code
Comments should be used at all levels. This is especially helpful for those who may need to reference your modules and for those who will maintain the modules or applications. Comments make the source code more understandable and should be to-the-point while describing the function or change as necessary. Code modification comments must include the date and identification of the developer.
If changing several lines of code requires a corresponding change in other modules, identify all other modules in the version comments.
Even if the module is very thoroughly commented, a brief summary is required in version control (RCS) comments as well. No module should ever be checked into RCS without comments.
Error Handling
Error handling procedures should be discussed with the customer requesting a product. Error conditions should be anticipated and procedures included in the module to handle them. Procedures may range from generation of an error file during a batch update process to interruption of a process and display of error messages during an on-line update.
Conditional Statements
Every possible case should be handled by a conditional statement. All conditional statements (IFs, LOOPs, CASEs, etc.) must provide a path for unexpected data. For example, if social security numbers are defined by the customer to be all numeric in the format 999-99-9999, locally developed code should trap the error if the customer tries to enter 123-45-678X.
Version Control
All developed code must be checked into version control (RCS). This includes any new code as well as any modified vendor code. When a vendor program is to be modified, the original code should be checked into RCS before modifications are incorporated into the code. (Note: at the time of this writing, Oracle Forms 6i is not compatible with RCS. This is the ONLY type of module exempt from this rule.)
Even if the module is very thoroughly commented, a brief summary is required in version control (RCS) comments as well. The Change Control number or tracking identification number (i.e. REMEDY) must be included in the RCS comments.
Page 2 of 8
07/17/2003
Style
Standards & Guidelines:
EIS Programming Guidelines - Banner
Code should be neat, orderly in appearance, and easy to read. Use of tabs, indentation, spacing, and case (upper or lower) should be as consistent as possible. Blank lines and comments should be used where appropriate to separate important sections of code. Formatting standards for the specific language you are using must be followed.
Message or hint text punctuation, grammar, and spelling must be correct.
Performance
All developed code is expected to run in a reasonable amount of time. Any performance problems should be discussed with the customers and resolved before the module is submitted for testing. Developers should use techniques such as TRACE, TKPROF, indexing, array processing, etc., as necessary to resolve performance problems. All developed code must be free of the performance pitfalls discussed in the following language-specific appendices and any other known performance anomalies.
Variation From Standard
Any variance from this programming standard must be documented and approved. The documentation of the variance from the standard must include the reason for the variation. The final approval of all variations from this standard is the responsibility of the applicable Project Director after careful evaluation of the Lead Analyst.
Special Conditions
All conditions in the topics covered above, apply to every Appendix below.
Appendix A - SQL and PL/SQL
This appendix has four sections:
•
•
•
•
PL/SQL Only,
SQL and PL/SQL,
Performance, and
Style.
PL/SQL Only:
•
Every block must have a BEGIN, EXCEPTION, and an END clause.
Page 3 of 8
07/17/2003
•
•
Standards & Guidelines:
EIS Programming Guidelines - Banner
When using a WHEN OTHERS exception, the error message must be displayed or printed using the SQLCODE and SQLERRM built-in functions.
For nested blocks, the outer block exception clause should not reference a null condition. Example: WHEN OTHERS NULL;
SQL and PL/SQL:
SQL is a non-procedural database language which means you can state what you want done without stating how to do it. It is important to structure SQL statements for readability and to express the structure within the statement.
•
•
•
•
•
•
•
•
Each SQL command should begin on a new line.
SQL commands may be in uppercase, lower case or a mixture of case. Uppercase may be used for reserved words and lower case for all other parts of the statement. Whatever style the developer uses, he/she must continue that style from start to finish of the module.
SQL statements should be left-justified except where nested statements are required.
Nested statements should be indented consistently under the original select. If more than one nesting level is used, the indentation of each select should be graduated to the right so that the statements are not directly underneath each other.
Reference to columns should use the full [table.column] or [alias.column] only when required to uniquely identify the column.
Avoid use of wildcard character ('*') in SELECT statements. Always list the applicable columns being selected.
A column list must be used in an INSERT statement. INSERT statements must specifically include the names of the columns being inserted.
Place commas at the right of the applicable line of code. Do not begin lines of code with a comma.
Performance:
•
•
All tables must be checked for index definitions so indices may be utilized when available. Try to avoid use of conditions (NOT, !=, functions on key columns in the WHERE clause, etc.) that will suppress the use of indices.
Avoid use of complex OR conditions whenever a union can be used.
Page 4 of 8
07/17/2003
•
•
•
•
Style:
Standards & Guidelines:
EIS Programming Guidelines - Banner
Columns used in join clauses should be indexed whenever possible. However, do not add new indexes to baseline Banner tables unless all baseline and EIS modules that use the table are tested for possible performance problems caused by the new index.
The driving table (the largest table or the table with poorest performance) should be listed last in the FROM section of the statement.
Join conditions should be listed last in the WHERE section of the statement.
SQL optimization rules could change with new versions of Oracle or SCT Banner, (for Instance, rule-based optimization could be changed to cost-based optimization). Therefore, whatever form of a SQL statement executes most quickly and accurately is deemed to meet these standards
Note: all caps, each command on new line, statement is left-justified, fields are listed, * not used.
Example: SELECT CRITTER, BREED, SEX, HEIGHT, WEIGHT FROM ANIMALHOUSE WHERE BREED = 'MUTT' AND SEX = 'F';
Note: mixed case, all columns listed.
Example: INSERT INTO doghouse (breed, sex, height, weight) SELECT breed, sex, height, weight FROM animalhouse WHERE critter = 'DOG';
Note: lower case, nested select statements are graduated to right, commas to right of field names.
Example: select name, sex, height, weight from animalhouse where breed in (select breed from doghouse where weight > 10 and sex in (select sex from codes where sex = 'F'));
Page 5 of 8
07/17/2003
Appendix B - Pro*C
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Standards & Guidelines:
EIS Programming Guidelines - Banner
Always use one of the standard makefiles (i.e. “sctproc.mk” for normal modules or “sctpass.mk” for modules requiring an embedded user name and password). Refresh the copy you use regularly by copying it from $BANNER_HOME/gtsis/source/proc to avoid using an outdated version. Avoid using non-standard makefiles.
Always use the latest version of header, include and object files that will be linked with the program.
Whenever the standard makefile must be modified, the changes/additions must be very well commented. Every comment must start with the pound sign (#) on the left side of the comment.
Use standard or pre-existing libraries and functions before creating your own.
Variable names must be descriptive and pertinent to the function being performed.
Variable names should be lower case unless specific conditions call for uppercase.
Each variable must be declared on a separate line.
Defined declarations must be in uppercase. Macros are the exception and should be in lowercase.
When defining macros, do not code the final semicolon inside the macro when it is declared. The semicolon should be used when the macro is called within the program.
Avoid use of 'go to' statements. Functions should end with 'return'.
Use SCT Banner I/O functions whenever possible. Otherwise, always use standard 'C' I/O functions from the highest level available. Example, use fprintf instead of fwrite.
For Pro*C, error checking after all SQL statements is mandatory. The SQL error message must contain enough information to identify the correct problem, list the Oracle error number, and the official Oracle error message.
For new Pro*C modules, use of ORACA is recommended for handling error messages.
Use of array processing is suggested for any program that will be handling more than 10,000 rows of data in any given select statement. Use of PL/SQL blocks to combine related SQL statements is also recommended for processing large amounts of data.
Braces {} must be aligned so that pairs match vertically. Braces must be indented appropriately so that the level of nesting is obvious.
Page 6 of 8
07/17/2003
Appendix C – Oracle Forms
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Standards & Guidelines:
EIS Programming Guidelines - Banner
Header information must be in the form comments section. The standard header comment marks are not required for forms. (i.e. /******/ may be omitted from form the top and bottom of header comments).
Each block must have comments describing the function of the block.
Hint text must appear for every navigable displayed field and should follow the standard for the product.
SQL statements within triggers must contain exception processing.
Use stored procedures and functions whenever possible. Always reference procedures and functions instead of copying them into the form unless they must be changed.
All key fields must be accounted for in forms processing. While key fields may be null allowed in the table, the form must insert a value in the key field to maintain parent/child relationships.
Function keys must perform as defined on the show keys screen and use the same key for the same function as Banner uses in their forms.
Field length in the form must correspond with the field length in the table, except for fields defined as LONG.
The version number of GT forms should be updated whenever the form is modified.The form's version number is defined in theLoad_Current_Releaseform-level trigger.
Any modification to a form must have a clearly worded description of the modification saved in the form’s AUDIT TRAIL. Include your name and the Change Control number or tracking identification number (i.e. REMEDY).
The user should experience a look and feel that is seamless between SCT and GT forms. This means all GT forms should make use of SCT-supplied objects such as buttons, Visual Attributes, LOV's and Record Groups.
All references to table owners must be removed from SQL statements (triggers, procedures, etc.).
The standard Banner toolbar should always be used in GT forms. There should be no Save, Rollback, Exit, etc., buttons at the bottom of the form. Standard banner icons should be used for all other buttons in the form (“flashlight” buttons for search features, etc.).
See documents\\biggun.oit.gatech.edu\groups\everyone\Banner Conversion\Banner_4.0.docand \\biggun.oit.gatech.edu\groups\everyone\Banner Conversion\Banner_5.0.docfor complete details on converting a form to version 5.0.
Page 7 of 8
07/17/2003
END of EIS PROGRAMMING GUIDELINES
Page 8 of 8
Standards & Guidelines:
EIS Programming Guidelines - Banner
07/17/2003
