Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding CONTRIBUTING.md, CONTRIBUTING_GUIDELINES.md, and LICENSE files #10

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
122 changes: 122 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,122 @@
# Contributing Guidelines

Thank you for considering contributing to our project! We appreciate your interest and support. Please take a moment to read these guidelines to ensure a smooth and productive collaboration.

## Table of Contents

1. [Code of Conduct](#code-of-conduct)
2. [How to Contribute](#how-to-contribute)
- [Reporting Issues](#reporting-issues)
- [Submitting Pull Requests](#submitting-pull-requests)
3. [Development Setup](#development-setup)
4. [Coding Guidelines](#coding-guidelines)
5. [Commit Guidelines](#commit-guidelines)
6. [Testing](#testing)
7. [Documentation](#documentation)
8. [License](#license)

## Code of Conduct

Please review and adhere to our [Code of Conduct](CODE_OF_CONDUCT.md) to ensure a welcoming and inclusive environment for all contributors.

## How to Contribute

### Reporting Issues

If you encounter a bug, have a feature request, or want to discuss improvements, please open an issue on our [GitHub issue tracker](https://github.com/your-repo/issues).

When reporting an issue, please provide as much detail as possible, including:

- A clear and concise description of the problem.
- Steps to reproduce the issue.
- Any error messages or screenshots if applicable.
- Information about your environment (e.g., operating system, browser, version).

### Submitting Pull Requests

We welcome and encourage contributions from the community! To submit a pull request (PR):

1. Fork the repository to your GitHub account.
2. Create a new branch for your changes:

```shell
git checkout -b feature/your-feature
```

3. Make your changes and ensure that they adhere to our coding guidelines (see [Coding Guidelines](#coding-guidelines)).
4. Commit your changes with a clear and concise message (see [Commit Guidelines](#commit-guidelines)):

```shell
git commit -m "feat: Add new feature"
```

5. Push your changes to your fork:

```shell
git push origin feature/your-feature
```

6. Create a pull request (PR) from your fork's branch to our `master` branch.
7. Describe your changes in the PR, referencing any related issues.

Our maintainers will review your PR and may request further changes or provide feedback. Once your changes are accepted, they will be merged into the project.

## Development Setup

To set up a development environment, follow these steps:

1. Clone the repository:

```shell
git clone https://github.com/your-repo.git
cd your-repo
```

2. Install project dependencies:

```shell
npm install # or yarn install
```

3. Follow any additional setup instructions in the project's README if available.

## Coding Guidelines

Please adhere to our coding guidelines to maintain code consistency throughout the project. Refer to the [CONTRIBUTING_GUIDELINES.md](CONTRIBUTING_GUIDELINES.md) for detailed coding guidelines.

## Commit Guidelines

We follow conventional commits for our commit messages. Each commit message should have the following format:

```
type: short description

Longer description (optional)

Closes #issue-number
```

The `type` can be one of the following:

- `feat`: New feature
- `fix`: Bug fix
- `chore`: Routine tasks, maintenance, or tooling changes
- `docs`: Documentation changes
- `style`: Code style changes (e.g., formatting)
- `test`: Adding or modifying tests
- `refactor`: Code refactoring
- `perf`: Performance improvement

## Testing

Ensure that your code changes include appropriate tests. Run the tests locally before submitting a pull request. Provide test cases for new features and bug fixes whenever possible.

## Documentation

If your changes affect user documentation, please update the documentation accordingly in the relevant files or folders. Make sure that your documentation is clear and concise.

## License

By contributing to this project, you agree that your contributions will be licensed under the project's license. See the [LICENSE](LICENSE) file for details.

Thank you for contributing to our project! Your efforts are greatly appreciated.
85 changes: 85 additions & 0 deletions CONTRIBUTING_GUIDELINES.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# Contributing Guidelines

Contributing guidelines are a set of rules and conventions that help ensure consistent and readable code across a project or organization. Adhering to coding guidelines makes it easier for developers to collaborate, maintain, and understand code. Below are some general coding guidelines that can be adapted to your specific project and programming language.

## 1. Code Structure and Organization

- **File Structure**: Organize your project files logically. Use directories to group related files. For example, separate source code from configuration files, tests, and documentation.

- **Consistent Naming**: Use consistent naming conventions for files, classes, functions, variables, and other identifiers. Choose a naming style (e.g., camelCase, snake_case, PascalCase) and stick with it.

- **Module Imports**: Keep imports organized and grouped. Avoid using wildcard imports as they can lead to naming conflicts and make it unclear which modules are used.

- **Comments and Documentation**: Add comments and documentation to explain complex code, functions, and classes. Use a documentation tool (e.g., Javadoc, Sphinx) if applicable.

## 2. Code Formatting

- **Indentation**: Use a consistent and agreed-upon indentation style. Common choices are tabs or spaces. Choose one and use it consistently throughout the codebase.

- **Line Length**: Limit lines of code to a reasonable length (usually around 80-100 characters) to improve readability. Break long lines into multiple lines if necessary.

- **Whitespace**: Use whitespace consistently for improved readability. Follow guidelines for spacing around operators, after commas, and between function arguments.

- **Brace Placement**: Choose a brace style (e.g., K&R, Allman, Stroustrup) and use it consistently. Place opening braces on the same line or the next line after a control statement.

## 3. Code Quality

- **Consistency**: Maintain a consistent coding style throughout the project. Enforce style guidelines using code linters or formatters if available for your programming language.

- **Avoid Magic Numbers**: Replace magic numbers (hard-coded constants) with named constants or variables with descriptive names. This improves code readability and maintainability.

- **Avoid Global Variables**: Minimize the use of global variables, as they can lead to unexpected side effects and make code harder to reason about.

- **Error Handling**: Implement proper error handling for exceptional cases. Use try-catch blocks, return error codes, or throw exceptions where appropriate.

## 4. Naming Conventions

- **Descriptive Names**: Choose descriptive and meaningful names for variables, functions, and classes. Names should convey the purpose or intent of the code.

- **Abbreviations**: Avoid unnecessary abbreviations. If you must use abbreviations, make sure they are well-known and documented.

- **Constants**: Use uppercase letters and underscores to name constants. For example: `MAX_LENGTH`, `PI`.

## 5. Code Comments

- **Inline Comments**: Use inline comments sparingly and only when necessary to explain complex logic or non-obvious code.

- **Function/Method Comments**: Include comments at the beginning of functions or methods to describe their purpose, parameters, and return values.

- **TODO and FIXME**: Use `TODO` comments to mark tasks that need to be completed in the future. Use `FIXME` comments to highlight issues or code that needs immediate attention.

## 6. Version Control

- **Commit Messages**: Write clear and concise commit messages following a convention (e.g., [Conventional Commits](https://www.conventionalcommits.org/)).

- **Branch Naming**: Use a consistent branch naming strategy, such as prefixing branch names with feature/ or bugfix/.

- **Pull Requests**: Follow the guidelines for creating and reviewing pull requests, including referencing related issues.

## 7. Testing

- **Unit Tests**: Write unit tests for your code to ensure its correctness and robustness. Follow best practices for test naming and organization.

- **Test Coverage**: Aim for high test coverage to catch as many bugs as possible. Use code coverage tools to track your test coverage.

## 8. Security

- **Security Best Practices**: Follow security best practices for your programming language and framework. Sanitize user input, use parameterized queries for databases, and avoid hardcoded secrets.

- **Dependency Management**: Keep dependencies up-to-date to patch security vulnerabilities. Use a dependency management tool (e.g., npm, pip) to manage third-party libraries.

## 9. Performance

- **Optimization**: Profile and optimize critical sections of code when necessary. Avoid premature optimization and prioritize readability and maintainability.

- **Resource Management**: Release resources (e.g., file handles, database connections) explicitly when no longer needed to prevent resource leaks.

## 10. Documentation

- **README**: Maintain a clear and informative README file that explains how to set up, use, and contribute to the project.

- **Code Comments**: Document code with comments as needed. Explain complex algorithms, data structures, or non-obvious implementation details.

- **API Documentation**: If your project provides an API, document it thoroughly, including usage examples and expected responses.

Remember that these guidelines are just a starting point. Adapt them to your specific project and team preferences. Consistency and communication within the development team are key to successful code maintenance and collaboration.
21 changes: 21 additions & 0 deletions LICENSE
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
MIT License

Copyright (c) 2023 AsmrProg-YT

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.