CONTRIBUTING.md

How to contribute

• Fork this repository, and then clone it.
• Nuke your nuget cache dotnet nuget locals all --clear

1. Create a new branch. This can be done easily on github.
2. Naming convention: <type of branch>-<name of your contribution> where * <type of branch> is generally either feature, improvement or fix (similar to issue labels) * <name of your contribution> would e whatever your code is going to be about, where it should use camelCase. In case of an issue, just add the ticket number.
3. Examples: * feature-commandOverrides (without an issue) * improvement-123-youtubeNotifications (for issue #123) * fix-123 (for issue #123) Please don't use just the number for bigger features, add some title to know what's that about without having to look it up.
4. Commit your code properly into your branch as you work on it.
5. Recommended IDE to write your code (You can also refer to fedoraloves.net for further information on C# in Fedora Linux.) * Jetbrains Rider - Windows, Linux and Mac. Prefered choice and active contributors will receive a license from Rhea. * Visual Studio Code - Windows, Linux and Mac. * Standard Visual Studio is not recommended, however you can use it if you prefer. There are issues ;)
6. Follow our naming conventions and code style guide below. (Set up your IDE for it...)
7. Discuss your problems and ideas with our awesome dev team on Discord, to further improve them!
8. Test your code.
9. Jetbrains Rider can nicely build, debug and run both mono and netcore on both Windows and Linux. VS, VSCode, MonoDevelop or Xamarin are not recommended for debugging.
10. Submit PullRequest when you're done. This can be done easily on github. e.g. 1. 2.
11. New features or improvements or any other large changes should go into the dev branch.
12. Really tiny fixes and typos, or tiny improvements of a response message, etc, can go straight into master. If in doubt ask.
13. If there is an issue for your PR, make sure to mention the #number in the title.

Code style and Naming Conventions

Just a few guidelines about the code:

• If you're writing a new module, try to write summary for public and internal methods.
• Use PascalCase for member properties and this notation when accessing them. Treat internal as public, and protected as private. Treat constants as public as well, ie PascalCase.
• Always immediately initialise variables.
• Always explicitly declare whether methods are public or private. If they are async, this keyword should be second (or third in case of static methods public static async Task ...)
• Never return void with async methods. Return Task instead of void.

    
  public class BunnehClient<TUser>: IClient<TUser> where TUser: UserData, new()
  {
    public enum ConnectionState
    {
      None = 0,
      Bad,
      Good,
      Peachy
    }
    
    internal const int LoopLimit = 60;
    
    public ConnectionState State = ConnectionState.None;
    
    internal int LoopCount{ get; private set; } = 0;
  
    	
    /// <summary> This is blocking call that will await til the connection is peachy.
    /// Returns true if the operation was canceled, false otherwise. </summary>
    public async Task<bool> AwaitConnection<TUser>(TUser user) where TUser: UserData, new()
    {
      while( this.State != ConnectionState.Peachy )
      {
        if( this.LoopCount++ >= this.LoopLimit )
          return true;
  
        await Task.Delay(1000);
      }
  
      await user.SendMessageAsync("You have been connected!");
      return false;
    }
  }

Please try to set-up your IDE to handle this for you:

• Use tabs, do not expand to spaces. (Yes we're that old.)
• Always use explicit types. Do Not Use var!
• Set the IDE to remove trailing whitespace, it triggers OCD...
• Default VS-style will try to format your code in rather weird way that is a little irational. Please follow the above displayed format: if( something ). (Note that the VS style would place spaces for if statement this way: if (something))