]> source.dussan.org Git - sonarqube.git/commitdiff
Fix typo in docs (#1916)
authorSiegfried Ehret <siegfried.ehret@sonarsource.com>
Thu, 11 Jul 2019 17:27:15 +0000 (19:27 +0200)
committerSonarTech <sonartech@sonarsource.com>
Thu, 11 Jul 2019 18:21:09 +0000 (20:21 +0200)
server/sonar-docs/src/pages/extend/new-langauges.md [deleted file]
server/sonar-docs/src/pages/extend/new-languages.md [new file with mode: 0644]
server/sonar-docs/src/pages/user-guide/security-rules.md

diff --git a/server/sonar-docs/src/pages/extend/new-langauges.md b/server/sonar-docs/src/pages/extend/new-langauges.md
deleted file mode 100644 (file)
index b6a5ee3..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Supporting New Langauges
-url: /extend/new-languages/
----
-
-
-The steps to cover a new programming language are:
-
-1. Write the grammar. This is the hardest part.
-1. Write a parser (a parser simply parses an input based on your grammar to yield a parse tree).
-1. Test your grammar, to ensure it is able to parse real-life language files.
-1. Write a few parse tree visitors. Some visitors will compute metrics such as [executable lines](/extend/executable-lines/), while others will enforce [coding rules](/extend/adding-coding-rules/). A dozen or so visitors is sufficient for an initial release.
-1. Write a scanner Sensor, in a SonarQube plugin, to launch the visitors. 
-1. Compute
-   1. issues
-   1. raw measures
-   1. code duplications
-   1. syntax highlighting
-   1. symbol table
-   1. coverage information (lines/branches to cover, line/branch hits)
-   
-In fulfilling these steps, the [SonarSource Language Recognizer (SSLR)](https://github.com/SonarSource/sslr) can be an important resource.
-   
-
-
diff --git a/server/sonar-docs/src/pages/extend/new-languages.md b/server/sonar-docs/src/pages/extend/new-languages.md
new file mode 100644 (file)
index 0000000..7bfa643
--- /dev/null
@@ -0,0 +1,26 @@
+---
+title: Supporting New Languages
+url: /extend/new-languages/
+---
+
+
+The steps to cover a new programming language are:
+
+1. Write the grammar. This is the hardest part.
+1. Write a parser (a parser simply parses an input based on your grammar to yield a parse tree).
+1. Test your grammar, to ensure it is able to parse real-life language files.
+1. Write a few parse tree visitors. Some visitors will compute metrics such as [executable lines](/extend/executable-lines/), while others will enforce [coding rules](/extend/adding-coding-rules/). A dozen or so visitors is sufficient for an initial release.
+1. Write a scanner Sensor, in a SonarQube plugin, to launch the visitors. 
+1. Compute
+   1. issues
+   1. raw measures
+   1. code duplications
+   1. syntax highlighting
+   1. symbol table
+   1. coverage information (lines/branches to cover, line/branch hits)
+   
+In fulfilling these steps, the [SonarSource Language Recognizer (SSLR)](https://github.com/SonarSource/sslr) can be an important resource.
+   
+
+
index b917bde76c7d65bf24016fb3a4db673e5a16e8f9..cd1a80152c9cadc0ac10ace6295ed8d9b1ed319d 100644 (file)
@@ -29,7 +29,7 @@ Tools which meet certain requirements can be certified as [CWE Compatible](http:
 * Rules must be accurately linked to their related CWE items. To see the CWE mapping for a {instance} rule, consult the rule's See section at the bottom of the rule description.
 * You must be able to identify the relevant CWE from an Issue. To do so in the {instance} platform, consult the related rule.
 * The product documentation must include a description of CWE and CWE Compatibility.
-* The version of CWE supported must be listed. The {instance} langauge plugins support version 2.8.
+* The version of CWE supported must be listed. The {instance} language plugins support version 2.8.
 * In addition to searching rules by CWE id's, you can also search by the "cwe" rule tag.
 
 To see which CWE items are covered for a language, consult the links below.