c# – 在Lambda语法中绕过int.TryParse的else块

假设我有一个字符串数组,它可能包含一些可以解析为整数的数据.

string[] strnums = { "2","3","hello","5","6","8" };

我试图使用LINQ Select方法将此字符串数组转换为整数数组,如下所示： –

int[] numbers = strnums.Select(x =>
                {
                    int temp = 0;
                    return int.TryParse(x,out temp) ? temp : 0;
                }).ToArray();

输出：2,3,5,6,8 //这里不要0

在这里,在int.TryParse的else块中我必须给出一个默认值(0),但我不需要这个,这就是为什么我把我的问题命名为“By-Pass”else部分.

我已经使用了这个查询,这工作正常,意味着如果没有解析字符串,它不会插入不必要的零： –

int[] numbers1 = strnums.Select(x => 
                {
                    int temp = 0;
                    bool isParsed = int.TryParse(x,out temp);
                    return new { temp,isParsed };
                })
                .Where(x => x.isParsed)
                .Select(x => x.temp)
                .ToArray();

但是,这似乎是很多代码,只是为了不考虑默认值,我正在预测,过滤和再次投影.这是正确的方法吗？

解决方法

我会说你的第二个例子不仅仅是解决问题的方法.

与其他答案不同,它实际上明确表示您只需要可以解析的值.所有其他解决方案虽然聪明,但却混淆了这一事实.我发现第二个例子是一个更好的解决方案的主要原因是isParsed字段,特别是当与.Where(x => x.isParsed)结合使用时.这就是显而易见的是,您只需要成功解析的值.任何第一次阅读代码的人都会立即想到“只获得被解析的值”.此外,代码中没有歧义.

另外,我不同意第二个例子是坏的,因为它更长.您应该更多地关注代码的自我描述,而不是更短的代码.这是新开发人员得到的错误想法之一.他们认为,如果他们能够生成更短的代码,他们是更好的开发人员,那么他们就是更好的开发人员.虽然代码高尔夫是有趣的学科,但大多数人不希望在生产环境中看到这样的代码.