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

Update C# language version used for console and engine #1479

Closed
CharliePoole opened this issue Sep 14, 2024 · 4 comments · Fixed by #1484
Closed

Update C# language version used for console and engine #1479

CharliePoole opened this issue Sep 14, 2024 · 4 comments · Fixed by #1484
Assignees
Labels
Milestone

Comments

@CharliePoole
Copy link
Collaborator

NUnit Framework uses C#11 while the engine and console use C# 7. That's too great a difference and is confusing for developers. Ideally we would also use C#11.

The first step in this change will be to determine whether to make this change in one jump or in stages. If possible, I'd like to upgrade the language version alone, without making immediate use of the new features in existing code. We will also need coding standards to indicate whether certain features are used in production code.

Given the above, it's likely that multiple PRs will be needed for this issue.

@CharliePoole CharliePoole added this to the 3.18.2 milestone Sep 14, 2024
@CharliePoole CharliePoole self-assigned this Sep 14, 2024
@manfred-brands
Copy link
Member

@CharliePoole I was always told that coding guidelines for NUnit are per repository.

Just increasing the level doesn't change any code. Most features we can use since we still target .net framework are limited to syntactic sugar.

Main thing to enable would be nullability as that can find hidden null references.

@CharliePoole
Copy link
Collaborator Author

@manfred-brands Yes, I was meaning the coding guidelines to be for the nunit-console repository. Of course, if anyone is going to work in both repos, it will be better if the language level is the same.

I know that changing the level isn't supposed to change the code that's generated, but I'm a cantankerous old TDD guy so I'll run the tests first. I do think the existing test set is large enough that it will probably catch anything bad. I probably won't actually do multiple PRs for that part alone, although I might be more incremental locally just to see what happens.

I agree about the importance of nullability. I know it wasn't quick to implement in the framework and I suspect that will also be true of the engine. In both cases, we often used null values to mean something, which is not considered good form these days, but then NUnit is pretty old. Full implementation might change some APIs, which means V4, of course.

@CharliePoole
Copy link
Collaborator Author

@manfred-brands Well that was pretty easy. It actually does just work! :-)

@CharliePoole
Copy link
Collaborator Author

This issue has been resolved in version 3.18.2

The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org

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

Successfully merging a pull request may close this issue.

2 participants