Merge pull request #8 from ThundeRatz/develop

Develop

.all-contributorsrc

@@ -0,0 +1,70 @@
+{
+  "projectName": "STM32RF24",
+  "projectOwner": "ThundeRatz",
+  "repoType": "github",
+  "repoHost": "https://github.com",
+  "files": [
+    "README.md",
+    "README.pt-br.md"
+  ],
+  "imageSize": 100,
+  "commit": true,
+  "commitConvention": "gitmoji",
+  "contributors": [
+    {
+      "login": "LucasHaug",
+      "name": "Lucas Haug",
+      "avatar_url": "https://avatars3.githubusercontent.com/u/39196309?v=4",
+      "profile": "https://github.com/LucasHaug",
+      "contributions": [
+        "code",
+        "doc",
+        "test",
+        "translation"
+      ]
+    },
+    {
+      "login": "lucastrschneider",
+      "name": "Lucas Schneider",
+      "avatar_url": "https://avatars0.githubusercontent.com/u/50970346?v=4",
+      "profile": "https://github.com/lucastrschneider",
+      "contributions": [
+        "code",
+        "doc",
+        "test",
+        "translation",
+        "review"
+      ]
+    },
+    {
+      "login": "d-nery",
+      "name": "Daniel Nery",
+      "avatar_url": "https://avatars2.githubusercontent.com/u/12468184?v=4",
+      "profile": "https://github.com/d-nery",
+      "contributions": [
+        "code",
+        "review"
+      ]
+    },
+    {
+      "login": "FelipeGdM",
+      "name": "Felipe Gomes de Melo",
+      "avatar_url": "https://avatars3.githubusercontent.com/u/1054087?v=4",
+      "profile": "https://github.com/FelipeGdM",
+      "contributions": [
+        "ideas",
+        "review"
+      ]
+    },
+    {
+      "login": "Berbardo",
+      "name": "Bernardo Coutinho",
+      "avatar_url": "https://avatars0.githubusercontent.com/u/48636340?v=4",
+      "profile": "https://github.com/Berbardo",
+      "contributions": [
+        "test"
+      ]
+    }
+  ],
+  "contributorsPerLine": 7
+}

.gitignore

@@ -0,0 +1 @@
+docs/Doxygen/

CODE_OF_CONDUCT.md

@@ -0,0 +1,78 @@
+# Contributor Covenant Code of Conduct
+
+Para a versão em PT-BR 🇧🇷 desse documento, [veja aqui](CODE_OF_CONDUCT.pt-br.md).
+
+## 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, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* 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
+
+## 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 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.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at comp@thunderatz.org. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and 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.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CODE_OF_CONDUCT.pt-br.md

@@ -0,0 +1,76 @@
+# Código de Conduta para Colaboradores
+
+## Nossa Promessa
+
+Com o interesse de fomentar uma comunidade aberta e acolhedora, nós, como
+colaboradores e administradores deste projeto, comprometemo-nos a fazer a
+participação neste projeto e nesta comunidade uma experiência livre de assédio
+para todes, independente da idade, porte físico, deficiência, etnia, características
+sexuais, identidade ou expressão de gênero, nível de experiência, educação, status
+socio=econômico, nacionalidade, aparência pessoal, raça, religião, ou identidade
+e orientação sexual.
+
+## Nossos Padrões
+
+Exemplos de comportamentos que contribuem a criar um ambiente positivo incluem:
+
+* Usar linguagem acolhedora e inclusiva
+* Respeitar pontos de vista e experiências diferentes
+* Aceitar crítica construtiva graciosamente
+* Focar no que é melhor para a comunidade
+* Mostrar empatia com outros membros da comunidade
+
+Exemplos de comportamentos inaceitáveis por parte dos participantes incluem:
+
+* Uso de linguagem ou imagens sexuais e atenção ou avanço sexual indesejada
+* Comentários insultuosos e/ou depreciativos e ataques pessoais ou
+  políticos (Trolling)
+* Assédio público ou privado
+* Publicar informação pessoal de outros sem permissão explícita, como, por exemplo,
+  um endereço eletrônico ou residencial
+* Qualquer outra forma de conduta que pode ser razoavelmente considerada
+  inapropriada num ambiente profissional
+
+## Nossas Responsibilidades
+
+Os administradores do projeto são responsáveis por esclarecer os padrões de
+comportamento e deverão tomar ação corretiva apropriada e justa em resposta a
+qualquer instância de comportamento inaceitável.
+
+Os administradores do projeto têm o direito e a responsabilidade de remover, editar ou
+rejeitar comentários, commits, código, edições na wiki, issues ou outras formas de
+contribuição que não estejam de acordo com este Código de Conduta, bem como banir
+temporariamente ou permanentemente qualquer colaborador por qualquer outro
+comportamento que se considere impróprio, perigoso, ofensivo ou problemático.
+
+## Escopo
+
+Este Código de Conduta aplica-se dentro dos espaços do projeto ou qualquer espaço
+público onde alguém represente o mesmo ou a sua comunidade. Exemplos de
+representação do projeto ou comunidade incluem usar um endereço de email oficial do
+projeto, postar por uma conta de mídia social oficial, ou agir como um representante
+designado num evento online ou offline. A representação de um projeto pode ser ainda
+definida e esclarecida pelos administradores do projeto.
+
+## Aplicação
+
+Comportamento abusivo, de assédio ou de outros tipos podem ser comunicados
+contatando a equipe do projeto em comp@thunderatz.org. Todas as queixas serão
+revistas investigadas e resultarão numa resposta necessária e apropriada à
+situação. A equipe é obrigada a manter a confidencialidade em relação a quem
+reportou o incidente. Demais detalhes de políticas de aplicação podem ser
+postadas separadamente.
+
+Administradores do projeto que não sigam ou não mantenham o Código de Conduta em
+boa fé podem enfrentar repercussões temporárias ou permanentes determinadas por
+outros membros da liderança do projeto.
+
+## Atribuição
+
+Este Código de Conduta é adaptado do [Contributor Covenant][homepage], versão 1.4,
+disponível em https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+Para obter respostas a perguntas comuns sobre este código de conduta, veja
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,124 @@
+# Contributing to STM32RF24 🚀
+
+Para a versão em PT-BR 🇧🇷 desse documento, [veja aqui](CONTRIBUTING.pt-br.md).
+
+First of all, thanks for your interest! We really appreciate the participation of the community! ✨
+
+Here we describe a set of guidelines when contributing to STM32RF24. These are not strict rules, so use your best judgment, and in case you have questions, contact us on comp@thunderatz.org.
+
+Please note that this project is released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
+
+## How can I contribute?
+
+### Issues
+
+Most contributions are made with [GitHub Issues](https://guides.github.com/features/issues/). They will be primarily used for
+
+1. Tracking bugs - `bug`
+2. Suggesting Enhancements - `enhancement`
+3. Improving documentation - `documentation`
+
+For each of these, there is a specific [label](https://docs.github.com/en/enterprise/2.17/user/github/managing-your-work-on-github/applying-labels-to-issues-and-pull-requests). We strongly recommend that every issue created has at least one of the three labels described above.
+
+But before creating an issue, first check if there is already one with the same subject. You can search and filter by labels, for example, [here](https://github.com/ThundeRatz/STM32RF24/labels/bug) we only see the issues that are active and have the `bug` label.
+
+#### Reporting Bugs 🐛
+
+- Use a clear title
+- Specify the version of the library
+- Specify OS, VM (if applicable), project's microcontroller, and other configurations that may be useful
+- Describe the steps to reproduce the bug
+- Describe the observed and the expected behavior
+- Include screenshots, gifs, any type of reference that helps to explain the problem
+
+#### Suggesting Enhancements ✨
+
+- Use a clear title
+- Describe the suggestion step-by-step
+- Describe the expected behavior after implementing this idea
+- Explain why this new feature or update can be usefull
+
+#### Improving documentation 📝
+
+- Use a clear title
+- Specify the files that need to be documented
+- Explain your suggestion and why would it be better/clearer
+
+### Pull Requests
+
+If you want to contribute with code to the project, search for an open issue and start developing. When you are ready, open a Pull Request and we will review it.
+
+A few recommendations:
+
+- Describe exactly what you've done, always as clear as possible
+- Link the applicable issue in your Pull Request (if there is none, please, create a new one)
+- Make sure that you are following the [Syleguide 💄](#styleguide-)
+
+## Styleguide 💄
+
+### Code formatting
+
+The code is formatted following specific rules, for more information on how to ensure that your code is formatted correctly, see the [🎨 Formatting](./README.md#-formatting) section on the README.
+
+### Coding in C
+
+There are some guidelines for organizing C code that should be followed.
+
+> "Programs must be written for people to read,
+> and only incidentally for machines to execute."
+
+― Harold Abelson, Structure and Interpretation of Computer Programs
+
+#### Variables and functions scopes
+
+Always reduce the scopes of the variables to the minimum possible, avoiding global, external and static, giving preference to local variables. The same is true for functions, do not create public functions if they are only to be used within a file, leave them private.
+
+#### Nomenclature
+
+> "You should name a variable using the same care
+> with which you name a first-born child."
+
+― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
+
+First, to maintain the standard, leave all the names of variables, functions, constants, files, among others, in English.
+
+Choose meaningful names, the names should show what the variable, for example, is used in the code, so never use variables with only one letter, besides saying nothing about what it is, it is also difficult to find the variable in the code.
+
+For variables or constants, for example, that have a unit of measure, include this unit of measure in the name, this makes it easier to understand its meaning.
+
+In order to indicate that a variable is a pointer, add `p_` to the beginning of the variable name, if it is a pointer to a pointer, for example, add `pp_`.
+
+Global variables in a file and external variables should be avoided, especially external ones, but if they are really necessary, they should be identified to facilitate the understanding of isolated parts of the code. Add `m_` to the beginning of a variable name to indicate that it is a global variable in a file. And to indicate that a variable is a global external, add `g_` at the beginning of its name. If you had an external pointer, for example, you would use `gp_`.
+
+For more naming tips, see the article ["How To Create Meaningful Names In Code"](https://medium.com/better-programming/how-to-create-meaningful-names-in-code-20d7476537d4).
+
+#### Variable types
+
+Make coherent choices for your variable types and your functions return and parameters types. For examples, do not use `float` if your variable is a unit counter.
+
+Besides that, for integer variables, distinguish between `signed` and `unsigned` and specify their size in bits, this ensures more control over the values that each variable can have, as well as optimizes the memory occupation. To do this, use the `stdint.h` library, than, for example, you can use the types `uint8_t` for unsigned 8-bit integers and `int16_t` for signed 16-bit integers.
+
+#### Magic numbers/Constants
+
+Avoid [magic numbers](https://en.wikipedia.org/wiki/Magic_number_(programming)) in your code. In addition to decreasing readability, they also make maintenance difficult. To solve this, use constants defined with `#define` at the beginning of your code.
+
+### Git commit messages
+
+- Use the present tense ("Add feature" not "Added feature")
+- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
+- It is strongly recommended to start a commit message with a related emoji
+  - 📝 `:memo:` for documentation
+  - 🐛 `:bug:` for bug issues
+  - 🚑 `:ambulance:` for critical fixes
+  - 🎨 `:art:` for improving structure
+  - ✨ `:sparkles:` for new features
+
+  For more examples, see [this reference](https://gitmoji.carloscuesta.me/).
+
+### Git workflow
+
+The project workflow is based on [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/).
+
+### Documentation
+
+The documentation is generated with [Doxygen](https://www.doxygen.nl/index.html) and should follow its documenting manual. A well-documented code is crucial for understanding it.