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

EditorConfig file added and documented #203

Open
wants to merge 7 commits into
base: pages-source
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions .editorconfig
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# EditorConfig for Visual Studio 2022: https://learn.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options?view=vs-2022

# This is a top-most .editorconfig file
root = true

#=====================================================
#
# Settings for all file types
#
#=====================================================
[*]

# Generic EditorConfig settings
indent_style = space
indent_size = 4
end_of_line = crlf
charset = utf-8-bom
trim_trailing_whitespace = true
insert_final_newline = true

# Visual Studio spell checker
spelling_languages = en-us
spelling_checkable_types = strings,identifiers,comments
spelling_error_severity = information
spelling_exclusion_path = spelling_exclusion.dic
8 changes: 5 additions & 3 deletions content/contributing/cs-coding-style.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
# C# Coding Style
# C# Coding Style

For non code files (xml etc) our current best guidance is consistency. When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. Last, if there's a completely new component, anything that is reasonably broadly accepted is fine.

The general rule we follow is "use Visual Studio defaults". For details check the [Naming Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines) of .NET guide.

1. We use [Allman style](https://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. Even a single line statement block should go with braces and nested in other statement blocks that use braces.
2. We use four spaces of indentation (no tabs).
3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix static fields can be used with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (i.e. `static readonly` not `readonly static`).
3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (i.e. `static readonly` not `readonly static`).
4. We avoid `this.` unless absolutely necessary.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't reinforce the s_ and t_. IT's just a recommendation. But we do reinforce the _

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In dotnet's .editorconfig there is a rule that checks for this. You'll get a message that says "naming rule violation". As a simple contributor I would read that as a "must".

Also: see nanoframework/nanoFramework.Networking.Sntp#134 about this. I'm confused what is expected of me. I think if you produce a message about it, then it is part of the coding style.

Leniency is another question: how much can you deviate from the coding style? That is: when will your contribution be rejected because you first need to clean up the code. I guess if only the "s_" are missing, the contribution is accepted. But there may also be other violations that are acceptable...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For automated checks we have to choose one or the other. I'm afraid we can't have recommendations...
If we are stating that we are following .NET code style (which we aim to) then let's play ball and have those s_ prefixes.
No harm with that, it's just a convention.

Now, we will have extra work to "fix" these as we add the rules to the class repos and update the native code. But that's life. 😅

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for the contribution being accepted or not, considering that we'll have the editorconfig and will enable the check during the build in the pipeline, I suppose that makes it quite clear.

There is always a human reviewing the PRs and we try to be very friendly with the review comments. So not much to worry about.

For existing code, there will an extra step as we add the rules to the repos which will be making sure the code is compliant and make the necessary fixes.

5. We always specify the visibility, even if it's the default (i.e.
`private string _foo` not `string _foo`). Visibility should be the first modifier (i.e.
Expand All @@ -32,7 +32,9 @@ The general rule we follow is "use Visual Studio defaults". For details check th
18. Don't forget the header, the 2 lines simplified version can be used.
19. Try to avoid abbreviation, always use longer names when possible and where it does make sense. It is acceptable for very known ones to use them like HTTP for example. Also, if using abbreviations, the names should follow the the pattern. For example, if you are using `HTTP` in a name of a function called `Something`, it will then be `HttpSomething`. This goes as well for namespaces, classes, properties, variable names.

We have provided a Visual Studio 2013 vssettings file `nnnnn.vssettings` at the root of each repository, enabling C# auto-formatting conforming to the above guidelines. Note that rules 7 and 8 are not covered by the vssettings, since these are not rules currently supported by VS formatting.
We have provided an EditorConfig file `.editorconfig` at the root of each repository, enabling C# auto-formatting conforming to the above guidelines, in particular rules 1, 2 and 9. Visual Studio cannot auto-correct code to comply with other rules; these are verified by StyleCop when the code is compiled.

The EditorConfig also configures the Visual Studio spell checker. The spell checker is not enabled by default; it can be turned on/off by a button on the toolbar (the button with text *abc* and a green checkmark) or via the menu *Edit | Advanced | Toggle Spell Checker*. At the moment it can analyse the C#, C++ and markdown files that are open in he IDE. Code files typically contain jargon that is not recognised, e.g., the name of a communication protocol. If the spell checker flags such a word, choose to ignore it. The word will be added to the `spelling_exclusion.dic` file at the root of the repository.

## Example File

Expand Down
3 changes: 3 additions & 0 deletions spelling_exclusion.dic
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
nano
intellisense
nanoff
Loading