Fix #122 - Consistent use of initcap case for the word Oracle

kibeha · kibeha · commit ac47b7125375 · 2022-07-15T06:20:33.000Z
diff --git a/docs/1-introduction/introduction.md b/docs/1-introduction/introduction.md
@@ -4,7 +4,7 @@ This document describes rules and recommendations for developing applications us
 
 ## Scope
 
-This document applies to the PL/SQL and SQL language as used within ORACLE databases and tools, which access ORACLE databases.
+This document applies to the PL/SQL and SQL language as used within Oracle databases and tools, which access Oracle databases.
 
 ## Document Conventions
 
diff --git a/docs/2-naming-conventions/naming-conventions.md b/docs/2-naming-conventions/naming-conventions.md
@@ -8,14 +8,14 @@
 4. Avoid long abbreviations. Abbreviations should be shorter than 5 characters.
 5. Any abbreviations must be widely known and accepted. 
 6. Create a glossary with all accepted abbreviations.
-7. Never use ORACLE keywords as names. A list of ORACLEs keywords may be found in the dictionary view `v$reserved_words`.
+7. Never use Oracle keywords as names. A list of Oracles keywords may be found in the dictionary view `v$reserved_words`.
 8. Avoid adding redundant or meaningless prefixes and suffixes to identifiers.<br/>Example: `create table emp_table`.
 9. Always use one spoken language (e.g. English, German, French) for all objects in your application.
 10. Always use the same names for elements with the same meaning.
 
 ## Naming Conventions for PL/SQL
 
-In general, ORACLE is not case sensitive with names. A variable named personname is equal to one named PersonName, as well as to one named PERSONNAME. Some products (e.g. TMDA by Trivadis, APEX, OWB) put each name within double quotes (&quot;) so ORACLE will treat these names to be case sensitive. Using case sensitive variable names force developers to use double quotes for each reference to the variable. Our recommendation is to write all names in lowercase and to avoid double quoted identifiers.
+In general, Oracle is not case sensitive with names. A variable named personname is equal to one named PersonName, as well as to one named PERSONNAME. Some products (e.g. TMDA by Trivadis, APEX, OWB) put each name within double quotes (&quot;) so Oracle will treat these names to be case sensitive. Using case sensitive variable names force developers to use double quotes for each reference to the variable. Our recommendation is to write all names in lowercase and to avoid double quoted identifiers.
 
 A widely used convention is to follow a `{prefix}variablecontent{suffix}` pattern.
 
diff --git a/docs/3-coding-style/coding-style.md b/docs/3-coding-style/coding-style.md
@@ -56,7 +56,7 @@ Inside a program unit only use the line commenting technique `--` unless you tem
 
 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. 
+Tools like Oracle SQL Developer or PL/SQL Developer include documentation functionality based on a javadoc-like tagging. 
 
 ### Commenting Tags
 
diff --git a/docs/4-language-usage/2-variables-and-types/1-general/g-2130.md b/docs/4-language-usage/2-variables-and-types/1-general/g-2130.md
@@ -13,7 +13,7 @@ Your code will be easier to read as the usage of a variable/constant may be deri
 
 Type               | Usage
 ------------------ | -----
-`ora_name_type`    | Object corresponding to the ORACLE naming conventions (table, variable, column, package, etc.).
+`ora_name_type`    | Object corresponding to the Oracle naming conventions (table, variable, column, package, etc.).
 `max_vc2_type`     | String variable with maximal VARCHAR2 size.
 `array_index_type` | Best fitting data type for array navigation.
 `id_type`          | Data type used for all primary key (id) columns.
diff --git a/docs/4-language-usage/2-variables-and-types/2-numeric-data-types/g-2230.md b/docs/4-language-usage/2-variables-and-types/2-numeric-data-types/g-2230.md
@@ -5,13 +5,13 @@
 
 ## Restriction
 
-ORACLE 11g or later
+Oracle 11g or later
 
 ## Reason
 
 `simple_integer` does no checks on numeric overflow, which results in better performance compared to the other numeric datatypes.
 
-With ORACLE 11g, the new data type `simple_integer` has been introduced. It is a sub-type of `pls_integer` and covers the same range. The basic difference is that `simple_integer` is always `not null`.  When the value of the declared variable is never going to be null then you can declare it as `simple_integer`. Another major difference is that you will never face a numeric overflow using `simple_integer` as this data type wraps around without giving any error. `simple_integer` data type gives major performance boost over `pls_integer` when code is compiled in `native` mode, because arithmetic operations on `simple_integer` type are performed directly at the hardware level.
+With Oracle 11g, the new data type `simple_integer` has been introduced. It is a sub-type of `pls_integer` and covers the same range. The basic difference is that `simple_integer` is always `not null`.  When the value of the declared variable is never going to be null then you can declare it as `simple_integer`. Another major difference is that you will never face a numeric overflow using `simple_integer` as this data type wraps around without giving any error. `simple_integer` data type gives major performance boost over `pls_integer` when code is compiled in `native` mode, because arithmetic operations on `simple_integer` type are performed directly at the hardware level.
 
 
 ## Example (bad)
diff --git a/docs/4-language-usage/2-variables-and-types/3-character-data-types/g-2330.md b/docs/4-language-usage/2-variables-and-types/3-character-data-types/g-2330.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-Today zero-length strings and `null` are currently handled identical by ORACLE. There is no guarantee that this will still be the case in future releases, therefore if you mean `null` use `null`.
+Today zero-length strings and `null` are currently handled identical by Oracle. There is no guarantee that this will still be the case in future releases, therefore if you mean `null` use `null`.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/2-variables-and-types/5-large-objects/g-2510.md b/docs/4-language-usage/2-variables-and-types/5-large-objects/g-2510.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-`long` and `long raw` data types have been deprecated by ORACLE since version 8i - support might be discontinued in future ORACLE releases.
+`long` and `long raw` data types have been deprecated by Oracle since version 8i - support might be discontinued in future Oracle releases.
 
 There are many constraints to `long` datatypes in comparison to the `lob` types.
 
diff --git a/docs/4-language-usage/3-dml-and-sql/1-general/g-3150.md b/docs/4-language-usage/3-dml-and-sql/1-general/g-3150.md
@@ -5,7 +5,7 @@
 
 ## Restriction
 
-ORACLE 12c
+Oracle 12c
 
 ## Reason
 
diff --git a/docs/4-language-usage/3-dml-and-sql/1-general/g-3160.md b/docs/4-language-usage/3-dml-and-sql/1-general/g-3160.md
@@ -4,11 +4,11 @@
     Maintainability, Reliability
 
 !!! missing "Unsupported in PL/SQL Cop Validators"
-    We cannot identify the type of a column. Requires `create table` and `alter table` parser support or access to the Oracle Data Dicionary.
+    We cannot identify the type of a column. Requires `create table` and `alter table` parser support or access to the Oracle Data Dictionary.
 
 ## Restriction
 
-ORACLE 12c
+Oracle 12c
 
 ## Reason
 
diff --git a/docs/4-language-usage/3-dml-and-sql/1-general/g-3170.md b/docs/4-language-usage/3-dml-and-sql/1-general/g-3170.md
@@ -4,15 +4,15 @@
     Reliability
 
 !!! missing "Unsupported in PL/SQL Cop Validators"
-    We cannot identify column default values. Requires `create table` and `alter table` parser support or access to the Oracle Data Dicionary.
+    We cannot identify column default values. Requires `create table` and `alter table` parser support or access to the Oracle Data Dictionary.
 
 ## Restriction
 
-ORACLE 12c
+Oracle 12c
 
 ## Reason
 
-Default values have been nullifiable until ORACLE 12c. Meaning any tool sending null as a value for a column having a default value bypassed the default value. Starting with ORACLE 12c default definitions may have an `on null` definition in addition, which will assign the default value in case of a `null` value too.
+Default values have been nullifiable until Oracle 12c. Meaning any tool sending null as a value for a column having a default value bypassed the default value. Starting with Oracle 12c default definitions may have an `on null` definition in addition, which will assign the default value in case of a `null` value too.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4220.md b/docs/4-language-usage/4-control-structures/2-case-if-decode-nvl-nvl2-coalesce/g-4220.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-`decode` is an ORACLE specific function hard to understand and restricted to SQL only. The “newer” `case` function is much more common, has a better readability and may be used within PL/SQL too. Be careful that `decode` can handle `null` values, which the simple `case` cannot - for such cases you must use the searched `case` and `is null` instead.
+`decode` is an Oracle specific function hard to understand and restricted to SQL only. The “newer” `case` function is much more common, has a better readability and may be used within PL/SQL too. Be careful that `decode` can handle `null` values, which the simple `case` cannot - for such cases you must use the searched `case` and `is null` instead.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/5-exception-handling/g-5010.md b/docs/4-language-usage/5-exception-handling/g-5010.md
@@ -15,7 +15,7 @@ This kind of framework should include
 * Logging (different channels like table, mail, file, etc. if needed)
 * Error Raising
 * Multilanguage support if needed
-* Translate ORACLE error messages to a user friendly error text
+* Translate Oracle error messages to a user friendly error text
 * Error repository
 
 ## Example (bad)
diff --git a/docs/4-language-usage/7-stored-objects/5-oracle-supplied-packages/g-7510.md b/docs/4-language-usage/7-stored-objects/5-oracle-supplied-packages/g-7510.md
@@ -1,11 +1,11 @@
-# G-7510: Always prefix ORACLE supplied packages with owner schema name.
+# G-7510: Always prefix Oracle supplied packages with owner schema name.
 
 !!! warning "Major"
     Security
 
 ## Reason
 
-The signature of oracle-supplied packages is well known and therefore it is quite easy to provide packages with the same name as those from oracle doing something completely different without you noticing it.
+The signature of Oracle-supplied packages is well known and therefore it is quite easy to provide packages with the same name as those from Oracle doing something completely different without you noticing it.
 
 ## Example (bad)
 
diff --git a/docs/4-language-usage/7-stored-objects/8-sequences/g-7810.md b/docs/4-language-usage/7-stored-objects/8-sequences/g-7810.md
@@ -5,7 +5,7 @@
 
 ## Reason
 
-Since ORACLE 11g it is no longer needed to use a `select` statement to read a sequence (which would imply a context switch).
+Since Oracle 11g it is no longer needed to use a `select` statement to read a sequence (which would imply a context switch).
 
 ## Example (bad)
 
diff --git a/docs/7-tool-support/tool-support.md b/docs/7-tool-support/tool-support.md
@@ -2,7 +2,7 @@
 
 ## Development
 
-Trivadis offers a cost-free extension to ORACLE SQL Developer to test compliance with this coding guideline. The extension may be parameterized to your preferred set of rules and allows checking this set against a program unit.
+Trivadis offers a cost-free extension to Oracle SQL Developer to test compliance with this coding guideline. The extension may be parameterized to your preferred set of rules and allows checking this set against a program unit.
 
 ### Setting the preferences
 
