For private fields that are either primitive type or string, we can simply change these to const with no ill effects (which can be its own PR).
For internal/public/protected fields, generally the answer is yes, we should change these. However, changing to const means compiling the value into a consuming assemblies' metadata, so we need to be judicious on how to deal with these.
If the value will certainly never change, we can change to const.
If the value is likely to change, we should leave as static readonly.
All other cases need to be considered carefully.
For example, we need to consider the implications of what will happen if someone uses an older version of one of the modules, such as Lucene.Net.Analysis.Common with a newer version of Lucene.Net that has updates to these constant values. If there is any doubt, these should be static readonly.
Do note that making this change may result in compile errors which means we need to either revert the change or apply a fix, if appropriate.
NOTE: In Java, there is only one option, static final, so this is a .NET-specific translation problem and there is no need to add a // LUCENENET comment for it.
For private fields that are either primitive type or string, we can simply change these to const with no ill effects (which can be its own PR).
For internal/public/protected fields, generally the answer is yes, we should change these. However, changing to const means compiling the value into a consuming assemblies' metadata, so we need to be judicious on how to deal with these.
const
.static readonly
.For example, we need to consider the implications of what will happen if someone uses an older version of one of the modules, such as
Lucene.Net.Analysis.Common
with a newer version ofLucene.Net
that has updates to these constant values. If there is any doubt, these should bestatic readonly
.Do note that making this change may result in compile errors which means we need to either revert the change or apply a fix, if appropriate.