Skip to content

Latest commit

 

History

History
59 lines (40 loc) · 2.72 KB

CONTRIBUTING.md

File metadata and controls

59 lines (40 loc) · 2.72 KB
Raw

✏️ Bluechirp Contributing Guidelines

This document will aid you in the case that you want to open a pull request for this project.
Your help is appreciated! 😊

🤔 Starting

Please open a draft pull request or tell others that you will work on an issue before you spend too much time into it.

Sometimes, someone else may also try to fix the issue you're trying to fix, which will cause both of you to end up wasting time.
Communication is key!

Also remember to read the code of conduct!

📨 Commit Messages

Follow this format! It makes commit messages much nicer.

[PROJECT -> MODULE] COMMIT_MESSAGE

Here's a list of what you should replace PROJECT with:

  • 📱 Bluechirp.csproj - App
  • 🔗 Bluechirp.Library.csproj - Library
  • ✅ Bluechirp.Tests.csproj - Tests
  • 🔍 MastoParserLib.csproj - Parser
  • 🗂️ Repository - GitHub

MODULE should be the folder the modified files are in, like "Core" or "Model".
For GitHub though, here is the list:

  • 🤖 Bots - Bots
  • ▶️ Actions - Actions
  • ❓ Other - General

If you are committing for the Tests/Parser project, you do not need to include the MODULE part.

📊 Indentation Style

The indentation style must be Allman.

This is because it looks cleaner, since the spacing is much more noticeable and because most C# projects use it anyways.

🌬️ Spacing

You must leave 1 new line between each function/class/struct/statement.

You may group a statement (i.e. an if statement) group if it makes sense to do so. For example, if you are checking several cases against one variable, or it contextually makes sense to place them together.

Please don't leave extra random empty lines at the end or start of functions and such!

🏷️ Naming

Use PascalCase for class names, variables and parameters, but use camelCase for local variables. Use SCREAMING_SNAKE_CASE for const variables.

Anything private must use the _camelCase or _SCREAMING_SNAKE_CASE convention.
This is because the MVVM source generator expects _camelCase to add observable properties.

📣 Comments

Please use XML documentation to document all classes and functions.

Don't comment over-comment! It can have the opposite effect and make code annoying to read.

🗃️ Types

Please use the keyword version of types when possible, this means using string instead of String (looking at you, pesky Java users), int instead of Int32, uint instead of UInt32 and so on.

Do the exact opposite when working with binary files, where knowing the datatype in detail is crucial.