In C#6, we will (most likely) have the nameof operator, a very useful operator for the ArgumentNullException pattern:
public void M(T x) {
if (x == null) {
throw new ArgumentNullException("x"); // change "x" to nameof(x)
}
}
However, C#6 is not yet released, and code using nameof won’t be compiled by the stable versions of the compiler.
The nameof is only an example, where the difference in readability is very tiny. This question is not only about this case, but the general case.
Is it worth (or at which point of improvement is it worth) signaling on the code that piece of code could be changed to be better (more readable/better performance/any other metric) in a future version of the language/compiler? What kind of signal is better at this job (just a comment, a TODO comment, an issue in the project management, etc)?
1
Beware of uncertainty. A given feature may be released or not: it may be postponed, or simply dropped. Also, migrating to the new version of a language and framework is not an easy task. For instance, in Microsoft’s community, this sometimes requires a new version of Visual Studio, which may have a very substantial cost for a company.
If you still want to signal a possible improvement, think about what you’ll do when the new version of the language is released. Would you:
-
Walk through the whole code base and modify the thing everywhere you can?
-
Or do nothing and wait until you maintain a specific piece of code to use the new language feature?
In the first case, a TODO comment or a ticket looks appropriate, but you may also consider doing nothing, since you’ll be browsing the whole code base anyway.
In the second case, put a simple comment for the maintainers.
1