4 ms·
I'm currently involved at work with migrating a legacy C# code base to nullable reference types. One thing I'd really like is the explicit marker for non-nullab
by ygra 2y ago
I'm currently involved at work with migrating a legacy C# code base to nullable reference types. One thing I'd really like is the explicit marker for non-nullable since it makes it explicit which parts of the code have already been looked at and annotated. For time reasons we've opted to just enable the annotations for now except in a few core places. But we still retain the JetBrains NotNullAttribute and CanBeNullAttribute as markers for now to immediately see where we've made a conscious decision (granted, the latter can be removed since nullable has an explicit marker, but the former has a name conflict with C#'s own feature).
So in that sense having the three options would be quite desirable. Especially since a few hundred thousand lines of code aren't that quick or easy to migrate.
In another internal project we've been doing this in a different way by sprinkling #nullable enable around the code where we touch it and thus gradually improve nullability coverage (and keep in mind that new code must be in a nullable context). This works as well to make it explicit what is annotated already, but it's a much smaller codebase and team.
- Deukhoofd 2y agoWhat we did was to turn on nullability as warnings everywhere. We then went through them project by project, and fixed them. After we were done with a project, we'd turn on WarningsAsErrors for nullable warnings, and know the project didn't need additional fixes any more.
- ygra 2y agoWould have loved to do the same and that's my plan eventually, too. Alas, no time for fixing right now. And as I've already noticed when migrating from JS to TS or non-strict TS to strict TS, there's a whole lot of issues that require thought and investigation whether everything is fine from a nullable perspective. I have found quite a few issues, even outright bugs, but when there are more pressing issues than a few lingering NullReferenceExceptions that no customer has stumbled over in the past decade, then those get prioritized. At least new code is forced to deal with those warnings for now, which is much easier than fixing legacy code.