Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add .dotsettings file #40

Open
tugberkugurlu opened this issue Jan 30, 2017 · 1 comment
Open

Add .dotsettings file #40

tugberkugurlu opened this issue Jan 30, 2017 · 1 comment

Comments

@tugberkugurlu
Copy link
Owner

This is to lay down some coding/naming guidelines in place to make refactoring a bit easier for contributors.


Coding Guidelines

When you are contributing to a project (this doesn't need to be an OSS project), you should always keep the style consistent. KLoggy project adopts some coding guidelines and it's best to check them before you want to contribute to this project.

C# Coding Conventions

In general, KLoggy project adopts Allman bracing style for any type of C# code. You can find some specific rules below:

  • Private fields are prefixed with an underscore and camel-cased (to be more specific, it's lower camel-cased).

  • Always include curly braces around blocks, even when they would be optional.

  • Using statements go at the top of the file, before the namespace declaration, with System directives first.

  • Use of regions (#region) is not permitted.

  • Use var, not the explicit type name.

  • Public properties should not have setters unless it's necessary for the behavior of the class. If the property is required for the class, accept it through the constructor and make sure it's validated inside the constructor.

  • Prefer extension methods over instance methods when it's possible to achieve the required behavior through the public members of the class. For example:

     public interface ILoggerProvider
     {
         ILogger Create(string name);
     }
    

    We can make it easy for consumers of this interface to create a new logger by passing the Type as a generic parameter and we don't need to polute the interface for this behavior as it's possible to provide it by using the Create method above.

     public static class LoggerFactoryExtensions
     {
         public static ILogger Create<T>(this ILoggerFactory factory)
         {
             if (factory == null)
             {
                 throw new ArgumentNullException("factory");
             }
    
             return factory.Create(typeof(T).FullName);
         }
     }
    
  • All methods which have Task or Task<T> as the return type need to have Async as the suffix for the method name.

  • Make sure to directly return the Task or Task<T> object without awaiting inside a method where you don't need to run any continuation. For instance:

     public class Foo 
     {
     	private const string FooBar = "foobar";
     	private readonly IBar _bar;
     
     	public Foo(IBar bar)
     	{
     		_bar = bar;
     	}
     
     	public async Task<Bar> GetBarsAsync()
     	{
     		Bar bar = await _bar.GetBarAsync(FooBar);
     		return bar;
     	}
     }
    

    The GetBarsAsync method here doesn't need to await on the _bar.GetBarAsync method call. It can just directly return the result as below:

     public Task<Bar> GetBarsAsync()
     {
     	return _bar.GetBarAsync(FooBar);
     }
    
@dealproc
Copy link
Collaborator

dealproc commented Jan 9, 2019

@tugberkugurlu are you willing to create this, as this is something I am unfamiliar with at this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants