Can you give examples? I'm not sold that the "low hanging fruit" of readability improvement (empty lines to break up "paragraphs", breaking up unintelligible one-liners into several lines, etc.) degrades performance. My intuition is that the compiler/interpreter ends up producing almost identical runtime code and therefore similar performance.

Unless you mean more along the lines of expressivity (i.e Python and Ruby can get a lot done with fewer statements compared to C), but to me this effect is in a different category than readability.

    foreach (var item in items) {
        if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) {
            item.Duplicate = true;
        }
    }

Note that this was conceived in just a few minutes of reading your code, deciphering syntax only remotely familiar, and figuring out what was it supposed to do, all with cold start (I haven't written much today yet). Something went wrong with your thought process.

    if (items.Count(item2 => item.Upc == item2.Upc) != 1)

    var set = new HashSet<string>();
    foreach (var item in items) {
        if (set.Contains(item.Upc)) {
            item.Duplicate = true;
        } else {
            set.Add(item.Upc);
        }
    }

For a final comparison, here's an implementation of the extra loops and manual indexing I suggested:

    for (var i = 0; i < items.Count; i++) {
        for (var j = i + 1; j < items.Count; j++) {
            if (items[i].Upc != items[j].Upc) continue;
            items[i].Duplicate = true;
            items[j].Duplicate = true;
            break;
        }
    }

In conclusion, while I appreciate your suggestion for a possible alternative implementation, I do not appreciate your impugning of my abilities with the suggestion that "something went wrong with your thought process", and implying that I may not be aware of basic data structures.

Not to menion that:

> you suggest 'a. k. a. "dictionaries"' but that is slower

In what way you think mappings are different in implementation than sets that makes them slower? They only need to carry one more pointer, and you're already writing in a language quite detached from bare metal.

One more thing, since you decided to "correct" yourself instead of letting the mistake slip: your "working" code is still wrong, unless something very weird happens in the data (but then calling it more readable this way is fundamentally wrong).

O(n^2) I do not dispute. "Landmines," however, I take offense at: my naive implementation can still check 10,000 items in less than three seconds; should this ever become a bottleneck I assure you that I will adjust the implementation accordingly. Considering that hitting this number would require expanding the entire company at least tenfold, and knowing how other portions of the code work, I feel justified in saying that this is likely to be the least of their problems.

> you're now justifying them by linecount and readability (actually more like familiarity with using sets and mappings).

The entire point of this thread was justifying by readability, so yes, I am. I'm well familiar with sets and mappings, I just don't think that they're the best solution for this particular task.

> In what way you think mappings are different in implementation than sets that makes them slower?

I don't know the internal implementation details, but having just benchmarked it I can tell you that Dictionary<string, Item> is roughly 8% slower than HashSet<string> for two otherwise identical implementations of this method.

> You have just proved my intuition about your abilities.

Likewise. From the preceding conversation, I conclude that you are inclined to prematurely optimize at the cost of maintainability and that you tend to look down on and make fun of anyone who you believe knows less about a topic than you, without taking the time to consider their point of view, or even basic politeness. You may not think that this description accurately depicts you; but then I don't think your opinion of me seems to be correct either.

Considering that I have now spent far more time than this code will ever run for arguing the point, I'm going to step away from this discussion now. I feel that I have made my point; increasingly heated argument seems unlikely to affect the outcome of the debate.

If you're satisfied that the loop you presented runs for a time comparable with three seconds for merely 10000 elements, it says plenty enough about your craft.

> [...] I can tell you that Dictionary<string, Item> is roughly 8% slower than HashSet<string> for two otherwise identical implementations of this method.

Ah yes, benchmark comparing non-implementation (abstract class) with an implementation (concrete class).

> From the preceding conversation, I conclude that you are inclined to prematurely optimize at the cost of maintainability

No. I just tend not to leave behind ridiculous algorithms, especially when an acceptably efficient solution is of comparable code complexity.

> [...] You may not think that this description accurately depicts you; but then I don't think your opinion of me seems to be correct either.

Parts of it, yes, they do match. I'm an asshole that laughs openly whenever sees statements that look ridiculous made by somebody who considers themselves an expert (note that it doesn't matter whether they are or are not actually an expert). But then, it's not my code that takes three seconds to walk through ten thousands elements when -- as napkin calculations show -- it should take under a millisecond.

Incorrect. Most practices like meaningful variable names, logically separated functions and classes, comments where appropriate, etc have absolutely no impact on performance. Principles like DRY and KISS and YAGNI typically also lead to better performance. Only in rare isolated cases might there be a conflict, eg. where a more cryptic algorithm have better performance than the straightforward.

The right way is to write modular code, where each class/function has simple and clear responsibilities. In that kind of code, changes are usually isolated and clear.