• hellishharlot
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    Index can be useful but start looking for mapping and sorting functions. Or foreach. If you really must index, sure go use index or I if it’s conventionally understood. But reading something like for I in e where p == r.status is really taxing to make sense of

    • indepndnt@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Honest question: is there a mapping function that handles the case where you need to loop through an iterable, and conditionally reference an item one or two steps ahead in the iterable?

      • xigoi@lemmy.sdf.org
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 year ago

        In Haskell, you could do something like map (\(thisItem, nextItem) -> …) (zip list (tail list))

      • hellishharlot
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Not that I’m aware of but that’s a condition where you’re thinking with an index. What’s the difference you’re looking for?

        • indepndnt@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Something like parsing a string that could have command codes in it of varying length. So I guess the difference is, is this a 1-, 2-, or 3-character code?

          I have something like this in a barcode generator and I keep trying to find a way to make it more elegant, but I keep coming back to index and offset as the simplest and most understandable approach.

          • hellishharlot
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            So you could generate lists of 1, 2, and 3 character code items rather than looking at index +1 or something.

      • drathvedro@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        In js there’s reduce. Something like

        arr.reduce((result, currentValue, currentIndex, original) => {
        if(currentIndex < original.length - 2
            && original[currentIndendex + 2] % 2 === 0 ) {
            result.push(currentValue / 2) 
        } else { 
            result.push(currentValue);
        }
        return result;
        }, []) 
        

        This would map arr and return halved values for elements for which the element two steps ahead is even. This should be available in languages where map is present. And sorry for possible typos, writing this on mobile.

    • 9point6@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Oh yeah, I map, filter and reduce pretty much everywhere I can. But sometimes you need the index and i is so commonly understood to be that, I’d say it could even be less legible to deviate from that convention

      • hellishharlot
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 year ago

        In what world is

        for (int index = 0; index < objectToIterate; index++)
        {
            // DO YO THANG
        }
        

        less coherent than

        for (int i; i < objectToIterate; i++)
        {
            // DO YO THANG
        }
        
          • hellishharlot
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            What’s incoherent about the first one? Why is index bad beyond standards

            • 9point6@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              It’s not incoherent, it just takes a tiny bit more effort to mentally parse as it’s not a stereotypical for loop. Maybe it’s just me, but let me try and explain

              With the i example if you’re familiar enough with a language, your brain will gloss over the unimportant syntax, you go straight to the comparison and then whether it’s incrementing or decrementing.

              With the other example, the first my brain did was notice it’s not following convention, which then pushes me to read the line carefully as there is probably a reason it doesn’t.

              I’m not saying it’s a huge difference or anything, but following code conventions like this makes things like code reviews much easier cumulatively.