Dos and Don'ts for your 1st PR in professional world

This is my first time writing here, so it maybe a bit wonky but I'll try my best to deliver here. So this article is basically a starter's guide for all freshers/beginners who just started in the professional world.

Ensure correct formatting

So that your code does not look like this:

Whatever language you might be working with and however much you think that your code is clean, there will always be comments on your PR regarding code formatting if you don't stick by some rules:

1. Always keep your variable names concise and as clean as possible, check earlier code if people used camelCase or snake_case or whatever other case. Make sure your variables follow the same case!
2. Same applies for function names and calls.
3. Always run the completed code through a formatter. Here are some popular formatters:
   • Prettier: JavaScript, TypeScript, HTML, CSS, and more.
   • Black: Python.
   • gofmt: Go.
   • RuboCop: Ruby.
   • clang-format: C and C++.
   • PHP_CodeSniffer: PHP.
   • ESLint: JavaScript and TypeScript.

(Check with your seniors which one they use, as they might prefer
something other than this)

Thoroughly test your code before committing

Just like your ex, the code does not care about your feelings. So test it thoroughly before committing. Otherwise get ready to spend the cozy evening you planned, fixing your commits.

Pro-tip:

• Even if there is no essential logic or syntax change, test your code one last time before it goes.

Keep the commit message as clean and concise as possible

The reviewers aren't mentalists and probably look like this while reviewing your PR:

So do them a favor and keep the message clean. You can ideally follow this template, but confirm with seniors before using:

• 1st line: One-liner about what your change does
• 2nd line: ---Empty---
• 3rd line: Why was the change needed, in detail (you may take multiple lines for this)
• end: What is your change, in detail (you may take multiple lines for this as well)
• additional : You may also mention details like record ID or ticket ID as required (check old PRs to refer)

In the end, try to keep everything short and sweet.

Pushing the changes and raising the PR

This is the stage before the final stage of your PR. Exercise as much caution as possible here especially while raising the PR. Once your changes are pushed to your fork, you may be prompted to raise a PR by a URL in the terminal or you might need to raise it manually (although I would say the URL in the terminal is most common). Once you go to the URL, you will be prompted to select the branch you want to raise PR to. Here you need pay attention to the source and the target branch. Make sure the source is your branch from your fork and the target is the correct branch from the main repo. (Take seniors help here if you're unsure which is the correct branch). Once this is done, you will see a page where the 1st line of your commit has become the PR title and rest of the body is the PR message. Here, you can confirm the diff one last time to ensure that it only shows the changes you did, if any other changes show up, do NOT raise the PR as it may result in merge conflicts.
Once confirmed, go ahead and raise that PR!

Final stage

After raising PR, the reviewers will start reviewing your PR and may post some comments based on logical and syntactical aspects of the code. Make sure you answer their concerns in a short and concise manner. Post approval ask them to merge the PR as well. (Sometimes there is an additional step to merge the PR)

Finally your code changes are merged! Congrats on your 1st successful PR merge in the professional world!

Additional tip

Always make sure your PR has only 1 commit