Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code Smells: Iteration

blog.jetbrains.com

Post reply on HN
Print view View original

91–95 of 95 posts

Re: Code Smells: Iteration

#91

Post by apta »

leeter wrote: post #62
tXEHOKhd wrote: post #59

Earlier quoted context omitted.

It's not just Java! I see this all the time in C and C++ as well. Developers seem to be afraid to use types as they were intended. For example, look up any OpenGL question on StackOverflow and you'll see things like what should be an array of 3D vertices with separate x, y, and z components passed as a 1D array of floats. In C++ we see quite a bit of abuse of std::pair instead of just making a fucking struct to hold…

It's an educational problem, Chandler Caruth of LLVM gave a really good talk on POD type slicing and how useful it can be. More to the point that for PODs it's supported in the standard. I do agree on the abuse of pair... pair is there for implementers primarily and shouldn't be used outside of deliberately templated code. Ditto tuple. That said... with C++17 destructuring... it's a lot less painful since you can do…

What was the title of the talk?

Re: Code Smells: Iteration

#92

Post by apta »

masklinn wrote: post #16
megawatthours wrote: post #12

Something I see often and is a huge code smell to me is not using the most restrictive form of iteration. If you see collection.map(...) you know that each iteration is simply a pure function from original element to transformed element, which is an immense help when reading the code. If you can use only map / filter / takeWhile / join etc to express what you are doing, use those! If not, try and just use reduce / fo…

> If you see collection.map(...) you know that each iteration is simply a pure function from original element to transformed element, which is an immense help when reading the code. You'd think so, but I've had colleagues who managed to fuck that up and use map or list comprehension solely for side-effects.

I saw some code like this:

    def update(): Try[Unit] = {
      parser.parse(...).map(result => updateState(result))
    }
And I thought it was abusing the map() call for side effects. However, it is still shorter than writing it out as follows:

    def update(): Try[Unit] = {
      parser.parse(...) match {
        case Success(result) =>
          updateState(result)
          Success(())
        case f@Failure(_) =>
          f
      }
   }
So I didn't have a strong opinion either way since semantically both do the same (and in the case of Scala, the first one is potentially more performant since it relies on the JVM doing virtual dispatch as opposed to calling unapply() and matching, not to mention potentially less garbage being generated).

Re: Code Smells: Iteration

#93

Post by needcheapbw »

KirinDave wrote: post #89
needcheapbw wrote: post #79

Earlier quoted context omitted.

> There are very few cases where a for-loop is the right thing to write. I'm trying to get my head around that, do you mean any for loop is bad or many nested loops?

Indexed loops are just a bad problem waiting to happen. They introduce arithmetic bugs, are the least efficient way to traverse most any data structure but a sequential memory segment, maximize the opportunity for error, and are often harder for compile-time optimizers to work through (since it's harder to prove what they do in situ). Abstracting away your iteration is important.

Like, for(int i=0; iThere is on rare occasion, however, sometimes a problem that is solved more clearly or handily using indexing, similar to step indexing in BASIC.

One use case where I've seen stepped indexing useful is in the field of robotics, which uses step characteristics for synchros and servos.

Re: Code Smells: Iteration

#94

Post by hepta »

needcheapbw wrote: post #93
KirinDave wrote: post #89

Earlier quoted context omitted.

Indexed loops are just a bad problem waiting to happen. They introduce arithmetic bugs, are the least efficient way to traverse most any data structure but a sequential memory segment, maximize the opportunity for error, and are often harder for compile-time optimizers to work through (since it's harder to prove what they do in situ). Abstracting away your iteration is important.

Like, for(int i=0; i There is on rare occasion, however, sometimes a problem that is solved more clearly or handily using indexing, similar to step indexing in BASIC. One use case where I've seen stepped indexing useful is in the field of robotics, which uses step characteristics for synchros and servos.

> The only down side is removed compatibility with other languages like C and C++ and C#, locking in the app to a specific language more.

Using a Stream instead of a for loop does very little to make your code incompatible with C. It is already pretty much incompatible (modulo JNI).

What I mean is: if you want something that looks like C just use that, there is no gain in not learning new constructs just because older languages did not have them.

Re: Code Smells: Iteration

#95

Post by gpvos »

The autoplaying code editing animations are really annoying. By the time I've read the preceding text, it is somewhere in the middle and I don't know what it's doing.

Please, can we just agree that animations and videos (and audio) should only play when the reader initiates it? Also, a progress bar would be handy, although it may not always be necessary (for short animal videos and similar).

Post reply on HN