<commit_before># Contributions are welcome!
You should be familiar with the following few guidelines before you contribute any code. These are not set in stone, if there is a good argument, I am very much open to change. You can submit a pull request with your changes, briefly describe them and I will review as soon as I can!

## Some guidelines, which can be broken if you have a good reason:
- use the default Visual Studio 2017 formatting
- generally, function names start with Uppercase, variable names with lowercase
- Very short, inline function names can start with lowercase
- member and global variables usually use camelCase formatting: int myGlobalVariable;
- temporary variables on stack sometimes use lowercase formatting like this: int tmp_variable_on_stack;
- prefer having braces on their own line when writing loops, branches, functions or whatever
- avoid using c++ stl containers if possible (std::vector is acceptable, or unordered_map, but use them sparingly)
- avoid new and malloc and generally allocating on heap wherever you can. Especially avoid it in frequently called code! Note that by default, c++ std:: lib will allocate on heap.
- you can use auto keyword, but aim for as small scope as possible
- using auto keyword for iterators is encouraged
- aim to write const-correct code
- using references, and pointers is encouraged to indicate if a resource must be initialized or not
- you can write templated code, but aim for simplicity, and it must be commented thoroughly
- aim for minimal header inclusion to keep build times fast. Use forward declarations wherever you can<commit_msg>updated contributing.md<commit_after># Contributions are welcome!
Here are some guidelines how to contribute code. You can submit a pull request with your changes, briefly describe them and I will review as soon as I can!

## Some guidelines to what kind of code to write:
- use the default Visual Studio 2017 formatting
- all engine source and header files are in the project root directory
- all engine header files have .h extension, while compiled source files have .cpp extension
- all third party libraries are in their respective folders within the project directory
- generally, function names start with Uppercase, variable names with lowercase
- Very short, inline function names can start with lowercase
- member and global variables usually use camelCase formatting: int myGlobalVariable;
- temporary variables on stack sometimes use lowercase formatting like this: int tmp_variable_on_stack;
- prefer having braces on their own line when writing loops, branches, functions or whatever
- unit of time should be seconds
- use std::string to store strings
- avoid using c++ stl containers if possible (std::vector is acceptable, or unordered_map, but use them sparingly)
- avoid new and malloc and allocating on general purpose heap wherever you can. Especially avoid it in frequently called code! Note that by default, c++ std:: lib will allocate on heap.
- you can use auto keyword, but aim for as small scope as possible
- using auto keyword for iterators is encouraged
- aim to write const-correct code
- using references, and pointers is encouraged to indicate if a resource must be initialized or not
- you can write templated code, but aim for simplicity, and it must be commented thoroughly
- aim for minimal header inclusion to keep build times fast. Use forward declarations wherever you can
{'fraction_non_alphanumeric': 0.03702623906705539, 'fraction_numerical': 0.0023323615160349854, 'mean_word_length': 4.652388797364086, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, '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': '1595494', 'n_tokens_mistral': 765, 'n_tokens_neox': 741, 'n_words': 523}