You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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);
}
The text was updated successfully, but these errors were encountered:
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:
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.
All methods which have
Task
orTask<T>
as the return type need to have Async as the suffix for the method name.Make sure to directly return the
Task
orTask<T>
object withoutawait
ing inside a method where you don't need to run any continuation. For instance:The
GetBarsAsync
method here doesn't need to await on the_bar.GetBarAsync
method call. It can just directly return the result as below:The text was updated successfully, but these errors were encountered: