Skip to content

Contributing

Mendel Monteiro-Beckerman edited this page Jul 13, 2019 · 5 revisions

#Git workflow We use the master branch as our main working branch, and it is tagged for every release (that are made available on Nuget.org).

When submitting a pull request, please do it from master. We will test it in a branch on our side then merge it with master when it is considered reliable.

##CR-LF We use Windows format carriage returns, the .gitattributes file is set up to handle carriage returns properly

#Code expectations

We will be happy to integrate your changes in the project, but we have some expectations regarding the eventual proposals.

Coding conventions

We don't have a written coding convention but we like things to be coherent, so you should browse the code base to get a hang of our coding style.

Testing

We expect all features to be thoroughly tested, with explicit unit tests. Unit tests have to be clear and understandable at a glance, since they are as important as the actual code (if not more). We usually name our tests in plain English as explicitly as possible, regardless of the length of the method (public void should_not_handle_replayed_message_with_unknown_replay_id() is totally acceptable).

We try to apply the "Arrange Act Assert" pattern, but we don't necessarily write the // Arrange, // Act , // Assert comments, separating the code is enough.

#Commit messages

We try to use the 50/72 approach for commit messages, it is described in more details in the Git documentation but here are the key points:

  • Write a 50 chars or less summary in the imperative mode (e.g. "fix" instead of "fixed").
  • Leave a blank line.
  • Write a more descriptive text, wrapped to 72 chars.
  • "Fix bug" or "Some changes" are NOT good commit messages.

#Tools

We use the latest Visual Studio and Resharper versions, and we strongly advise contributors to do so as well. Features like unreachable code highlighting or dangerous usages detection (like multiple enumerations for an IEnumerable) are already reason enough to use it, but being able to coordinate our styling/snippets among the team makes it essential.

If you use Resharper and want to share our coding style rules / snippets, just add the Zebus.DotSettings layer in the "Manage Options" dialog:

manage_options_dialog

Clone this wiki locally