C# 6.0 Feature: using static #9
Conversation
BillWagner
force-pushed
the
feature-using-static
branch
2 times, most recently
from
63a4c98
to
80bb520
Current spec text for using static proofread fixes
I chose to use non-descript names rather than provide an example from the class library. I think that's sufficient to understand, and doesn't beg more questions about the design decision (even in an informative example).
Broadly fine - just some formatting nits.
| > { | ||
| > class A {} | ||
| > } | ||
| > class C |
There was a problem hiding this comment.
A blank line between each top-level declaration? This is a bit hard to read as-is. (We might want to talk about this - it looks like a lot of examples don't have lines between top-level declarations.)
There was a problem hiding this comment.
I did add them here.
I didn't resolve the conversation so we can discuss at the upcoming meeting.
There was a problem hiding this comment.
Group decided to add a blank line between peer declarations (other than obvious cases where it would harm readability, e.g. where there are 5 methods one after another, all with an implementation of {}, just for signatures etc).
@BillWagner: Do you want to make the change consistently in this PR and we'll work out what to do elsewhere?
There was a problem hiding this comment.
I'll make the changes consistently in the areas touched by this PR.
I'll keep notes and make an open issue for all formatting so we have a record of our preferred formatting. Maybe we can get some community help on that task.
I have nothing more to add.
Co-authored-by: Jon Skeet <skeet@pobox.com>
I wanted to check other clauses in the standard to compare. Jon is correct.
|
Meeting is happy to merge when formatting is sorted. |
Make the following changes to the code samples in this clause: - Add a blank line between peer elements *except* for multiple `using` directives and multiple `alias` directives. (I did add a blank line between `using` and `alias` directives. - Use Allman brace style on non-empty `class` declarations. (I'd prefer using Allman brace style on methods, but the standard currently uses K&R style for methods consistently.
@jskeet I tried to make the changes in this clause to develop our general practice.
I followed the notes from the meeting, and then applied my own opinion on whitespace, because I was doing the work.
| @@ -669,7 +713,9 @@ Using this notation, the meaning of a *qualified_alias_member* is determined as | |||
| > *Note*: The identifier `global` has special meaning only when used as the left-hand identifier of a *qualified_alias_name*. It is not a keyword and it is not itself an alias; it is a contextual keyword ([§7.4.4](lexical-structure.md#744-keywords)). In the code: | |||
| > ```csharp | |||
| > class A { } | |||
| > class C { | |||
| > | |||
| > class C | |||
There was a problem hiding this comment.
This was one of 2 instances for K&R braces on class declarations. That's why I changed this one.
| > class C { | ||
| > | ||
| > class C | ||
| > { |
There was a problem hiding this comment.
second instance of K&R braces on a class
| @@ -166,6 +167,7 @@ Within global attributes and member declarations in a compilation unit or namesp | |||
| > namespace N3 | |||
| > { | |||
| > using A = N1.N2.A; | |||
| > | |||
There was a problem hiding this comment.
@jskeet This was one type of change I wanted to check on. I think it's better by having the blank line, but it's a very mild preferences.
For our "coding style", I'd like to say different elements should have a blank line between them. On the other hand, I like a rule that doesn't add a blank line where the element is an empty class or namespace.
See also line 179, 192, 201-203.
There was a problem hiding this comment.
Mmm, interesting. I probably wouldn't have added blank lines in 179, 192, 201-203... but I'm quite happy for us to do so, and that should probably be the default. We should just allow ourselves to have an exception for things like:
public void M(int x) {}
public void M(string y) {}
public void M(int x, string y = null) {}... in an example about overload resolution, for example.
There was a problem hiding this comment.
I agree. I think that's easily handled by adding methods to my exception in the previous comment.
There was a problem hiding this comment.
I opened #358 to start the coding standard discussion.
I'll merge this.
PR #9 has been merged, so this is done now.
PR #9 has been merged, so this is done now.
Current spec text for using static.
Creating a draft PR because of outstanding TODO item.TODO item is complete.Fixes #51
Fixes #199
The text was updated successfully, but these errors were encountered: