-
Notifications
You must be signed in to change notification settings - Fork 70
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
Library compatibility - Keep revision 1 as default #100
Comments
Hi @roberto-guerzoni, this will cause breaking changes. Thank you! |
Hi Rickedb,
|
Hi Rickedb,
|
@roberto-guerzoni However, the second one doesn't seems to make much sense, why |
I worried about this warning
*Code Inspection: Possible multiple enumeration of IEnumerable*
Last modified: 08 March 2021
You can suppress this inspection to ignore specific issues, change its
severity level to make the issues less or more noticeable, or disable it
altogether.
Consider the following code snippet:
IEnumerable<string> names = GetNames();
foreach (var name in names)
Console.WriteLine("Found " + name);
var allNames = new StringBuilder();
foreach (var name in names)
allNames.Append(name + " ");
Assuming that GetNames() returns an IEnumerable<string>, we are,
effectively, doing extra work by enumerating this collection twice in the
two foreach statements.
It could get even worse if GetNames() results in a database query, in which
case you could end up getting different values in both foreach loops if
some other process changes the database between the two calls.
This kind of problem can be easily fixed — force the enumeration at the
point of variable initialization by converting the sequence to an array or
a list, for example:
List<string> names = GetNames().ToList();
The rest of your code can stay the same, because both array and list types
implement the IEnumerable interface.
False positives
Sometimes, this inspection may render false positives if the IEnumerable
object is passed to some method before being enumerated. For example:
public void Foo(IEnumerable<string> values)
{
ThrowIfNull(values, nameof(values));
var x = values.ToList(); // Possible multiple enumeration of IEnumerable
}
public static void ThrowIfNull<T>(T value, string name) where T : class
{
// custom check for null but no enumeration
}
In this case, ReSharper presumes that the method will do additional
enumeration, which is true in most cases. If the method doesn't actually
enumerate the IEnumerable object, you can mark the corresponding parameter
with the [NoEnumerationAttribute] to prevent the false positive:
public void Foo(IEnumerable<string> values)
{
ThrowIfNull(values, nameof(values));
var x = values.ToList(); // No warnings about multiple enumeration
}
public static void ThrowIfNull<T>([NoEnumeration] T value, string name)
where T : class
{
// custom check for null but no enumeration
}
Il giorno dom 14 mag 2023 alle ore 05:54 Henrique Dal Bello <
***@***.***> ha scritto:
… Hi Rickedb, Could you consider this improvements?
Mid.cs
protected virtual void ProcessDataFields(string package)
{
if (!RevisionsByFields.Any())
return;
int revision = Header.Revision > 0 ? Header.Revision : 1;
for (int i = 1; i <= revision; i++)
{
if (RevisionsByFields.TryGetValue(i, out var field))
{
ProcessDataFields(field, package);
}
}
}
MidInterpreterMessagesExtensions.cs
public static MidInterpreter UseAllMessages(this MidInterpreter midInterpreter, IEnumerable<Type> mids)
{
var enumerable = mids.ToList();
if (enumerable.Any(x => !x.IsSubclassOf(typeof(Mid))))
throw new ArgumentException("All mids must inherit Mid class", nameof(mids));
return midInterpreter
.UseAlarmMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IAlarm))))
.UseApplicationControllerMessage(enumerable.Where(x => DoesImplementInterface(x, typeof(IApplicationController))))
.UseApplicationSelectorMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IApplicationSelector))))
.UseApplicationToolLocationSystemMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IApplicationToolLocationSystem))))
.UseAutomaticManualModeMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IAutomaticManualMode))))
.UseCommunicationMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(ICommunication))))
.UseIOInterfaceMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IIOInterface))))
.UseJobMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IJob))))
.UseAdvancedJobMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IAdvancedJob))))
.UseLinkCommunicationMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(ILinkCommunication))))
.UseMotorTuningMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IMotorTuning))))
.UseMultipleIdentifiersMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IMultipleIdentifier))))
.UseMultiSpindleMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IMultiSpindle))))
.UseOpenProtocolCommandsDisabledMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IOpenProtocolCommandsDisabled))))
.UseParameterSetMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IParameterSet))))
.UsePLCUserDataMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IPLCUserData))))
.UsePowerMACSMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IPowerMACS))))
.UseResultMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IResult))))
.UseStatisticMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IStatistic))))
.UseTighteningMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(ITightening))))
.UseTimeMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(ITime))))
.UseToolMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(ITool))))
.UseUserInterfaceMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(IUserInterface))))
.UseVinMessages(enumerable.Where(x => DoesImplementInterface(x, typeof(Vin.IVin))));
}
@roberto-guerzoni <https://github.com/roberto-guerzoni>
First one is fine, we save some operations.
However, the second one doesn't seems to make much sense, why .ToList()
and using Linq over IEnumerable<> if the parameter is already an
IEnumerable<>?
—
Reply to this email directly, view it on GitHub
<#100 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACT7RNHLC3N7WOETIJRAYC3XGBJPHANCNFSM6AAAAAAW6SEUDM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes, that is true, if your However, by doing this I'm forcing to materialize everything, also your operation at database, which, sometimes might lead to a problem too and we will just switch problems, and this behaviour would be forced without user`s acknowledgement. Another possible option is to use |
Good evening,
I always follow this project with pleasure and I noticed that in the latest release some mids have been updated. In order not to lose compatibility with the previous version, I think it's better not to always create the mid with the latest release, better to create it with the minor release and let the developer upgrade the release when needed.
The text was updated successfully, but these errors were encountered: