Clean up some bits with markdown lint [skip ci]

Signed-off-by: Geoff Hutchison <geoff.hutchison@gmail.com>

CODE_OF_CONDUCT.md

@@ -2,11 +2,17 @@
 
 ## Our Pledge
 
-In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project
+and our community a harassment-free experience for everyone, regardless of
+age, body size, disability, ethnicity, gender identity and expression,
+level of experience, nationality, personal appearance, race, religion,
+or sexual identity and orientation.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment include:
+Examples of behavior that contributes to creating a positive environment
+include:
 
 * Using welcoming and inclusive language
 * Being respectful of differing viewpoints and experiences
@@ -16,31 +22,55 @@ Examples of behavior that contributes to creating a positive environment include
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* The use of sexualized language or imagery and unwelcome sexual attention
+or advances
 * Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing others' private information, such as a physical or electronic address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a professional setting
+* Publishing others' private information, such as a physical or electronic
+address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+professional setting
 
 ## Our Responsibilities
 
-Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+Project maintainers are responsible for clarifying the standards of
+acceptable behavior and are expected to take appropriate and fair
+corrective action in response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit,
+or reject comments, commits, code, wiki edits, issues, and other
+contributions that are not aligned to this Code of Conduct, or to
+ban temporarily or permanently any contributor for other behaviors that
+they deem inappropriate, threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+This Code of Conduct applies both within project spaces and in public
+spaces when an individual is representing the project or its community.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or
+acting as an appointed representative at an online or offline event.
+Representation of a project may be further defined and clarified by
+project maintainers.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at avogadro-devel@lists.sourceforge.net. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+Instances of abusive, harassing, or otherwise unacceptable behavior may
+be reported by contacting the project team at
+avogadro-devel@lists.sourceforge.net. The project team will review and
+investigate all complaints, and will respond in a way that it deems
+appropriate to the circumstances. The project team is obligated to
+maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
 
-Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+Project maintainers who do not follow or enforce the Code of Conduct in
+good faith may face temporary or permanent repercussions as determined by
+other members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
 
 [homepage]: http://contributor-covenant.org
 [version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -1,39 +1,40 @@
-Contributing
-------------
+# Contributing
 
 Avogadro welcomes new development and ideas! We are an open community, made better by all of us.
 
 If you're an Avogadro user who wants to give back, a great
 place to start is supporting your fellow users on the [Avogadro
-Forum](https://discuss.avogadro.cc/). Questions of all levels are posted, 
+Forum](https://discuss.avogadro.cc/). Questions of all levels are posted,
 and you may find that there are some for which your experience is very valuable!
 
 If you find a bug or have a feature suggestion, please take a moment
-to submit a description to the [GitHub Tracker](https://github.com/openchemistry/avogadrolibs/issues/), 
+to submit a description to the
+[GitHub Tracker](https://github.com/openchemistry/avogadrolibs/issues/),
 which helps as an open
 database of issues and suggestions as the code is developed. While there are
 several different GitHub repositories for the project, we will move
 issues around if they better fit a particular component.
 
 For development of Avogadro itself, the [Avogadro
 Forum](https://discuss.avogadro.cc/) has sections for discussing
-ideas, planned directions, work in progress, etc. This includes both the C++ libraries
-and Python scripts and utilities.
+ideas, planned directions, work in progress, etc. This includes both
+the C++ libraries and Python scripts and utilities.
 
 ## Contributing Code
 
 Our project uses the standard GitHub pull request process for code review
 and integration. Please check our [development][Development] guide for more
 details on developing and contributing to the project. The [GitHub issue
-tracker](https://github.com/openchemistry/avogadrolibs/issues) can be used to report bugs, make feature requests, etc.
+tracker](https://github.com/openchemistry/avogadrolibs/issues) can be 
+used to report bugs, make feature requests, etc.
 
 The best way to coordinate development, get support, and offer feedback is
 through the [Avogadro Discussion forum](https://discuss.avogadro.cc/)
 
 If you are new to Git, the Software Carpentry's [Version Control with
 Git](https://swcarpentry.github.io/git-novice/) tutorial is a good place to
-start.  More learning resources are listed at
-https://help.github.com/en/github/getting-started-with-github/git-and-github-learning-resources
+start.  More learning resources are listed in the [GitHub Learning Resources]
+(https://help.github.com/en/github/getting-started-with-github/git-and-github-learning-resources)
 
 1. Make sure you have a free [GitHub](https://github.com/) account. To increase
    the security of your account, we strongly recommend that you configure
@@ -51,25 +52,26 @@ https://help.github.com/en/github/getting-started-with-github/git-and-github-lea
    in the `avogadroapp` repository too.
 
    ```
-   $ git remote add upstream https://github.com/openchemistry/avogadrolibs
-   $ git fetch upstream
-   $ git checkout dev
-   $ git merge upstream/dev
+   git remote add upstream https://github.com/openchemistry/avogadrolibs
+   git fetch upstream
+   git checkout dev
+   git merge upstream/dev
    ```
 
 3. Build OpenChemistry and `avogadrolibs`. You will find full instructions on [building from source code](http://two.avogadro.cc/install/build.html) on the Avogadro2 website.
 
 4. Avogadro contains dozens of tests of different types and complexity and
    running each is difficult and probably not reasonable on your workstation.
-   Most will be run as part of our Continuous Integration as part of a pull request.
+   Most will be run as part of our Continuous Integration as part of a
+   pull request.
 
    If possible, also try to add new tests for the features added or bugs fixed
    by your pull request.
 
    Developers reviewing your pull request will be happy to help you add or run
    the relevant tests as part of the pull request review process.
 
-5. Write a useful and properly formatted commit message. 
+5. Write a useful and properly formatted commit message.
    Follow [these guidelines and template](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines),
    in particular start your message with a short imperative sentence on a single
    line, possibly followed by a blank line and a more detailed explanation.
@@ -96,47 +98,48 @@ https://help.github.com/en/github/getting-started-with-github/git-and-github-lea
 8. The pull request should pass all the continuous integration tests which are
    automatically started by GitHub.
 
-9. Your pull request will be handled by code review and the continuous integration
-    tests.
+9. Your pull request will be handled by code review and the
+   continuous integration tests.
 
 ## Coding Conventions
 
 ### C++ Features
 
--  Don't use exceptions or asserts - Avogadro is production code and should never crash
--  Prefer solutions from the Qt library over Boost/others in Qt
-   dependent code
+* Don't use exceptions or asserts - Avogadro is production code and 
+  should never crash
+* Prefer solutions from the Qt library over Boost/others in Qt
+  dependent code
 
-   -  In Avogadro use the C++11 or C++17 features where necessary, they fall back
-      to Boost on older compilers
-   -  Be careful about using newer language features, since Avogadro runs on many
-      different compilers and platforms. Visual C++ and Clang may not support every
-      feature in GCC.
+  * In Avogadro use the C++11 or C++17 features where necessary, they fall back
+    to Boost on older compilers
+  * Be careful about using newer language features, since Avogadro runs on many
+      different compilers and platforms. Visual C++ and Clang may not 
+      support every feature in GCC.
 
--  Minimize dependencies on third party libraries, think carefully
+* Minimize dependencies on third party libraries, think carefully
    before adding more. If in doubt, please ask.
--  Use templates where they make sense
+* Use templates where they make sense
 
 ### Casting
 
--  Avoid C-style casts, prefer C++ (static_cast, dynamic_cast,
+* Avoid C-style casts, prefer C++ (static_cast, dynamic_cast,
    const_cast, reinterpret_cast)
--  For Qt classes, and Qt derived classes prefer qobject_cast over
+* For Qt classes, and Qt derived classes prefer qobject_cast over
    dynamic_cast
 
 ### Aesthetics
 
--  Prefer enums to define constants over static const int or defines
--  Prefer verbose argument names in headers
+* Prefer enums to define constants over static const int or defines
+* Prefer verbose argument names in headers
 
-   -  Most IDEs show the argument names in their autocompletion
-   -  It looks better in the generated documentation
-   -  Poor style making people guess what an argument is for
+  * Most IDEs show the argument names in their autocompletion
+  * It looks better in the generated documentation
+  * Poor style making people guess what an argument is for
 
--  Avoid abbreviations, as they are often ambiguous and we can afford
+* Avoid abbreviations, as they are often ambiguous and we can afford
    the extra bytes
--  Please use comments and docstrings frequently. You will appreciate it
-   yourself when looking back over code. It may make sense now, but in 
+* Please use comments and docstrings frequently. You will appreciate it
+   yourself when looking back over code. It may make sense now, but in
    a few weeks or months, you may not remember why you wrote that particular
    implementation. (Let alone reading other people's code in a large project.)
 
@@ -149,14 +152,15 @@ For more on [Coding Style](http://two.avogadro.cc/contrib/style.html) see the
 For the most part, Avogadro plugins should be published to your own repository.
 
 Examples:
-- Input Generators: https://github.com/OpenChemistry/avogenerators
-- Example Commands: https://github.com/OpenChemistry/avogadro-commands
-- cclib Import: https://github.com/OpenChemistry/avogadro-cclib
-- Nanocar Builder: https://github.com/kbsezginel/nanocar-avogadro
-- ASE: https://github.com/ghutchis/avogadro-build-ase
-- RDKit: https://github.com/ghutchis/avogadro-rdkit
-- GenIce: https://github.com/ghutchis/avogadro-genice
-- SciKitNano: https://github.com/ghutchis/avogadro-scikit-nano
+
+* Input Generators: <https://github.com/OpenChemistry/avogenerators>
+* Example Commands: <https://github.com/OpenChemistry/avogadro-commands>
+* cclib Import: <https://github.com/OpenChemistry/avogadro-cclib>
+* Nanocar Builder: <https://github.com/kbsezginel/nanocar-avogadro>
+* ASE: <https://github.com/ghutchis/avogadro-build-ase>
+* RDKit: <https://github.com/ghutchis/avogadro-rdkit>
+* GenIce: <https://github.com/ghutchis/avogadro-genice>
+* SciKitNano: <https://github.com/ghutchis/avogadro-scikit-nano>
 
   [Development]: http://two.avogadro.cc/contrib/code.html "Development guide"
   [Wiki]: http://wiki.openchemistry.org/ "Open Chemistry wiki"

STYLE.md

@@ -1,5 +1,4 @@
-clang-format
-------------
+# clang-format
 
 We use [clang-format][clang-format] to keep formatting in the code base
 consistent. Please run clang-format on your patches before submitting.
@@ -22,7 +21,7 @@ git clang-format HEAD~1
 
 ```
 
-### clang-format-diff locations by platform
+## clang-format-diff locations by platform
 
 The exact location of the Python script varies by platform/distro. The table
 below provides the location on some common platform/distro's
@@ -34,8 +33,7 @@ below provides the location on some common platform/distro's
 
 The script can also be downloaded [here][clang-format-diff].
 
-Code style
-----------
+## Code style
 
 This project is developed primarily in C++ and Python. Please follow these code
 style guidelines when contributing code to our project.
@@ -64,37 +62,41 @@ style guidelines when contributing code to our project.
 
 * For comments, add a space between // and the beginning of the comment, e.g.,
 
-    * // A comment
-    * \# Python comment
+  * // A comment
+  * \# Python comment
 
 * Use 2 spaces when indenting C++ code, 4 spaces for Python code.
 
 * Do not indent inside namespaces, e.g.,
 
+```c++
         namespace Avogadro {
         namespace Core {
         void foo();
         }
         }
+```
 
 * Curly braces marking the start and end of a code block should be on
   separate lines and aligned vertically with the statement preceding
   the block, e.g.,
 
+```c++
         if (condition) {
           statement;
         }
 
         for (int i = 0; i < n; ++i) {
           statement;
         }
+```
 
 * Assume that C++11 features are available, and prefer them over legacy macros,
   defines, etc. A few examples follow, but are not exhaustive.
 
-    * Use override to specify member overrides in derived classes.
-    * Set default values of member variables directly in definitions.
-    * Use nullptr instead of NULL.
+  * Use override to specify member overrides in derived classes.
+  * Set default values of member variables directly in definitions.
+  * Use nullptr instead of NULL.
 
 ### C++ Features
 
@@ -111,30 +113,38 @@ style guidelines when contributing code to our project.
 * Prefer declaration of types in public headers over including headers for the
   type
 
+```c++
         namespace Avogadro {
         class MyClass;
         }
+```
 
 * In source files include specialized headers first, then dependency headers,
   then generic headers
 
+```c++
         #include "myapiheader.h" // Our header
         #include <avogadro/core/molecule.h> // Avogadro header from a different module
         #include <QtCore/QString> // Qt header
         #include <vector> // STL
+```
 
 * If you need to include the export header for the module do it as the first include
 
+```c++
         #include "avogadrorenderingexport.h"
+```
 
 * Private headers are denoted by _p.h endings, and should not be included in
   public headers
 * Use the Qt module and camel-cased header
 * Never include Qt module headers such as QtGui, instead include the header for
   the class being used
 
+```c++
         #include <QtGui> // WRONG (module header)!
         #include <QtGui/QDialog> // Correct
+```
 
 ### Namespaces