| Age | Commit message (Collapse) | Author |
|---|
|
When a test name suffix consists of multiple words camelCasing should be
used to indicate separation of words.
|
|
Use %w to wrap errors
See merge request gitlab-org/gitaly!2877
|
|
Code style document updated to notice on the error wrapping and useful links for reference.
|
|
Since v2.25.0 of git you've been able to use this way of doing it. See
git-vcs/git@1f0fc1db85 (pretty: implement 'reference' format,
2019-11-19).
So let's use that example, and while I'm at it change the SHA-1 in the
example here to the one that landed in the repo, not some pre-rebase
version that was only in @pks-t's local repo.
|
|
While our style document currently contains mostly advice about code
hygiene, commit hygiene is also important for a project to ensure it
ends up with understandable commits. It ensures that it is easily
possible to dig up the reasoning behind changes in the future, making
the project easier to maintain in the long run.
This commit thus documents various best practices around commit hygiene.
|
|
style: Document location of `TestMain()` function
See merge request gitlab-org/gitaly!2799
|
|
While many tests use a `testhelper_test.go` file to implement
`TestMain()`, this is not common to all. This makes test setup harder to
find than necessary. This commit thus documents the recommended name of
"testhelper_test.go" for such code.
|
|
Using `os.Exit()` will cause the calling process to exit immediately
without executing any deferred functions. In the context of our tests,
this means that any created ondisk state may not get cleaned up
correctly. This commit thus documents those pitfalls in "STYLE.md".
|
|
|
|
Go vet, editors, and other tooling will emit warnings when a struct
doens't have the fields names, as it falls back on ordering. That could
introduce bugs when new fields are added with the same type at the
beginning of a struct.
To reduce the number of warnings in my editor, I ran a `sed` script to
update the code.
|
|
Our current policy with regards to pointer vs. value receivers is not
documented anywhere. Given that we have a policy saying that if a single
method requires a pointer receiver, all methods should be pointer
receivers, there's some non-obvious bits to our coding style. So let's
write this part down so we can point to it from now on.
|
|
There's currently a lot of different practices sprawling throughout the
codebase when it comes to logging, so chances are high you will not use
up-to-date best practices when writing new logging code. So let's nail
down our logging style so we have a document we can consult and point
to.
|
|
Developer-facing code should use the ASCII character set as far as
possible to ensure improve accessibility across platforms. Many
platforms lack a lot of UTF8 code glyps, leading to code that is hard to
read on such platforms if they are used.
Add a note to our style guide that mandates this rule.
|
|
Add a note on ordering of functions and types
See merge request gitlab-org/gitaly!1949
|
|
Types should be declared before their first. Let's document this in our
style guide.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts merge request !653
|
|
|
|
|
|
|
|
|
|
|
|
|
