<commit_before># libsaxbospiral - Contributing

Thanks for considering contributing to libsaxbospiral!

To get started, [sign the Contributor License Agreement](https://www.clahub.com/agreements/saxbophone/libsaxbospiral).

> [A copy of the CLA](CLA_INDIVIDUAL.md) is also available in this repository.

Here are some tips and general info about contributing to this project. Following these tips will increase the likelihood of getting a speedy PR :smile:

## Checklist

Before you contribute, check the work you're about to do fulfils one of these criteria:

1. Implements a feature represented by an accepted issue in the project's [Github issue tracker](https://github.com/saxbophone/libsaxbospiral/issues)
2. Fixes a bug you discovered (preferably an issue should be created too, but for small or critical bugs, this may not be needed).

Please also check that the work is not already being undertaken by someone else.

## Code Style

I haven't yet formalised the style guide for this project, but this is something I plan to do in the future. Until then, if you could try your best to follow the style of existing code, that will help a great deal.

In addition, please make sure:

- You commit files with Unix Line-endings (`\n` `<LF>` `0x0a`)
- Each text file committed has a trailing newline at the end
- Your C code is compliant to the ISO C99 and C11 standards
- C source code is indented with 4 spaces per indentation level (no tabs)
- Public functions are prototyped in the correct C Header file, all private declarations are declared `static`
- Every public function (and ideally private too) has an accompanying explanatory comment

## Testing

The unit tests for libsaxbospiral currently all reside in one C source file, `tests.c`. This isn't ideal, and I'm planning to clean these up at some point. Build and run the unit tests when you first pull down the code, rebuild and run them again when you've made your changes. Changes adding larger pieces of functionality will likely have additional tests requested for them, or an offer made to write the tests for them.

Pull requests also go through [Travis CI](https://travis-ci.org/) for automated testing.<commit_msg>Last rewording amendments in cla thingy<commit_after># libsxbp - Contributing

Thanks for considering contributing to libsxbp!

To get started, [sign the Contributor License Agreement](https://www.clahub.com/agreements/saxbophone/libsxbp).

> [A copy of the CLA](CLA_INDIVIDUAL.md) is also available in this repository.

Here are some tips and general info about contributing to this project. Following these tips will increase the likelihood of getting a speedy PR :smile:

## Checklist

Before you contribute, check the work you're about to do fulfils one of these criteria:

1. Implements a feature represented by an accepted issue in the project's [Github issue tracker](https://github.com/saxbophone/libsxbp/issues)
2. Fixes a bug you discovered (preferably an issue should be created too, but for small or critical bugs, this may not be needed).

Please also check that the work is not already being undertaken by someone else.

## Code Style

I haven't yet formalised the style guide for this project, but this is something I plan to do in the future. Until then, if you could try your best to follow the style of existing code, that will help a great deal.

In addition, please make sure:

- You commit files with Unix Line-endings (`\n` `<LF>` `0x0a`)
- Each text file committed has a trailing newline at the end
- Your C code is compliant to the ISO C99 and C11 standards
- C source code is indented with 4 spaces per indentation level (no tabs)
- Public functions are prototyped in the correct C Header file, all private declarations are declared `static`
- Every public function (and ideally private too) has an accompanying explanatory comment

## Testing

The unit tests for libsxbp currently all reside in one C source file, `tests.c`. This isn't ideal, and I'm planning to clean these up at some point. Build and run the unit tests when you first pull down the code, rebuild and run them again when you've made your changes. Changes adding larger pieces of functionality will likely have additional tests requested for them, or an offer made to write the tests for them.

Pull requests also go through [Travis CI](https://travis-ci.org/) for automated testing.
{'fraction_non_alphanumeric': 0.05365741802338913, 'fraction_numerical': 0.0041274936941068565, 'mean_word_length': 4.4525, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 7, 'https://': 6, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '754222', 'n_tokens_mistral': 1167, 'n_tokens_neox': 1095, 'n_words': 662}