Coding style #10724
Coding style #10724
Conversation
agriffard
requested review from
Piedone,
sebastienros,
Skrypt,
deanmarcussen and
jtkech
|
Will review early next week. |
| 8. Avoid spurious free spaces. For example avoid `if (someVar == 0)...`, where the dots mark the spurious free spaces. Consider enabling "View White Space (Ctrl+R, Ctrl+W)" or "Edit -> Advanced -> View White Space" if using Visual Studio to aid detection. | ||
| 9. If a file happens to differ in style from these guidelines (e.g. private members are named `m_member` rather than `_member`), the existing style in that file takes precedence. | ||
| 10. We only use `var` when it's obvious what the variable type is (e.g. `var stream = new FileStream(...)` not `var stream = OpenStandardInput()`). | ||
| 11. We use language keywords instead of BCL types (e.g. `int, string, float` instead of `Int32, String, Single`, etc) for both type references as well as method calls (e.g. `int.Parse` instead of `Int32.Parse`). |
There was a problem hiding this comment.
Yes, for locals, params and members it is set to predefined types.
But currently it is set to framework type for member access as String.Something
There was a problem hiding this comment.
I'd use language keywords everywhere since that's what the majority of .NET projects use, even if that means changing those in the source. It's also something that can be enforced by analysers.
There was a problem hiding this comment.
I started to change it to BCL types for String.Format() in some places. I don't mind as I think there is not much difference between one or the other. It's just my own preference which requires adding a using System on every file that uses it. That's the only drawback but ... if we would use Global using I'm pretty sure using System would be the first there up top.
| 3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`). Public fields should be used sparingly and should use PascalCasing with no prefix when used. | ||
| 4. We avoid `this.` unless absolutely necessary. | ||
| 5. We always specify the visibility, even if it's the default (e.g. `private string _foo` not `string _foo`). Visibility should be the first modifier (e.g. `public abstract` not `abstract public`). | ||
| 6. Namespace imports should be specified at the top of the file, *outside* of `namespace` declarations, and should be sorted alphabetically, with the exception of `System.*` namespaces, which are to be placed on top of all others. |
There was a problem hiding this comment.
Yes, I like to have System.* first
Isn't it @Piedone ;)
There was a problem hiding this comment.
Not really, just alphabetical all the way :D.
|
|
||
| 1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces (See rule 17 for more details). One exception is that a `using` statement is permitted to be nested within another `using` statement by starting on the following line at the same indentation level, even if the nested `using` contains a controlled block. | ||
| 2. We use four spaces of indentation (no tabs). | ||
| 3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`). Public fields should be used sparingly and should use PascalCasing with no prefix when used. |
There was a problem hiding this comment.
Didn't know s_ for static fields, will use it
Didn't find any in our source code, is it what we recommend?
There was a problem hiding this comment.
I also discovered it recently, suggested by Resharper.
There was a problem hiding this comment.
Hmm, not sure about this one since it's a form of Hungarian notation. What advantages does it bring? Static fields should really-really rare though, especially thread static ones.
BTW such a convention will violate the general naming convention of fields of avoiding snake case.
|
What about placing each type in a seperate file, coz we have a lot of types placed into a single file |
| | Code of Conduct | [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) | | ||
| | Coding Style | [coding-style.md](coding-style.md) | | ||
| | Contributors | [Contributors.md](Contributors.md) | | ||
| | Guidelines for Contributors | [CONTRIBUTING.md](CONTRIBUTING.md) | |
There was a problem hiding this comment.
It would help editing to also add these to the solution.
| 3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`). Public fields should be used sparingly and should use PascalCasing with no prefix when used. | ||
| 4. We avoid `this.` unless absolutely necessary. | ||
| 5. We always specify the visibility, even if it's the default (e.g. `private string _foo` not `string _foo`). Visibility should be the first modifier (e.g. `public abstract` not `abstract public`). | ||
| 6. Namespace imports should be specified at the top of the file, *outside* of `namespace` declarations, and should be sorted alphabetically, with the exception of `System.*` namespaces, which are to be placed on top of all others. |
There was a problem hiding this comment.
Not really, just alphabetical all the way :D.
| 8. Avoid spurious free spaces. For example avoid `if (someVar == 0)...`, where the dots mark the spurious free spaces. Consider enabling "View White Space (Ctrl+R, Ctrl+W)" or "Edit -> Advanced -> View White Space" if using Visual Studio to aid detection. | ||
| 9. If a file happens to differ in style from these guidelines (e.g. private members are named `m_member` rather than `_member`), the existing style in that file takes precedence. | ||
| 10. We only use `var` when it's obvious what the variable type is (e.g. `var stream = new FileStream(...)` not `var stream = OpenStandardInput()`). | ||
| 11. We use language keywords instead of BCL types (e.g. `int, string, float` instead of `Int32, String, Single`, etc) for both type references as well as method calls (e.g. `int.Parse` instead of `Int32.Parse`). |
There was a problem hiding this comment.
I'd use language keywords everywhere since that's what the majority of .NET projects use, even if that means changing those in the source. It's also something that can be enforced by analysers.
|
|
||
| 1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces (See rule 17 for more details). One exception is that a `using` statement is permitted to be nested within another `using` statement by starting on the following line at the same indentation level, even if the nested `using` contains a controlled block. | ||
| 2. We use four spaces of indentation (no tabs). | ||
| 3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`). Public fields should be used sparingly and should use PascalCasing with no prefix when used. |
There was a problem hiding this comment.
Hmm, not sure about this one since it's a form of Hungarian notation. What advantages does it bring? Static fields should really-really rare though, especially thread static ones.
BTW such a convention will violate the general naming convention of fields of avoiding snake case.
|
|
||
| The general rule we follow is "_use Visual Studio defaults_". | ||
|
|
||
| 1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces (See rule 17 for more details). One exception is that a `using` statement is permitted to be nested within another `using` statement by starting on the following line at the same indentation level, even if the nested `using` contains a controlled block. |
There was a problem hiding this comment.
I'd use the the imperative mood throughout, i.e. "Use..." instead of "We use...".
Co-authored-by: Zoltán Lehóczky <[email protected]>
|
I think here we should also define Text format across the board. For example, how should the menu item be formatted or the page title. There is few menu items that are not consistent with other formats. Here is a great place for standards we could adopt |
|
@CrestApps Maybe in an Admin UI design guideline. |
|
Is this something you'd like to revisit and finish @agriffard? |
|
No, closing it.
|
Add coding style instructions.
Inspired by https://github.com/dotnet/SqlClient/blob/main/coding-style.md
Check if it is in adequation with our .editorConfig.