• Your Name (unregistered)

    TRWTF is nothing to do with Linq and functional programming (both terms presumably present to get those precious link clicks) and is the same roundabout inefficiencies present in about 60% of all CodeSOD articles. Next!

  • David Mårtensson (unregistered)

    But this all assumes that GetAllForClientNotRetrieved and Get returns the same type of object :D

    With code like this I would not be surprised if they return different types of object containing different amount and plain different data.

    So without further knowledge of the return types AND if both populate the objects completely its hard to tell if you really can replace them.

    I unfortunately have personal experience of such monstrosities but am currently not in a position to share any example :/

  • Ulysses (unregistered)

    I submitted a good WTF article ages ago, but flavorless crud like this continues to get posted. Sigh.

  • scragar (unregistered)

    It's very possible this sort of monstrosity got written to work around a memory issue, retrieving all of every document needs enough memory for all documents at all times(and given the usage of ToList on something that doesn't need it, I'm gonna say they were always loading the full dataset as a list rather than itterable), but handling them in a foreach has memory requirements at any given point of sizeof( * numDocuments + currentDocumentSize.

    Probably an issue that showed up at one point when someone added thousands of documents at once and the bad code mentioned was added in as a quick work around by developers who either didn't know better ways to avoid the issue or just hacked at it until it stopped breaking.

    No excuse for the code, but worth considering when it comes to the replacement.

  • ApoY2k (unregistered)

    I fucking hate "var" in .NET. What's the point in having a strongly typed language if I cant look at an assignment and know what type the variable has? Drives me nuts.

    Yes, IDEs know it, but that doesn't help me when reviewing PRs in Bitbucket!

  • tgutu (unregistered)


  • Your Name (unregistered) in reply to ApoY2k

    The point is... legibility, no? If you have var foo = baz.Stuff() and you can't figure out what foo is by looking at the words foo, baz, and Stuff, then you need to use better names for your variables and methods. Read this code and tell me you can't figure out what type retrieveDocIdList is.

    Moreover, why do you care what the specific type of a thing is, beyond how it is used? If you have var donald = myFavoriteAnimal(); donald.walk();, why do you care whether donald is a Duck or a Dog or some other legged entity? That is the whole point of abstraction in programming. (Surely donald's type only matters when you see donald.quack(), by which point you are sure that it is not a Dog.)

    Or are you complaining because is this more your style...?

    IAbstractFactoryProvider myIAbstractFactoryProvider = new AbstractFactoryProvider(AbstractFactoryProvider.FactoryProviderConstant);

  • ApoY2k (unregistered) in reply to Your Name

    I can't rationally explain why it bothers me. It feels wrong to not explicitly state what type I'm expecting to get from a method. I know it shouldn't matter and that this is more readable. But it just feels wrong to leave this information out.

    I tried using it a couple of times and it just didn't take. I want to see / explicitly state what type a variable is. It also forces you to make a concious decision what abstraction of the type you want (implementation, interface, root object,...).

  • Dr. λ the Binder of Variables and Applicator of Terms (unregistered)

    Functional programming is the best!

  • Dr. λ the Creator of Variables, Binder of Variables, Applicator of Terms and β-Reducer of Redexes (unregistered)

    And I deserve the best!

  • Your Name (unregistered) in reply to ApoY2k

    Well, there's a shoe for every foot, but be aware that pretty much every non-curly-brace language does not require you to specify the type of a variable when you assign it. I also see no benefit, cognitive or otherwise, in being forced to specify how specific the type of a value is, because only the exact type of the assigned expression matters - otherwise why give that type in the first place?

  • Zenith (unregistered) in reply to Your Name

    Just because you can't understand the benefit does not mean that it does not exist. ApoY2k's reasoning is perfectly valid - it forces the developer to make a conscious decision of what type to use (versus blind copypasta "development" that's all the rage) and helps somebody reading the code quickly pick up on the result even when the lazy slob that used var was also too lazy to name their variables/functions reasonably. Further, this is really indicative of the kind of write-only code that garbage developers pump out. When the barely-working code has to be revisited because a light breeze knocked it over, it's more difficult for everybody, even the garbage developer that wrote it (assuming they haven't yet moved on to the next disaster of their own making).

  • Just Another Developer (unregistered) in reply to ApoY2k

    I used to specify types when I declared variables until I started at my current position where the convention was to use var. I wasn't a huge fan of it when I started, but I've adapted and now I'm happy with either approach. With something like this it really is just preference and people will make valid arguments for and against it.

  • Your Name (unregistered) in reply to Zenith

    That's a very emotionally-charged response when I have already covered a lot of your objections to var in previous comments. Please consider where I said many (dare I say most) programming languages do not even have the facility to specify the type of a variable upon assignment.

  • me (unregistered)

    I think everyone agrees that var names = new List<string>(); is better than having to declare the type. For more complex cases the IDE will help. But for more complex cases when you are not using an IDE ApoY2k definitely has a point. So there's really no argument here.

  • My Name (unregistered)

    Indeed, when you are working with "garbage developers" writing poor code, var will not help. There is no language feature that will "help" in this way when you have adversarial colleagues.

  • Parametamolcil (unregistered) in reply to Zenith

    Thank God for Ada. If not for the bondage and discipline people would be assuming that they can just convert integers to floating point, or worse! Static typing is a good mistress.

  • foxyshadis (unregistered) in reply to scragar

    That's just the thing, LINQ doesn't retrieve "all of every document needs enough memory for all documents at all times" unless you bodge it in a completely brain-dead manner, like putting a ToList() on the end. If you can't work with generators, you really shouldn't be working with databases in any way. Seeing ToList() on the end of a query is an automatic red flag.

  • LCrawford (unregistered) in reply to foxyshadis

    This anti-pattern probably came about because someone did use ToList() when retrieving all documents. Or, alternatively it is patterned after a query that selects items from a linked list to delete - thus the necessity of 2 steps to prevent iterator invalidation while stepping through the linked list.

  • siciac (unregistered) in reply to Your Name

    The point is... legibility, no? ... Moreover, why do you care what the specific type of a thing is, beyond how it is used? I also see no benefit, cognitive or otherwise

    The only way someone could be that smug and dense is if you've never had to do code reviews for junior devs or other teams.

  • Your Name (unregistered) in reply to siciac

    Come on, you have to follow up an ad hominem like that with some explanation, otherwise you just come off as... well, smug and dense.

  • meelash (unregistered)

    Maybe they're using the list of ids for something else later on in the code?

  • (nodebb) in reply to LCrawford

    Why is it an antipattern? What if you need to reduce round-trips to the database for performance reasons?

  • Zenith (unregistered) in reply to Your Name

    Let me guess, you're a JavaScript or PHP "developer." Sorry, that doesn't wish away static typing in Pascal, Delphi, C, C++, Objective C, C#, VB, VB.NET, real Java, and others or is usefulness. Nor is handwaving away type declaration with "oh, if your devs name stuff right" even remotely responsible. You may as well remove seatbelts, locks, railings, and soap because nobody drives recklessly, steals, loses their balance, or dirties their hands. You're the worst type of developer, the type that never thinks anything through and leaves users and teammates to pick up the pieces.

  • Zenith (unregistered) in reply to siciac

    That fool probably never even looks at their own code a second time because they're always moving on and it's somebody else's problem now.

    Good Lord, there's not liking static typing and then there's pretending that it cannot ever have any purpose just because you, personally, cannot imagine it. Working with that kind of developer is painful. Everybody else has to turn their thinking inside out and pile dependency upon dependency to accommodate them and it's always a one-way street. I can practically guarantee that this idiot "needs" camelCasing or Lisp-style brackets for "readability" all while expecting everybody else to guess WTF type comes out of a function like LoadWtfs(xml becauseNeedful).

  • 52 (unregistered)

    I use var for all of the reasons "Your Name" says. If your problem with var is that your current editor/viewer of choice does not reveal the type and you cannot infer the type from the code, then switch to an editor that does. Don't get mad at the language because you are using the wrong tool to craft it.

  • David (unregistered)

    var in languages like C# or Scala has nothing to do with static typing; they're every bit as staticly typed as Java. The type is static; it's just not overtly stated in the code. It can prevent some bugs; "int x = foo (y)" works great until foo starts returning a float, which C will not mention. (gcc -Wall, at least versions in use a few years ago, won't even offer a warning.) Whereas "var x = foo (y)" is more likely to do the right thing, especially if you're treating x as a token.

    It has its upsides and its downsides. There are times when it makes it clearer to explicitly state the variable type, and there are times the variable's type is just noise, especially with something like Java's "new AutomaticDistillerToken()" syntax.

  • JTK (unregistered)

    The Real WTF is the .ForEach() method that got incorporated into LINQ.

Leave a comment on “Gotta Get 'Em All”

Log In or post as a guest

Replying to comment #:

« Return to Article