Feature/go conventions

[marcel-aan-zee]

renewed the Go code conventions

[SeJuDesign]

Should we standardize the make commands? example would be the npm run start and npm run build

[marcel-aan-zee]

Describe make file "standards"

[leondevries]

I don't see why start is necessary, start should be the root.

project structure for an API / Web application

main / start

• business / app (separation of concerns)
  • domain (e.g.: users, cars, chairs etc. etc.)
    • handlers
    • middleware (local middelware)
    • models
    • queries (if you work with a database)
    • repositories
    • services
    • validators
• config
• datamodels
• helpers
• middleware (global middelswares)
• web / server

[marcel-aan-zee]

capWeb.Authenticate > capilaMiddleware.Au....

[marcel-aan-zee]

config
go > src folder
dist

[leondevries]

Variables should always explain what it does
Like in this example:
assert := asserts.New(t)
assert.Equals("Check", someVar)

or in a loop, like in this example:
for key, user := range users {
println("key:", key)
println("val:", user)
}

In any other case, it is wise to name the variable after the thing it contains.
If is can hold a collection of things, name it plural, like "users".
If it can only hold one value, name it singular, like "user".
if it is a boolean var, start it with something like "has", or "is".

which is mostly used for checking if an element is present in a map.
It's also common use, when a variable name holds an abbreviation, that the letters are all capitals, or all lowercase.
like "SQLStatement" or "sqlStatement"

[PeterdeJ]

Good suggestion. Let's use this instead.

[SeJuDesign]

Also, what's the convention on naming const variables?

[marcel-aan-zee]

eerste stuk overnemen

[SeJuDesign]

Standard behavior of go mod places the dependencies in your $GOPATH, go mod vendor puts them in a vendor folder inside your project, running go build -mod vendor uses the dependency put in the vendor folder. This further isolates the project from the globally installed dependencies

[marcel-aan-zee]

look at 1.13

[rickvandermeij-aanzee]

I guess sonarQube will be sufficient. But can be used for all languages, so maybe move to general?

[marcel-aan-zee]

I want to know how the sonarcube linting can be changed. (is the change of the configuration a project setting that can be exported/imported (and can be checked in with the project itself?)

[PeterdeJ]

Looks like in the last commit the title 'Makefile' was removed (intentionally?) and an empty title ("##") was added. I would suggest adding a title or removing the empty title :)

[marcel-aan-zee]

fixed

[rickvandermey]

Wellicht nog even goed kijken naar de MD structuur, leesbaar is het nu allerminst, geldt voor de volledige MD file

[rickvandermey]

Lint rules should be core. Without the correct 'style', the linter should fail with error code, thus the pull request cannot be merged