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

NO MERGE - code quality analysis spike #463

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

stephenfuqua
Copy link
Contributor

@stephenfuqua stephenfuqua commented Jul 7, 2022

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 that IdentityContext 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.

@stephenfuqua stephenfuqua marked this pull request as draft July 7, 2022 16:01
@@ -123,3 +121,7 @@ environment.json

# Sandbox Admin
/**/SandboxAdminLog*

# Log output
*.sarif
Copy link
Contributor Author

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;
Copy link
Contributor Author

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}");
Copy link
Contributor Author

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));
Copy link
Contributor Author

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.

Copy link
Contributor

@gmcelhanon gmcelhanon Jul 9, 2022

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 the GetClients 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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

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.

// 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)
Copy link
Contributor Author

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
Copy link
Contributor Author

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))
Copy link
Contributor Author

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)
Copy link
Contributor Author

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.

Copy link
Contributor

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"?

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants