Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Coding Style

Formatting

Rules

RuleDescription
1Keywords and names are written in lowercase1.
23 space indention2.
3One command per line.
4Keywordsloop,else,elsif,end if,when on a new line.
5Commas in front of separated elements.
6Call parameters aligned, operators aligned, values aligned.
7SQL keywords are right aligned within a SQL command.
8Within a program unit only line comments-- are used.
9Brackets are used when needed or when helpful to clarify a construct.

Example

 1 2 3 4 5 6 7 8 9101112131415161718192021222324252627
procedureset_salary(in_employee_idinemployees.employee_id%type)iscursorc_employees(p_employee_idinemployees.employee_id%type)isselectlast_name,first_name,salaryfromemployeeswhereemployee_id=p_employee_idorderbylast_name,first_name;r_employeec_employees%rowtype;l_new_salaryemployees.salary%type;beginopenc_employees(p_employee_id=>in_employee_id);fetchc_employeesintor_employee;closec_employees;new_salary(in_employee_id=>in_employee_id,out_salary=>l_new_salary);-- Check whether salary has changedifr_employee.salary<>l_new_salarythenupdateemployeessetsalary=l_new_salarywhereemployee_id=in_employee_id;endif;endset_salary;

Code Commenting

Conventions

Inside a program unit only use the line commenting technique-- unless you temporarly deactivate code sections for testing.

To comment the source code for later document generation, comments like/** ... */ are used. Within these documentation comments, tags may be used to define the documentation structure.

Tools like Oracle SQL Developer or PL/SQL Developer include documentation functionality based on a javadoc-like tagging.

Commenting Tags

TagMeaningExample
paramDescription of a parameter.@param in_string input string
returnDescription of the return value of a function.@return result of the calculation
throwsDescribe errors that may be raised by the program unit.@throws NO_DATA_FOUND

Example

This is an example using the documentation capabilities of SQL Developer.

 1 2 3 4 5 6 7 8 910111213
/**Check whether we passed a valid sql name@param   in_name  string to be checked@return  in_name if the string represents a valid sql name@throws  ORA-44003: invalid SQL name<b>Call Example:</b><pre>   select TVDAssert.valid_sql_name('TEST') from dual;   select TVDAssert.valid_sql_name('123') from dual</pre>*/

  1. It used to be good practice to use uppercase keywords and lowercase names to help visualize code structure. But practically all editors support more or less advanced color highlighting of code, similar to the examples in these guidelines. Hence as of version 4.0 we are now recommending all lowercase, as this is easier and faster for the brain to process. You may choose to prefer the old rule - however, it is important to always be consistent, like for example keywords always in uppercase and names always in lowercase. ↩

  2. Tabs are not used because the indentation depends on the editor configuration. We want to ensure that the code looks the same, independent of the editor used. Hence, no tabs. But why not use 8 spaces? That's the traditional value for a tab. When writing a package function the code in the body has an indentation of 3. That's 24 characters as a starting point for the code. We think it's too much. Especially if we try to keep a line below 100 or 80 characters. Other good options would be 2 or 4 spaces. We settled for 3 spaces as a compromise. The indentation is still good visible, but does not use too much space. ↩

[8]ページ先頭
©2009-2025 Movatter.jp