-
Notifications
You must be signed in to change notification settings - Fork 2
Address some stuff reported/suggested by code analyzers #167
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
Conversation
return type.GetCustomAttributes<AuthorizeWhenAttribute>().Select(AuthorizerDefinition.Create).ToList(); | ||
} | ||
public static List<AuthorizerDefinition> GetCustomAuthorizers(Type type) => | ||
[.. type.GetCustomAttributes<AuthorizeWhenAttribute>().Select(AuthorizerDefinition.Create)]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan of this syntax. Also this space after ..
is weird for me, but that's probably a csharpier thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The space is indeed a CSharpier thing. Weird, but I don't hate it.
(Take a look at how CSharpier formats XML files like csprojs to see something truly cursed 🙈)
As for [.. foo]
vs foo.ToBar()
, I'm not opposed to keeping the latter but the former does have one major advantage: it does the right thing with a single syntax, for many collection types, as long as the type can be inferred from context. But maybe there's enough space to keep both of them, without favoring one over another?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Take a look at how CSharpier formats XML files like csprojs to see something truly cursed
What do you mean? I've used csharpier 1.0.x somewhere, and csprojs seemed fine? 🤨
I'm not opposed to keeping the latter but the former does have one major advantage: it does the right thing with a single syntax, for many collection types
Right, that's true. I'm not hugely opposed, might even convience myself to using it, so there's place for coexistence of both for sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? I've used csharpier 1.0.x somewhere, and csprojs seemed fine? 🤨
contractsgenerator/examples/project/Directory.Build.targets
Lines 3 to 5 in cf1ac68
<TargetFrameworks Condition="$([MSBuild]::VersionLessThan('$(NETCoreAppMaximumVersion)', '9.0'))" | |
>net8.0</TargetFrameworks | |
> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have somewhat mixed feelings about the [.. X.Select(Y)]
- this mixes both the spread operator and LINQ and I don't really know what to think about it. [.. X]
is great, but I don't know if the ~4 chars are worth using instead of X.Select(Y).ToList()
.
But I don't hate it also. So basically indifferent. ^^'
[Theory] | ||
[InlineData((byte)10)] | ||
[InlineData((sbyte)10)] | ||
[InlineData((int)10)] | ||
[InlineData((long)10)] | ||
[InlineData((short)10)] | ||
[InlineData((uint)10)] | ||
[InlineData((ulong)10)] | ||
[InlineData((ushort)10)] | ||
[InlineData(10)] | ||
[InlineData(10L)] | ||
[InlineData(10U)] | ||
[InlineData(10UL)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old one was consistent at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, except .NET complained that the cast in (int)10
was redundant. If only we had byte
and short
literals 😢
src/LeanCode.ContractsGenerator/Compilation/ContractsCompiler.cs
Outdated
Show resolved
Hide resolved
public class ContractsGenerator(CompiledContracts contracts) | ||
{ | ||
private readonly CompiledContracts contracts; | ||
private readonly CompiledContracts contracts = contracts; | ||
|
||
private readonly TypeRefFactory typeRef; | ||
|
||
public ContractsGenerator(CompiledContracts contracts) | ||
{ | ||
this.contracts = contracts; | ||
|
||
typeRef = new(contracts); | ||
} | ||
private readonly TypeRefFactory typeRef = new(contracts); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arguably this should not be changed to a primary constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree with Łukasz here. This should not be a primary ctor IMO.
But as with everything recently when it comes to syntax, I don't hate it also. ^^'
ec3e2a9
to
136568f
Compare
return type.GetCustomAttributes<AuthorizeWhenAttribute>().Select(AuthorizerDefinition.Create).ToList(); | ||
} | ||
public static List<AuthorizerDefinition> GetCustomAuthorizers(Type type) => | ||
[.. type.GetCustomAttributes<AuthorizeWhenAttribute>().Select(AuthorizerDefinition.Create)]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have somewhat mixed feelings about the [.. X.Select(Y)]
- this mixes both the spread operator and LINQ and I don't really know what to think about it. [.. X]
is great, but I don't know if the ~4 chars are worth using instead of X.Select(Y).ToList()
.
But I don't hate it also. So basically indifferent. ^^'
public class ContractsGenerator(CompiledContracts contracts) | ||
{ | ||
private readonly CompiledContracts contracts; | ||
private readonly CompiledContracts contracts = contracts; | ||
|
||
private readonly TypeRefFactory typeRef; | ||
|
||
public ContractsGenerator(CompiledContracts contracts) | ||
{ | ||
this.contracts = contracts; | ||
|
||
typeRef = new(contracts); | ||
} | ||
private readonly TypeRefFactory typeRef = new(contracts); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree with Łukasz here. This should not be a primary ctor IMO.
But as with everything recently when it comes to syntax, I don't hate it also. ^^'
136568f
to
ce2e5d0
Compare
Lots of more or less stupid changes to make the .NET analyzers happy. I know some of them might be controversial so feel free to fight me where appropriate 🥊