Need to create a CI type checker before merge. Caught a markup bug in #107.

Hey. Thanks for your awesome project guidlines.

In the en doc, there is one step in the Gitflow that maked me confused when I polished the zh one.

Update your feature branch with latest changes from develop by interactive rebase.
git checkout
git rebase -i --autosquash develop

To my certain knowledge which may be wrong, the git rebase -i --autosquash develop command is used to update develop branch with the changes you have make in the feature branch. Did I misunderstand it? Look forward to your reply.

The Link : https://medium.com/@kentcdodds/why-semver-ranges-are-literally-the-worst-817cdcb09277 is broken

Hello Team Hive!

Great job on this so far, I would suggest in the git workflow section you add steps to setup a repository which are currently missing. I would like to add these as the first steps. They will give you standard branches used in your workflow (ie develop / feature / bugFix etc)

git init
git flow init

More than happy to PR

Why : "Even though your build process can(should) get rid of them, make sure that your code style checker warns you about leftover console logs."

As a beginner, this doesn't explain me (at all) why it should be avoided. Printing startup data (ip/port etc...) doesn't seem to hurt, does it ?

Thanks for clearing-up this point :)

In section 7 it says:

Always use //TODO: comments to remind yourself and others about an unfinished job.

Some developers avoid // TODO and prefer to open a ticket for any single reminder. This is to prevent TODOs from piling up in the source code.
I personally use a combination of them and I use // TODO mostly to remind myself if there is a need for refactoring.

I think the best approach is using //TODO(#3456) where the number is a ticket and it's enforced by a lint rule. Should we add a sub-section for this? any thoughts/suggestions?

various frameworks support multiple .env files (using naming conventions) to support multiple target destinations

I think Prettier Should be added to the code style recommendations, no?

Hi there,
I have a question about git flow(i am not sure about it's type of flow). Please help me answer this question. I really appreciate your time.

We have a central repository with a branch called "feature-branch-A".
We have 4 peoples(include me) are working on that branch. So those people will fork that center repo (create their own public repo) and work on "feature-branch-A".

After some days, when i am done with my task(task 1), i pushed code to my own public repo and created a PR for merging to "feature-branch-A" on the central repo. But unfortunately my team lead disapproved my PR(we don't need that task 1 anymore) and force me working on other task(task 2) not related to the current task(task 1) (but both still in the "feature-branch-A").

In that situation, what is the best practices for handling my public own repo?

1. I will revert all my commits for task 1 on my public own repo. And continue working on task 2. But when i am done with task 2, i push code to my own public repo and create PR for it. But that PR will include all commits of task 1(new code commit and revert commit) although we don't see any code changes for task 1.
2. I will delete my public own repo and re-fork again for working on task 2.

Thank you so much for reading my question.

Hello,

Recently we discussed in the Topcoder Community, and people have different opinions regarding errors messages.

From your best practices:

Response messages must be self-descriptive. A good error message response might look something like this:

// (1)
{
    "code": 1234,
    "message" : "Something bad happened",
    "description" : "More details"
}

or for validation errors:

// (2)
{
    "code" : 2314,
    "message" : "Validation Failed",
    "errors" : [
        {
            "code" : 1233,
            "field" : "email",
            "message" : "Invalid email"
        },
        {
            "code" : 1234,
            "field" : "password",
            "message" : "No password provided"
        }
      ]
}

Based on my understanding, (1) schema can be used as a general error format, and (2) schema can be used for a specific situation (validation errors in this case).
That means error responses don't have to have the exact format with the same properties.
Some developers insist that all error responses should be consistent and be the same.

Could you clarify it according to your best practices in this project?

Because why not :)

This would be a good addition to the guide as they encourage a good commit policy and push you towards implementing continuous integration workflows.

There are a few good tools that make git hooks easy such as husky, among others.

If approved, I can start working on adding this to the guide. Let me know your thoughts.

Cheers! ❤️

In 1.2, we can read the following:

You can use --autosquash to squash all your commits to a single commit. Nobody wants many commits for a single feature in develop branch. read more...

I think that asserting that nobody wants that is a fallacy. There are good reasons for which you would want to keep those commits separated even in develop branch:

• know what the reason of a change was when doing a git blame, which is naturally in the commit message/description and not in the feature
• having more precision for git bisect: squashing makes you lose information as you only know which feature caused a regression, rather than a specific commit (the latter narrows the scope)

Those are the reasons why I never squash my commits into a feature commit. You should therefore mention in your guidelines that this is subjective.

I like the part about API design, it's in a nutshell and concise.

If I may, the API Versioning part is actually dear to me since we've been rolling this solution out at work and I spun-up a modular and lightweight middleware for Express which does exactly that: https://github.com/lirantal/express-version-route

Would it be ok to reference it in the README?

I want to translate this guideline by forking a repo if you approve.

Since the guides were written long time back, most of the references to the main branch are master. And most of the organizations are making a move to have an inclusive language, even Github started renaming the master branch as main. Can we please update the guides for the same?

This formatting is a bit confusing. It looks as though, e.g., you are suggesting that the user do ls | npm Documentation (i.e., UNIX ls command piped to npm Documentation). It also won't be clear to new users that one must prepend the npm command. I recommend changing this formatting to formatted code npm ls with a "documentation" link after and clearly differentiated from the code example.

Since this guide mainly focuses on JS projects, I think we should remove Enunciate and Miredot from the list.

Thoughts?

How about immigrate those guidelines to Gitbook?

Lots of trailing spaces. I have Sublime configured to remove those on save. It created a huge diff. I think they should be removed and there should be a linter checking those prior to merge.

There are exclamation marks in .gitignore file.

.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

Why preffered like that?

You have a step "Make Changes." (here), where you say this:

git add
git commit -a

Why:

git commit -a will start an editor which lets you separate the subject from the body. Read more about it in section 1.3.

However, this will not work. When someone runs git add, it will output the following:

➔ git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?

Also, git commit -a does NOT mean "start an editor". It means the following (straight from man git-commit):

-a, --all
           Tell the command to automatically stage files that have been
           modified and deleted, but new files you have not told Git about
           are not affected.

If you want, I can make some changes to this and shoot you a PR. 😄

Having a section on issues best practices, particularly as it relates to development, would be useful. E.g.:

• All non-trivial commits should tie back to a single issue
• Issues should have acceptance criteria (and... other stuff... possibly user stories/etc, but could get too much into "product" land)
• Issues should be closed via commit messages to better create a paper trail to document issue origination to code commit.
• Label usage

... something like that anyway? I personally favor Github Issues, but this section could be agnostic (or have separate issue tracker carveouts?)

Hello,

Nice initiative !

However, a set of rules is never well followed when one does not fully understand why the rules were enacted. It also helps to adhere to a rule when one knows what can occur if the rule is ignored.

I think that along with the list of rules, the reasons why each of them was written this way should also be detailed (through hyperlinks to not clutter the rules list itself). Pointing to issues that occurred when a rule was not followed would also help.

Like, there's no develop or any other branches (which is considered necessary in this guideline). Everyone pushes directly to the master branch.

I don't know if it's proper (for opening an issue like this). Sorry for bothering, I just want to provide my personal opinion.

Instead of:
https://github.com/wearehive/project-guidelines/blob/4baf60bab3fc3d4616712b04f3dab48a3774d20c/config.sample.js#L1-L9

Maybe its an idea to use dotenv-safe, with that you can define the needed env variables in the .env.example (the optional ones can be prefixed with # ).

http://editorconfig.org

Is extremely useful for projects with more than 1 developer working on the code!

what do you think about https://github.com/shieldfy/API-Security-Checklist

Hello,

I would like to include some other editors such as Eclipse in the workspace exclude for the .gitignore.
Happy to PR if you feel appropriate

Write testable code, avoid side effects, extract side effects, write pure functions

Appears two times.

I guess it's a mistake? In the first section, there's only explanation about Pure Functions, so I think that its title could be 'Write Pure Functions'.

I want to translate this guideline by forking a repo if you approve.

As the screenshot I have added point out, the whole of the content uses a declarative and instructive verbiage while explaining concepts whereas a few of the headings in the Coding Style sections deviate from the rest in a way that they are more suggestive or in some cases not instructive but informative.

My suggestion would be to make it a little bit consistent with the rest of the headings while still keeping it's original suggestive meaning.
also I would love to work on the same as it seems like an easy fix.