-
Notifications
You must be signed in to change notification settings - Fork 33
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
NO MERGE - code quality analysis spike #463
base: main
Are you sure you want to change the base?
Conversation
@@ -123,3 +121,7 @@ environment.json | |||
|
|||
# Sandbox Admin | |||
/**/SandboxAdminLog* | |||
|
|||
# Log output | |||
*.sarif |
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.
Sarif is a type of log file for reporting on things like build errors. GitHub's CodeQL analyzer can read these sarif files and incorporate the results into the build process.
@@ -64,7 +64,7 @@ public async Task<ActionResult> Create(CreateLoginModel model) | |||
} | |||
|
|||
// Failed Model Validation | |||
Response.StatusCode = (int)HttpStatusCode.BadRequest; | |||
Response.StatusCode = (int) HttpStatusCode.BadRequest; |
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.
We have a mix of the two styles in our code base, and I had to choose one to enforce. Personally, I don't have a strong feeling about this, and I selected Microsoft's default option.
|
||
while (currentException != null) | ||
{ | ||
Trace.TraceError("{0}: {1}", currentException.Message, currentException.StackTrace); | ||
message += string.Format("{0}:{1}", counter, currentException.Message); | ||
message.AppendLine($"{counter}:{currentException.Message}"); |
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.
This is one of the code smells detected by the SonarSource analyzer. Arguably I should have kept it consistent with Append
instead of AppendLine
- but if this unhandled exception ever occurs, it will be easier to interpret the concatenated messages if there are linebreaks.
counter++; | ||
currentException = currentException.InnerException; | ||
} | ||
|
||
throw new Exception(string.Format("Unhandled exception with these messages: {0}", message)); | ||
// This is not an ideal exception type, but it is better than a plain Exception | ||
throw new InvalidOperationException(string.Format("Unhandled exception with these messages: {0}", message)); |
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.
Open to suggestions - including the suggestion that we eschew Microsoft's advice, and accept throwing Exception. In fact, our current C# best practices only suggest not throwing Exception
. We discussed that in detail 2-3 years ago and came to that conclusion. So on further reflection, I'll leave this here for discussion, but I'm inclined to globally downgrade the warning not to throw Exception
to a mere Suggestion instead of Warning.
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.
This is where I disagree with the advice, and we've had this discussion previously, but to recap my opinion on this -- I feel that there are only 2 times when a specifically typed exception should be thrown in an application (as opposed to a reusable library/framework):
- When there is an existing exception that matches perfectly as documented.
InvalidOperationException
is documented as "the exception that is thrown when a method call is invalid for the object's current state.". That doesn't fit here. There is nothing about the state of the controller that impacted the ability to invoke theGetClients
method (controllers don't even have state, generally). - When there is a need to attach definitive semantics to an exception so that it can be handled in a particular way elsewhere in the system (e.g. to be able to make a decision on which status code to return in the HTTP response). In most cases this is not needed (a 500 status is perfect) and the addition of new custom exception types for each occurrence is an onerous development and maintenance requirement, while an arbitrary usage of a different type of the exception than
Exception
is pointless and equally lacking in semantic meaning.
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 actually agree with that position, though I had to jog my memory on those details by actually working through the example.
The only reason I would consider leaving this as a Suggestion (which, to be honest, might not ever be noticed) rather than completely disabling the advice is to help prompt people to think about whether or not there is an existing appropriate exception.
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.
Latest commit restores the original code and tweaks the editorconfig so that this issue is only a suggestion.
@@ -10,7 +10,9 @@ | |||
|
|||
namespace EdFi.Ods.SandboxAdmin.Controllers.Api | |||
{ | |||
#pragma warning disable S101 // Types should be named in PascalCase, however, uppercase is preferred for acronyms such as "DTO" |
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.
We may be able to go a step further and recognize DTO as legitimate. https://docs.microsoft.com/en-us/visualstudio/code-quality/how-to-customize-the-code-analysis-dictionary?view=vs-2022
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.
Personally, I dislike the "DTO" suffix entirely. I generally find it to be an unnecessary addition to the name.
Application/EdFi.Ods.SandboxAdmin/Models/Results/AdminActionResult.cs
Outdated
Show resolved
Hide resolved
// Change the recurrence to suit your needs using Cron functions or a unix CRON expressions (i.e. "* */6 * * *" = every 6 hours) | ||
RecurringJob.AddOrUpdate("RebuildSandboxes", () => _engine.RebuildSandboxes(), Cron.Daily(), TimeZoneInfo.Local); | ||
} | ||
// Change the recurrence to suit your needs using Cron functions or a unix CRON expressions (i.e. "* */6 * * *" = every 6 hours) |
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.
This is another case where the SonarSource analyzer suggested turning the loop into a Linq statement. And in this case, I agree. However, I rewrote in a better style than the linter gave me originally. And I haven't tested this or even checked to see if there are unit tests - because this is just a spike.
If there aren't unit tests already, or if mocking RecurringJob.AddOrUpdate
is difficult, then we might just leave this existing code alone. It might not be worth the effort to test it.
// The Ed-Fi Alliance licenses this file to you under the Apache License, Version 2.0. | ||
// See the LICENSE and NOTICES files in the project root for more information. | ||
|
||
namespace EdFi.Ods.Sandbox.Admin.Services |
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.
Another missing header corrected!
@@ -48,12 +48,10 @@ public async Task<PasswordResetResult> ValidateRequest(string userEmail, string | |||
return PasswordResetResult.BadUsername; | |||
} | |||
|
|||
if (!await _identityProvider.VerifyUserEmailConfirmed(userEmail)) | |||
if (!await _identityProvider.VerifyUserEmailConfirmed(userEmail) | |||
&& !await _identityProvider.VerifyUserPassword(userEmail, secret)) |
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.
Code smell recommendation: unify the if statements. I agreed with that and applied this fix manually. This is not covered by dotnet format
.
@@ -72,9 +72,9 @@ public async Task<CreateLoginResult> Create(CreateLoginModel model) | |||
.AddFailingField(x => x.Email); | |||
} | |||
|
|||
public async Task<bool> Login(string userEmail, string password, bool isPersistent = false) | |||
public async Task<bool> Login(string userName, string password, bool isPersistent) |
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.
Another example of matching signature matching, in this case to an interface. I hesitated about the default value for isPersistent
. No build failures though, so I let it go through. But it would need to be tested. If we really did need a version that defaults to isPersistent
, I would prefer to see that done with a separate method that only has the two arguments and then delegates to this method. That way we have a signature that perfectly matches the interface.
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.
Agree with the default arguments...
One semi-related question though... is the concept for that first argument best represented as "user name" or "username"?
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.
Good question, one I didn't put thought into because I wasn't going to change the signature in at the interface level in this POC.
@@ -1,4 +1,4 @@ | |||
// SPDX-License-Identifier: Apache-2.0 | |||
// SPDX-License-Identifier: Apache-2.0 |
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.
Why are all these headers getting tweaked?
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.
Because the original had a BOM, and dotnet format
removed it.
# Lower the priority | ||
dotnet_diagnostic.S4136.severity=suggestion # Method overloads should be grouped together | ||
dotnet_diagnostic.S1135.severity=suggestion # Complete TODO comments | ||
dotnet_diagnostic.S112.severity=suggestion # 'System.Exception' should not be thrown by user code. |
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.
Lowered this from Warning to Suggestion
In this spike, I have added two code analyzers to the "Entry Point" projects: Microsoft's standard C# analyzer, and the SonarSource analyzer. The spike introduces an
editorconfig
file with substantial rule customization. This customization is based on the actual code practices in Analytics Middle Tier and here in these three projects updated projects.Most of the "little" fixes were applied automatically by running
dotnet format
in the three projects. Some of the files only show a change at the top of the file - because a byte order mark was removed. I have confirmed thatIdentityContext
previously had a BOM and the format command removed it. Another small change is an extra line at the end of the file. This is a standard convention in the Unix-like world; its absence can impact the ability to open or display the file properly in some tools.