• Zatapatique (unregistered)

    Frist of all, this is not C#, but Java.

  • TheCPUWizard (unregistered)

    There is one subtle, but potentially possible details [remember it is possible to win both Powerball and MegaMillions every week for the rest of your life -- just unlikely)... If the map contains more than Integer.MAX_VALUE elements.....

  • Registered (unregistered) in reply to TheCPUWizard

    more than Integer.MAX_VALUE elements.....

    Can Java even create such a structure without having an unsigned Int type?

  • Maia Everett (github)

    It's a variant of Raymond Chen's for-if antipattern:

    https://devblogs.microsoft.com/oldnewthing/20111227-00/?p=8793

    The for-inc antipattern, anyone?

  • Jacob (unregistered)

    +1 for Sesame Street counting. Please make this a thing.

  • (nodebb)

    This C# function wants to get the number of items contained in a dictionary.

    This is not C#, it's Java lol

    Addendum 2024-04-25 07:41: A C# Method would look like this:

    public override int GetNumberOfItemsInDataContainer() => 
    _myTransactionDataContainer.Count;

    Addendum 2024-04-25 07:45: And doing it wrong would look like this:

    public override int GetNumberOfItemsInDataContainer(int parDataId)
{
  var numberOfItems = 0;
  
  foreach(var x in _myTransactionDataContainer)
    ++numberOfItems;

  return numberOfItems;
}

    So yeah, Java's lack of override (hence the hack with an annotation) and the weird foreach syntax are a pretty good tell ;-)

  • (nodebb)

    My hypothesis is that originally parDataId was intended as a filter. i.e. they only wanted a count of items where some dataId attribute, long since obsoleted, equalled parDataId.

  • Sauron (unregistered)

    We can name that anti-pattern "re-invent the wheel, by misusing damaged trashcans unstead".

  • Brian (unregistered) in reply to jeremypnet

    That's a good point. I'd bet that a lot of these code samples didn't actually start out horrible, but evolved into abominations through a series of short-sighted decisions over the life of the project. I've seen plenty of cases of "Well, we could refactor the whole thing, but that's risky so just delete this one line and leave it at that."

  • Maarten (unregistered)

    I'd call this pattern Redundant Recount.

  • (nodebb)

    Even if you changed the method to no longer use the parameter because you didn't want to change the callers (maybe there are hundreds), you are setting yourself up for more failure because future programmers will think it does something (people often fail to look at methods' implementations).

  • Hanzito (unregistered)

    We could call it the iDC pattern.

  • (nodebb)

    Similar to a linear search, I suggest "linear count."

  • (nodebb) in reply to Registered

    Yes. The specification for the Map interface does allow it, though I'd guess most implementations don't support it.

    int size() "Returns the number of key-value mappings in this map. If the map contains more than Integer.MAX_VALUE elements, returns Integer.MAX_VALUE."

  • Rendle (unregistered)

    I humbly submit "Zero-Trust Counting":

    "Yes, I know there's a Count property, I just don't trust it."

  • Oracles (unregistered)

    I'll generically call it "wheel programming" where you undertake to re-implement a feature so common and widely known that you are truly reinventing the wheel.

  • Bill T (unregistered)

    "Sesame Street Counting" - "That's one - ONE - lovely key value! Ha ha ha!"

  • (nodebb)

    Count me amongst those who thinks this evolved. Perhaps fixing it isn't feasible because of stuff using it that would have to be updated.

    That being said, change the signature to (int Obsolete) if you're going to dump a parameter!

  • (nodebb)

    Maybe the code author works somewhere that is clever enough to know that using numbers of lines of code as a performance metric for your programmers is too vulnerable to being gamed, so they switched to a better method of assessing programmer performance: number of CPU cycles consumed by their code in production.

    Not only is this clearly more objective (no more arguments about brace styles or correction factors for the language of choice - is one line of SQL treated as 5 or 10 lines of assembly code?), it helps motivate programmers to work on the things that are important because they're run frequently (management dashboards!) rather than code that is unimportant because it's only used by a small number of people occasionally (year end processing, yawn).

  • NotAThingThatHappens (unregistered)

    What about "loopy counting" ? (pun intended)

  • (nodebb)

    All this is legitimate commentary, but is based on a very risky assumption - that myTransactionDataContainerMap is in fact a standard implementation of Java.util.Map. We don’t actually know this to be the case.

    The only things we know for certainty are that myTransactionDataContainerMap has a method keySet(), and that this method returns an Iterable (and both of those items of certainty are assuming that this code does indeed compile… which no-one has proved).

    If keySet() returns a Set, as you might expect from the name, then sure, one could call the size() method (not a field!) to get the count of items. However, we don’t know that this is definitely the case, and Iterable does not implement a size() method.

    It doesn’t take much imagination (unfortunately) to come up with a cursed design where keySet() returns an Iterable that is actually a cursor on a database query (maybe with SELECT DISTINCT to guarantee uniqueness)… in which case, the only way to get a count from this cursed library would indeed be to iterate like this.

    Sadly, I have definitely encountered libraries over my career where Iterable is the return type from some methods, and have had to employ this exact counting pattern.

  • RLB (unregistered)

    All this mention of Sesame Street counting reminds me that the original Pinball Number Count ("One two three FOUR five") was sung by the Pointer Sisters.

  • Duke of New York (unregistered)

    One time when I was quite young and in church, the pastor announced a hymn number, and there was a small boy in front of me. He took out the hymnal and started turning the pages one by one to find the hymn. That's what I think of when I see code like this. It's the code equivalent of writing an R backwards.

  • (nodebb)

    Disclaimer: I have never written a line of Java in my 50+ years working as a dev. I have no opinion plus or minus about it; I've just never dealt with it enough to have an opinion.

    Ref this bit of Rocketeer007's thoughtful and evidently well-informed comment:

    If keySet() returns a Set, as you might expect from the name, then sure, one could call the size() method (not a field!) to get the count of items.

    Since Set.size() is a method, not a field, that makes wonder about the internal implementation of the method. Perhaps Java has to iterate and count them too?


    Unrelated to the above, iterating over a collection of whatever sort in whatever language is also fraught in a multi-threaded environment. It's interesting to me that in all the WTFs that we deal with here, we almost never see any evidence of thought about multi-threaded interlocking, DB transactions (ref yesterday), or asynchronous ops.

    So many WTFs read like they came from the 1980s. Even when written in languages and for missions unheard of until 2015.

  • Oleksii (unregistered)

    this is "help Dora to" count :)

Leave a comment on “Unaccountable Counting”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article