Add DotNet style guide basic layout #20
Conversation
matiasbeckerle
requested review from
AlphaGit,
andresmoschini,
jfazzini,
mravinale,
gastonmancini,
easla,
Abriscioli,
afantini,
mvazquez-ms,
pbarrios,
lmarquezMS and
martinkeimel
There was a problem hiding this comment.
Some suggestions:
- I would move resources below the rules, since the most "meat" this guide will have will be the rules.
- I would give a definite name to "Some Title", maybe "General" for now and we can redefine later (so that until we do that, it doesn't look "wrong")
- Great start! Thanks for putting this together.
DotNet/README.md
Outdated
| IUserService userService = new UserService(); | ||
|
|
||
| // Allowed because the variable is poorly named from legacy code | ||
| Graph g = new Graph(); |
There was a problem hiding this comment.
I think that this scenario could be removed, it is normal to break the rules in exceptional cases like legacy code.
There was a problem hiding this comment.
+1. Each team should decide if legacy code should be adjusted (gradually or all at once) or not depending on each project's context
There was a problem hiding this comment.
Good point, will remove.
DotNet/README.md
Outdated
| IUserService userService = new UserService(); | ||
|
|
||
| // Allowed because the variable is poorly named from legacy code | ||
| Graph g = new Graph(); |
There was a problem hiding this comment.
BTW, I would like to see an example of this Eric Lippert's sentence:
Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
Personally, I prefer to always use var.
There was a problem hiding this comment.
😄 Agree. Maybe if you try a comment on the blogpost, who knows... Eric seems to leave really cool responses as @mvazquez-ms points every day.
There was a problem hiding this comment.
BTW, I would like to see an example of this Eric Lippert's sentence:
Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
I have one example in mind where explicit type is slightly more readable than var. (For the record, I prefer var 99.99% of the time)
A method receiving a Func<T1,T2,TResult>
public void SomeMethod(Func<int, int, bool> intComparer)
{
// do something with intComparer
}
// Explicit Type
Func<int, int, bool> greaterThanComparer = (x, y) => x > y;
SomeMethod(greaterThanComparer);
// Implicit Type 1 (this won't compile as type cannot be inferred)
var lessThanComparer = (x, y) => x < y;
SomeMethod(lessThanComparer);
// Implicit Type 2 (I find this harder to read than the explicit type version)
var lessThanComparer = new Func<int, int, bool>((x, y) => x < y);
SomeMethod(lessThanComparer);
// Local Function (unusual syntax)
bool equalityComparer(int x, int y) => x == y;
SomeMethod(equalityComparer);
(Also, for this scenario to be valid, the expression should be a bit more complex or require to be re-used somehow, otherwise we can just use it like: SomeMethod((x, y) => x > y); )
Of course this is a rare scenario, and it's OK if someone still prefers the implicit type version..
|
Nice initiative @matiasbeckerle, thanks! I want to mention that VS2017 supports some editorconfig extensions that could be useful to document and encourage the usage of some of the guidelines. See more details in: |
|
Nice! We really need this. The only comment I have so far is I think we should name it C# style-guide. DotNet is too broad, and if we put anything DotNet-related here, it will become huge. (e.g. On 3.0, we had tons of rules for XAML code, that's DotNet) |
|
Agree with you @mvazquez-ms. Actually I forgot to put that question on the PR description, as usually forgot something. I will rename this one. Thanks. |
|
Thank you @andresmoschini for the |
|
Thanks @AlphaGit, appreciated. Agree on both things:
|
matiasbeckerle
force-pushed
the
dotnet-start
branch
from
34fda26 to
edcfd58
Compare
|
Thank you all for participating, commenting, smiling or thumbing up! Appreciated. Feel free to join in upcoming discussions! |
Background
We were discussing a lot in several pull requests across different projects. This PR aims to set a base for putting the conclusions about style stuff. Please feel free to add, modify, delete, suggest, comment, whatever.
Changes
DotNet.Pending
Notes