<commit_before># Code conventions

	This is a modified version of kernel coding style.

## Indentation

	* Tabs are 8 characters and make reading easier, therefore we use tabs indentation, which also gives the limit for tending to use too deep nestings in the code.
	* Avoid putting multiple statements into a single line.
	* Avoid putting multiple assignments into single line.
	* Keep it simple (e.g. one issue per one function, no tricky code, no hard coding).
	* No white spaces in the end of lines.


## Breaking long lines and strings

	* 80 characters is the soft limit for the length of line. If over 80 characters and you find a good place for next line break you probably should do a line break. Do not compromise readability or do not shorten words.
	* Descendants are shorter than parent lines, indentation 2 tabs(16 spaces).
	* Previous applies also to function headers with long argument lists.
	* Prefer descriptive words.
	* Don’t brake printable, user visible strings shorter, since it brakes the availability to grep.


## Placing Braces and Spaces

    ### Braces

	#### Non-function statement blocks

	* Opening brace last in the line.
	* Closing brace in the beginning of the line.

	### Functions

	* Opening and closing braces in the beginning of the line.

	* Closing brace is empty of its own except when there is a continuation of the same statement.
	* Use braces always.

    ### Spaces

	* Use space after keyword except if they look more like a function (like typeof, sizeof etc.).
	* Surround ‘: ‘ with spaces e.g. in case of class inheritance.
	* Put pointer adjacent to function name or data name, not adjacent to type name.
	* No trailing whitespaces in the end of lines.
	* Surround most binary and ternary operators with one space on both sides.
	* Use unary operators without a space.
	* Use unary prefix- and postfix operators without a space.
	* No space with unary structure operators, like ‘.’ and ‘->’.


## Naming

	* Use descriptive names for global variables and functions.
	* Local variable names should be short and to the point.
	* In classes: write member variables with a leading ‘m’.
	* Write static variables with a leading ‘s’.


## Typedefs

	* Don’t use typedef for pointers and structs that has elements, that can be accessed directly.


## Functions

	* Functions should be short and contain only one task.
	* Functions should be maximum one or two screenfuls long.
	* Use maximum 5 -10 local variables per function.
	* Separate functions with a blank line.


## Centralized exiting of functions

	* Albeit deprecated, unconditional **goto** is acceptable in cases when:  
	  * Unconditional statements are easier to understand and follow.
	  * Reduced nesting.
	  * Errors by updating exit points are prevented.
	  * Optimizing redundant code.


## Commenting

	* See Doxygen README file for instructions how to document the code properly. IF NECESSARY USE THE FOLLOWING RULES FOR COMMENTING:
	  * Do not over-comment, use concise comments.
	  * Try not to use normal way of commenting, prefer doxygen documents. Leave licence comments as normal comments etc.
	  * Write WHAT your code does or WHY it is there, not HOW it does it.
	  * Use Linux style comments: /*...*/.
	  * It’s important to comment data whether it is basic type or derived type.


## Macros, Enums

	* Names of macros defining constants should be capitalized.
	* Labels in enums should be capitalized.
	* Capitalized macro names are preferred but names of macros resembling functions can be written in lowercase letters.


## The inline disease

	* Use inline functions if it is necessary for performance reasons.
	* Do not use otherwise.


## Function return values and names

	* If the name of the function is an action or an imperative command, the function should return an error code integer (-Exxx = failure, 0 = success).
	* If the name of the function is a predicative, the function should return a ‘succeeded’ boolean (0 = failure, non-zero = success).



<commit_msg>Modified file CODING_STYLE.md<commit_after># Code conventions

This is a modified version of kernel coding style.

## Indentation

* Tabs are 8 characters and make reading easier, therefore we use tabs indentation, which also gives the limit for tending to use too deep nestings in the code.
* Avoid putting multiple statements into a single line.
* Avoid putting multiple assignments into single line.
* Keep it simple (e.g. one issue per one function, no tricky code, no hard coding).
* No white spaces in the end of lines.


## Breaking long lines and strings

* 80 characters is the soft limit for the length of line. If over 80 characters and you find a good place for next line break you probably should do a line break. Do not compromise readability or do not shorten words.
* Descendants are shorter than parent lines, indentation 2 tabs(16 spaces).
* Previous applies also to function headers with long argument lists.
* Prefer descriptive words.
* Don’t brake printable, user visible strings shorter, since it brakes the availability to grep.


## Placing Braces and Spaces

### Braces

#### Non-function statement blocks

* Opening brace last in the line.
* Closing brace in the beginning of the line.

### Functions

* Opening and closing braces in the beginning of the line.

* Closing brace is empty of its own except when there is a continuation of the same statement.
* Use braces always.

### Spaces

* Use space after keyword except if they look more like a function (like typeof, sizeof etc.).
* Surround ‘: ‘ with spaces e.g. in case of class inheritance.
* Put pointer adjacent to function name or data name, not adjacent to type name.
* No trailing whitespaces in the end of lines.
* Surround most binary and ternary operators with one space on both sides.
* Use unary operators without a space.
* Use unary prefix- and postfix operators without a space.
* No space with unary structure operators, like ‘.’ and ‘->’.


## Naming

* Use descriptive names for global variables and functions.
* Local variable names should be short and to the point.
* In classes: write member variables with a leading ‘m’.
* Write static variables with a leading ‘s’.


## Typedefs

* Don’t use typedef for pointers and structs that has elements, that can be accessed directly.


## Functions

* Functions should be short and contain only one task.
* Functions should be maximum one or two screenfuls long.
* Use maximum 5 -10 local variables per function.
* Separate functions with a blank line.


## Centralized exiting of functions

* Albeit deprecated, unconditional **goto** is acceptable in cases when:  
  * Unconditional statements are easier to understand and follow.
  * Reduced nesting.
  * Errors by updating exit points are prevented.
  * Optimizing redundant code.


## Commenting

* See Doxygen README file for instructions how to document the code properly. IF NECESSARY USE THE FOLLOWING RULES FOR COMMENTING:
  * Do not over-comment, use concise comments.
  * Try not to use normal way of commenting, prefer doxygen documents. Leave licence comments as normal comments etc.
  * Write WHAT your code does or WHY it is there, not HOW it does it.
  * Use Linux style comments: /*...*/.
  * It’s important to comment data whether it is basic type or derived type.


## Macros, Enums

* Names of macros defining constants should be capitalized.
* Labels in enums should be capitalized.
* Capitalized macro names are preferred but names of macros resembling functions can be written in lowercase letters.


## The inline disease

* Use inline functions if it is necessary for performance reasons.
* Do not use otherwise.


## Function return values and names

* If the name of the function is an action or an imperative command, the function should return an error code integer (-Exxx = failure, 0 = success).
* If the name of the function is a predicative, the function should return a ‘succeeded’ boolean (0 = failure, non-zero = success).




{'fraction_non_alphanumeric': 0.055618330194601384, 'fraction_numerical': 0.0032642812303829254, 'mean_word_length': 3.7843843843843845, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, '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': '2598128', 'n_tokens_mistral': 2132, 'n_tokens_neox': 1960, 'n_words': 1186}