Hot answers tagged

10

English language These are relatively minor issues, but fixing them might help other people to use / maintain your code. The verb corresponding to permutation is permute. I'm pretty sure that reminder is intended as remainder. Code public static IEnumerable<T[]> Permutate<T>(this IEnumerable<T> source) { return permutate(...


7

Exit early Instead of stuffing everything in one return statements, return as early as possible. if (!projects.Any()) return Enumerable.Empty<string>(); can be the first statement of your method. It saves recreating the hashset objects and it makes the flow of your method with its recursion more clear. I think sacrificing a bit of "conciseness" for ...


6

public static TSource ArgBy<TSource, TKey>( MinBy and MaxBy are very intelligible names, but ArgBy doesn't say much to me. Really this is a specialised Aggregate (and I wonder whether an implementation using Aggregate might be simpler - or, indeed, whether the existence of Aggregate makes ArgBy unnecessary). Func<(TKey Current, TKey ...


6

Using line breaks and {} in code is not a crime :-P Only because we have the nice => doesn't mean we have to use it everywhere. The code is so condensed that it's hard to say where anything begins and ends. I find you should first try to write this function in such a way that it is easy to read and one can see what and where could be optimized. So, I ...


5

var result = new List<ScrapCategory>(); ... if (!result.Contains(parent)) There's one performance problem. Use a data structure which gives fast Contains checks: typically HashSet<>. var parent = categories.Where(x => x.Id == parentId)?.First(); There's another one. I assume that IDs are unique, in which ...


5

where TValue : IComparable<TValue> Don't do this. OrderBy doesn't require its type parameters to implement this interface like this either. Instead it uses the IComparer<T> interface. What's the difference? With IComparable<T>, the implementation of the comparison logic is sitting on the class T itself. This means that there is one and ...


4

You did also ask for a shortened version. I believe readability should not be a concern here (meaning the code should aim at being functional, not readable). Remove the local recursive function and allow the public API to have an optional parameter. public static IEnumerable<T[]> Permutate<T>( this IEnumerable<T> source, IEnumerable<...


4

First, you're going through the list of items to find all distinct children. Then, for each child, you're going through the list again to find all items that it belongs to, and then you take the lowest item ID. That's \$O(n^2)\$ in worst-case scenarios, though in practice it'll be closer to \$O(n)\$ if you don't have too many distinct children. A more ...


4

Indeed, you could use GroupBy but I think it's easier to solve with the query syntax because we also need the item from the first list to sort by its Id. Without it, we would need to do additional lookups like you do. var result = from item in items // from + from = SelectMany from child in item.Children orderby item.Id // sort in ascending ...


3

I think in general MinBy and MaxBy are useful but handling all the null cases might be tricky, and indeed it is seeing the repeated logic and two similar loops. For this reason I also think that it'd be easier if we do not handle them at all but let the user decide what he wants to do with them and implement both simply with OrderBy(Descending).First() ...


3

It might be boring to hear it again, but I have to ask :) Why do you think your application need performance optimisations? Is your bottle neck in these parts of code which you provided? Maybe problem is with database/external service/network? Have you measured processing and communication time? Stopwatch Do you have some kind of monitoring of application, ...


3

Scope If all you need is to calculate some values from a set of data tables, it would suffice to use LINQ. However, if you prefer to provide an API with common functionality concerning orders and order details, you should really create your own domain classes and map the data tables to your domain classes. For the sake of this question, I would opt for ...


3

A possibility is to store the parents as we go so we don't need to keep searching though the input array. We can use a dictionary to look up the parents by id. If we can guarantee that the ancestors for a category all appear in the array before the category then we can do this in one pass. Reading through the array we add each category to the dictionary, ...


2

An updated version, please see an accepted answer for details. public static IEnumerable<string> Permute(this string source) => source.AsEnumerable().Permute().Select(a => new string(a)); public static IEnumerable<T[]> Permute<T>(this IEnumerable<T> source) { return permute(source.ToArray(), Enumerable.Empty<T>())...


1

AggByA: baseline two-pass method presented by the OP. AggByB: one-pass method using Aggregate suggested by @PeterTaylor AggByC: one-pass method implemented by hand I left most error handling to the reader since I personally don't believe it is necessary, or even helpful, in something this abstracted. If the caller wants extra safety then they can easily add ...


Only top voted, non community-wiki answers of a minimum length are eligible