A Flutter App for Approach Helping Hands Foundation (AHHF).

First please do fork this repo into your own account. Fork by clicking on the fork button on the top right.

Do not clone this Original repository. Only clone the forked repository.

While working on the app in your local folders, do not commit and push changes to this Original repository. Only push changes to your own personal forked repository.

After pushing changes to your personal forked repository, create pull request to merge changes into the Original repository. Do not merge the changes without consulting with others.

Before making any changes to the codebase, it is important to make sure that you have the latest version of the code. This can be done by running the command git pull origin main to ensure that you have the latest updates from the remote repository. This will help prevent conflicts with other contributions and ensure that your changes are based on the most recent version of the code.

It is important to provide a clear and concise description of the changes that you are making. This makes it easier for others to understand the changes that you are making and to review your code. It is also a good practice to add screenshots in the description to show the changes that you are making.

A clear and concise commit message is important for maintaining the project's history and making it easier for others to understand the changes that were made. It is a good practice to prefix the commit message with the type of change, for example, feat: for a new feature, fix: for a bug fix, and docs: for documentation changes. For example, a commit message for a bug fix could be fix: resolved issue with login functionality and for a new feature, it could be feat: added new dashboard to track user data.

It is a good practice to name the branch that you are working on with a descriptive name that is related to the changes that you are making. For example, if you are working on a new feature, you could name the branch feature/new-dashboard or if you are fixing a bug, you could name the branch bugfix/login-error.

It is important to use descriptive names for variables, functions, and other identifiers. This makes it easier to understand the code and to find and fix bugs. It is also a good practice to use camelCase for variable names and PascalCase for component names.

Comments are important for explaining the code and for making it easier to understand. It is a good practice to add comments to explain the purpose of the code and to add comments to explain any complex logic. It is also a good practice to add comments to explain any workarounds or hacks that were used to fix bugs or to implement a specific feature.s

Maintaining a consistent and logical folder structure is important for keeping the codebase organized and easy to navigate. It is a good practice to create a separate folder for each component or feature and to keep related files, such as styles and tests, in the same folder. For example, you could have a components folder that contains subfolders for each component, such as header, footer, sidebar, etc. and each subfolder should contain all the related files for that component like index.js, styles.css and test.js

Using third-party libraries can save time and improve the functionality of the project, but it is important to use them responsibly. Before adding a new library, consider whether it is necessary and whether there are alternative solutions. It is also important to keep the libraries up-to-date and to document their usage in the codebase. Additionally, make sure that you have the necessary licenses to use the libraries in your open-source project. You should always get consent before using third-party libraries, and make sure that you have the necessary licenses to use them.