• (nodebb)

    LINQ -- Language Integrated Natural Query.....

    ar results = from c in SomeCollection where c.SomeProperty < 10 select new {c.SomeProperty, c.OtherProperty};

    What was shown is "Fluent Syntax" or "Method Chaining"....

    Unfortunately (for many reasons) this distinction has gotten lost.

  • (author) in reply to TheCPUWizard

    I mean, LINQ is a collection of extension methods, like Select. Languages may then add their own query language on top of it, which is also called LINQ, but that language must compile down into invocations of the LINQ methods. So you can kinda see why the distinction gets fuzzy.

  • akozakie (unregistered)

    I have to oppose the ERV. It's not exactly true that "clever code is bad" - it usually is, unless it's exactly what's needed.

    The best analogy for being a great programmer is being a great airline pilot. Both are getting paid for three things:

    1. being very good at always following best practices in routine work,
    2. being capable of VERY advanced and clever tricks when a need arises,
    3. being well aware that such a need arises so rarely, that you may never find yourself in such a situation in your entire career (especially if you take point 1 very seriously) - and being ok with that.

    You are expected to hone your skills in point 2 in training and in your free time (simulator and acrobatics vs hobby projects), while focusing on point 1 at work. Point 2 becomes important in very extraordinary situations - in programming that would be either extreme technical limitations (you have to fit all this in 4k memory, you have to make it run under 1ms on this hardware regardless of circumstances, etc. - analogue of flying a damaged plane) or organizational ones (patching a critical bug in a badly designed legacy system where doing it right would require a major rewrite with no budget - analogue of dealing with something like a wrong weather report, being surprised by a volcanic cloud, etc).

    The only real difference is that the rules and best practices are not written in avoidable blood, but in avoidable overtime.

  • (nodebb) in reply to akozakie

    The only real difference is that the rules and best practices are not written in avoidable blood, but in avoidable overtime.

    Tell that to the three folks who paid the Big Price for the faults in the Therac-25, or the folks in those two 737-MAXes.

  • MiserableOldGit (unregistered) in reply to Steve_The_Cynic

    Hadn't heard of the Therac-25 incident, that made for an interesting (and very familiar) read. Thanks.

  • (nodebb) in reply to TheCPUWizard

    To be specific, it is the fluent syntax of LINQ. Calling LINQ methods is using LINQ, regardless of whether it is done through the fluent (or method) syntax or through the query syntax.

    https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/query-syntax-and-method-syntax-in-linq

    Also, fluent syntax and method chaining are not terms that are specific to LINQ. LINQ is just one example (or collection of examples) of these techniques.

  • akozakie (unregistered) in reply to Steve_The_Cynic

    Yeah, well, it should have been "are usually paid".

  • Local (unregistered)

    What would be better than the original way??

  • NotAThingThatHappens (unregistered)

    Only change needed is

    Select(item => item.ToInt32()).ToArray();

  • LotsOfWays (unregistered) in reply to Local

    var ids = new List<int> {id}; ids.AddRange( Request.FormOrQuerystring("ids").EnsureNotNull().Split(",").Select(item => item.ToInt32())); Just breaking it into two statements makes it easy to see where the default is coming from, instead of having to hunt through a mountain of linq.

  • (nodebb)

    I'm not really understanding which part of this code is a WTF, other than the fact that "id" is always concatenated with the list of "ids", meaning that one of them needs to be either "special" or duplicated. As for @NotAThingThatHappens comment, I believe that this modification would make it less efficient, as it would need to construct 3 arrays, rather than use an iterator to build a single array containing the list of "ids", and the "id"

    Addendum 2020-11-15 21:07: Looking at it again, the fact that the resultant array is named ids, which collides with the query or form parameter, which may be confusing for the maintenance programmer. Otherwise, I'd rather look at this than a bunch of if() statements testing for each separate case. In terms of performance, I doubt that the overhead of creating an array will make much of a difference. The iterator allocation underlying LINQ to objects (or foreach for that matter) is similar.

  • LotsOfWays (unregistered)

    TRWTF is that there is a single REST endpoint, implemented with a single method, which accepts any combination of resource identifier in URL (/resource/38) or comma separated ids (/resource?ids=23,44,44). The equivalence of the following two requests, and their fulfillment by the same endpoint, is a monstrosity: /resource/38?ids=22,33 /resource?ids=38,22,33 etc There is one small difference, perhaps, that the way its currently implemented the id in URL might always be the last item returned. That is not a feature.

  • (nodebb)

    The real WTF is the C# API which explicitly joins together multiple values into a single comma-separated string instead of letting you read it as an array.

Leave a comment on “The Default Value”

Log In or post as a guest

Replying to comment #:

« Return to Article