From 0425aadc78680e53000fd0108b540d6eca048516 Mon Sep 17 00:00:00 2001
From: gmcdonald
Date: Sat, 13 Feb 2010 01:32:03 +0000
Subject: Moving axis svn, part of TLP move INFRA-2441

git-svn-id: http://svn.apache.org/repos/asf/axis/axis2/c/core/trunk@909681 13f79535-47bb-0310-9956-ffa450edef68
---
 xdocs/coding_conventions.html | 130 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 130 insertions(+)
 create mode 100644 xdocs/coding_conventions.html

(limited to 'xdocs/coding_conventions.html')
diff --git a/xdocs/coding_conventions.html b/xdocs/coding_conventions.html
new file mode 100644
index 0000000..0015b1a
--- /dev/null
+++ b/xdocs/coding_conventions.html
@@ -0,0 +1,130 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html><head><title>Apache Axis2/C - Coding Conventions</title>
+ <h2>Axis2/C Coding Conventions</h2><div class="subsection"><a name="Contents"></a><h3>Contents</h3><ul>
+  <li><a href="#1_Naming_conventions_">Naming Conventions</a>
+    <ul>
+      <li><a href="#1_1_Variables">Variables</a></li>
+      <li><a href="#1_2_Functions_">Functions</a></li>
+      <li><a href="#1_3_Structures_and_user_defined_data">Structures and User
+        defined Data Types</a></li>
+      <li><a href="#1_4_Macros">Macros</a></li>
+      <li><a href="#1_5_Enumerations">Enumerations</a></li>
+    </ul>
+  </li>
+  <li><a href="#2_Indentation">Indentation and Formatting</a></li>
+  <li><a href="#3_Comments">Comments</a></li>
+  <li><a href="#4_Function_parameters_and_Return_Value">Function Parameters
+    and Return Value Conventions</a></li>
+  <li><a href="#5_Include_directives">Include Directives</a></li>
+</ul><p><a name="1_Naming_conventions_"></a></p></div><div class="subsection"><a name="1__Naming_Conventions"></a><h3>1. Naming Conventions</h3><ul>
+  <li>Namespace validation is done using the
+    <code><strong>axis2_</strong></code> prefix.</li>
+  <li>Underscore should be used to separate individual words in
+  identifiers.</li>
+  <li>All identifiers should be meaningful and abbreviations must be avoided
+    whenever possible.</li>
+</ul><p><a name="1_1_Variables"></a></p></div><div class="subsection"><a name="1_1_Variables"></a><h3>1.1 Variables</h3><ul>
+  <li>Use meaningful nouns.</li>
+  <li>Make sure to use all lowercase letters for private and public
+  variables.</li>
+  <li>If it is a local variable or a member of a struct, there's no need to
+    prefix it with <code>axis2_</code></li>
+  e.g.</ul>
+    <div class="source"><pre>int count = 0;
+char *prefix = NULL;
+</pre></div>
+  <p><a name="1_2_Functions_"></a></p></div><div class="subsection"><a name="1_2_Functions"></a><h3>1.2 Functions</h3><ul>
+  <li>Function names should always start with the prefix <code>axis2_</code>
+    except for members of a struct.</li>
+  e.g.</ul>
+    <div class="source"><pre>axis2_engine_t * axis2_engine_create(axutil_env_t *environment);
+</pre></div>
+  <p><a name="1_3_Structures_and_user_defined_data"></a></p></div><div class="subsection"><a name="1_3_Structures_and_User_Defined_Data_Types"></a><h3>1.3 Structures and User Defined Data Types</h3><ul>
+  <li>Note the _t suffix in the type name.</li>
+  e.g.</ul>
+    <div class="source"><pre>typedef struct axis2_endpoint_ref {
+    axis2_char_t *address;
+} axis2_endpoint_ref_t;
+</pre></div>
+  <p><a name="1_4_Macros"></a></p></div><div class="subsection"><a name="1_4_Macros"></a><h3>1.4 Macros</h3><ul>
+  <li>Macro names should be in all uppercase letters.</li>
+  e.g.</ul>
+    <div class="source"><pre>#define AXIS2_H
+#define AXIS2_ERROR_GET_MESSAGE(error) ((error)-&gt;ops-&gt;get_message(error))
+
+</pre></div>
+  <p><a name="1_5_Enumerations"></a></p></div><div class="subsection"><a name="1_5_Enumerations"></a><h3>1.5 Enumerations</h3><ul>
+  e.g.</ul>
+    <div class="source"><pre>typedef enum axis2_status_codes {  
+    AXIS2_FAILURE = 0,
+    AXIS2_SUCCESS
+} axis2_status_codes_t;
+</pre></div>
+  <p><a name="2_Indentation"></a></p></div><div class="subsection"><a name="2__Indentation_and_Formatting"></a><h3>2. Indentation and Formatting</h3><ul>
+  Indentation rules are defined in terms of <a href="http://astyle.sourceforge.net/" class="externalLink" title="External Link">Artistic Style</a> indent
+options:</ul><ul>
+  
+  astyle --style=ansi  -b -p -s4  -M0 -c -U -S</ul><ul>
+  In detail, these options mean,
+  <ul>
+    <li>Use the ANSI style code layout
+      <pre>            int foo()
+            {
+                if (is_bar)
+                {
+                    bar();
+                    return 1;
+                }
+                else
+                    return 0;
+            }
+            </pre>
+    </li>
+    <li>Use spaces around operators</li>
+    <li>Use four spaces for indenting</li>
+    <li>No spaces between the function name and parenthesis
+      <pre>            if (is_foo(a, b))
+                bar(a, b);
+            </pre>
+      <pre>        </pre>
+    </li>
+  </ul>
+  There are some more formatting guidelines that could not be enforced by a
+  formatting tool, but nevertheless should be followed.
+  <ul>
+    <li>Checking pointer validity:
+      <pre>    if (foo)</pre>
+      and NOT
+      <pre>    if (foo != NULL)</pre>
+    </li>
+    <li>Checking equality:
+      <pre>    if (foo == 7)</pre>
+      and NOT
+      <pre>    if (7 == foo)</pre>
+    </li>
+  </ul>
+</ul><p><a name="3_Comments"></a></p></div><div class="subsection"><a name="3__Comments"></a><h3>3. Comments</h3><ul>
+  <a href="http://www.stack.nl/%7Edimitri/doxygen/docblocks.html" class="newWindow" title="New Window" target="_blank">Doxygen style comments</a> should be used to help auto
+  generate API documentation. All structs and functions including parameters
+  and return types should be documented.</ul><p><a name="4_Function_parameters_and_Return_Value"></a></p></div><div class="subsection"><a name="4__Function_Parameters_and_Return_Value_Conventions"></a><h3>4. Function Parameters and Return Value Conventions</h3><ul>
+  Each function should be passed a pointer to an instance of the
+  <code>axutil_env_t</code> struct as the first parameter. If the
+  function is tightly bound to a struct, the second parameter is a pointer to
+  an instance of that struct.</ul><ul>
+  Functions returning pointers should return NULL in case of an error. The
+  developer should make sure to set the relevant error code in the
+  environment's error struct.</ul><ul>
+  Functions that do not return pointer values should always return the
+  <code>AXIS2_FAILURE</code> status code on error whenever possible, or
+  return some other defined error value (in case of returning a struct
+  perhaps). A relevant error code must also be set in the environment's error
+  struct.</ul><p><a name="5_Include_directives"></a></p></div><div class="subsection"><a name="5__Include_Directives"></a><h3>5. Include Directives</h3><ul>
+  It is preferable to include header files in the following fashion:</ul><ul>
+</ul>
+    <div class="source"><pre>&lt;standard header files&gt;
+&lt;other system headers&gt;
+"local header files"
+
+
+
+</pre></div>
+  </div></div></div></div><div class="clear"><hr></hr></div></body></html>
-- 
cgit v1.1-32-gdbae

