CONTRIBUTING.md

How to contribute

This document provides guidelines on how to contribute code and what sorts of contributions are acceptable

General guidelines

Here is a list of introductory material to help you get started.

The following two pages below explain general starting guidelines regarding open source:

• How to contribute to open source
• Open Source Contribution Etiquette

First step is to fork a project:

• Forking a repo

Next if needed, you might want to set up your SSH keys:

• Connecting to GitHub with SSH

Regarding license and Copyright practices adopted by this project see:

• Maintaining file-scope copyright notices
• Requirements under U.S. and E.U. Copyright Law
• Copyright Notices

Regarding versioning adopted see:

• Semantic Versioning 2.0.0

For quick markdown references:

• Mastering Markdown
• Markdown Style Guide
• Markdown tables generator

Language specific:

• C++ Core Guidelines
• C and C++ in Visual Studio

Contributing

Contributing is welcome problem however is that there are no well established community guidelines on how assembly source files should be formatted.

For this reason only the following contributions are acceptable:

• Your formatting implementation must be very basic and minimal because personal coding style preferences must not dictate how the formatter will work.

• Implementation for other assemblers which should cover functionalities that is already implemented by this project.

• Implementation for other operating systems.

• Support for more file encodings and auto detection mechanism.

• Bugfixes, optimizations, improvements and tests of existing code base.

If you wish to do something unorthodox or if you believe some new formatting feature might be useful then please open a new issue to discuss it first.

Formatting implementation for other assemblers should be a new function rather than mixed with existing formatting functions due to potential complexity and for easier code maintenance.

As a rule of thumb, if your special formatting functionality goes beyond basic or expected functionality then it should be implemented as an option, that is, a command line option.

Coding style

No style guidelines are pushed upon you, however your coding style, naming convention, formatting, commenting etc. should be as close as possible to exiting code base.

Development environment

By default Visual Studio is used but you feel free to use and contribute your own build configuration

Please do:

1. Compile clean \W4 including static code analysis
2. Get familiar with existing error handling code
3. Review code design, criticize and optimize code