1 files changed, 44 insertions, 0 deletions
diff --git a/dwarfdump/CODINGSTYLE b/dwarfdump/CODINGSTYLE
new file mode 100644
index 0000000..64bbb48
--- /dev/null
+++ b/dwarfdump/CODINGSTYLE
@@ -0,0 +1,44 @@
+This document is a brief description of the main
+coding style conventions in dwarfdump.   Many of them
+will be obvious from the code, but over time some
+accidental diffences crept in.
+
+
+Code should be indented in multiples of 4 spaces, and
+tabs should not be used to indent the source code.
+Use the dicheck program to check indenting.
+
+The struct naming convention is 'struct  my_struct_s' for the
+struct defined here  (meaning the name should end with _s).
+It is better to not do struct typedefs of local structs.
+Coders should type  'struct mystruct_s'.  Readability
+is much more important than brevity.
+
+Any data or function not referenced outside the
+defining source file should be declared 'static'.
+
+Any duplicated code is a candidate for refactoring
+into a subprogram.
+
+Function names should be all lower case with underbars
+with the goal that statements and comments 'read well'.
+
+Variables should be lower-case with
+underbars for readability.   It's ok for a small loop
+with counters to use single letter names like i or k or m.
+
+Structure members should have a struct-specific
+2-character prefix to the name (followed by
+an underbar). That makes it much
+easier to grep for uses of members.
+
+Try to keep lines under 80 characters in length.
+
+Ensure every if() has {} to enclose the actions.
+
+Use libdwarf.h types for all the data objects you define,
+though sometimes an 'unsigned' or 'int' or 'size_t' is
+ok in restricted circumstances.  Dwarf_Unsigned and 
+Dwarf_Signed are the preferred integer types for general use.
+
+------------