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

11–20 of 95 posts

Re: Code Smells: Iteration

#11

Post by rootlocus »

jrs95 wrote: post #4
jnty wrote: post #2

At the risk of sounding arrogant, isn't this a bit obvious? To me, code smells are more about spotting when someone's been forced to do something a bit weird and convoluted. It's possibly the cleanest solution available given the immediate context, but this is actually a symptom (or "smell") that something is wrong with the wider design of the system. This article seems more about detecting choices around data struct…

It's obvious to some of us, but not all of us. I see things way worse than this on a fairly regular basis.

Sets have a very specific use case: they only contain unique values and (unless using a specific implementation) they don't have any defined order. Switching from arrays to sets just to get rid of an iteration doesn't sound like fixing a smell to me. Also, insertion, iteration and memory usage are less efficient for a set.

Re: Code Smells: Iteration

#12

Post by megawatthours »

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 / foreach. If not, try and just use for. Only use while if nothing else works!

Re: Code Smells: Iteration

#13

Post by hinkley »

jnty wrote: post #2

At the risk of sounding arrogant, isn't this a bit obvious? To me, code smells are more about spotting when someone's been forced to do something a bit weird and convoluted. It's possibly the cleanest solution available given the immediate context, but this is actually a symptom (or "smell") that something is wrong with the wider design of the system. This article seems more about detecting choices around data struct…

It's worse than that. We have met the Enemy and the Enemy is us.

Java, as introduced, claimed that nearly everything was an Object. What we got instead was nearly everything is a String.

The Real WTF in this code is that all of the important information is passed around as Strings. The iterator and its source hint at this but she fixes the wrong problem. Ever has this been the way with Java. Despite having a statically typed language nobody turns the data into information and instead your modules just vomit strings at each other. Sometimes in groups of four or more.

Re: Code Smells: Iteration

#14

Post by glibgil »

Hashing is indexing and there is no faster and memory efficient index than an array (not vector) of sorted items. Iteration is the best if you can organize your data for it

Re: Code Smells: Iteration

#15

Post by nickbauman »

hinkley wrote: post #13
jnty wrote: post #2

At the risk of sounding arrogant, isn't this a bit obvious? To me, code smells are more about spotting when someone's been forced to do something a bit weird and convoluted. It's possibly the cleanest solution available given the immediate context, but this is actually a symptom (or "smell") that something is wrong with the wider design of the system. This article seems more about detecting choices around data struct…

It's worse than that. We have met the Enemy and the Enemy is us. Java, as introduced, claimed that nearly everything was an Object. What we got instead was nearly everything is a String. The Real WTF in this code is that all of the important information is passed around as Strings. The iterator and its source hint at this but she fixes the wrong problem. Ever has this been the way with Java. Despite having a statical…

Agree. I think we're all Stringly-typed developers. We use strings everywhere. We throw strings across system boundaries at will.

Re: Code Smells: Iteration

#16

Post by masklinn »

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.

Re: Code Smells: Iteration

#17

Post by jayd16 »

hinkley wrote: post #13
jnty wrote: post #2

At the risk of sounding arrogant, isn't this a bit obvious? To me, code smells are more about spotting when someone's been forced to do something a bit weird and convoluted. It's possibly the cleanest solution available given the immediate context, but this is actually a symptom (or "smell") that something is wrong with the wider design of the system. This article seems more about detecting choices around data struct…

It's worse than that. We have met the Enemy and the Enemy is us. Java, as introduced, claimed that nearly everything was an Object. What we got instead was nearly everything is a String. The Real WTF in this code is that all of the important information is passed around as Strings. The iterator and its source hint at this but she fixes the wrong problem. Ever has this been the way with Java. Despite having a statical…

Just FYI, they ran this example over some built in reflection APIs. Hard to write code designed to get methods by string name without strings...

Re: Code Smells: Iteration

#18

Post by jstimpfle »

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…

What is the "most restrictive" form? The answer to this question is highly context dependent (for example, programming language / architectural framework) and expensive to give. Remember that everything has a cost. And especially overzealous formalism.

Personally I find simple C index-based for loops consistent and refreshing. And it's typically not a huge deal. If it is, the procedure might be doing too many things at once. (But yes, I use simple "for x in y" style loops in Python or C++ when they make the lion's share of the loops).

Many different types of loops in a single file, over a single datastructure, always remind me of odd syntax highlighting (for example in vim) in so many different colors that it's only a distraction. I don't care to make so many distinctions. I try to focus on the distinctions that we have to make to get a program done.

Re: Code Smells: Iteration

#19

Post by jayd16 »

jnty wrote: post #10
jrs95 wrote: post #4

Earlier quoted context omitted.

It's obvious to some of us, but not all of us. I see things way worse than this on a fairly regular basis.

I guess - but I feel like you'd call it an "error" rather than a "smell". Better to just teach people data structures rather than which constructs they should be afraid of. Approaching it "sideways" like this just leads to people going "I heard that loops can be bad, so I copied and pasted that line 25 times instead".

Its a smell and not an error because it works perfectly fine and it actually is perfectly fine for now because the n for that linear search is low.

Re: Code Smells: Iteration

#20

Post by recursive »

hinkley wrote: post #13
jnty wrote: post #2

At the risk of sounding arrogant, isn't this a bit obvious? To me, code smells are more about spotting when someone's been forced to do something a bit weird and convoluted. It's possibly the cleanest solution available given the immediate context, but this is actually a symptom (or "smell") that something is wrong with the wider design of the system. This article seems more about detecting choices around data struct…

It's worse than that. We have met the Enemy and the Enemy is us. Java, as introduced, claimed that nearly everything was an Object. What we got instead was nearly everything is a String. The Real WTF in this code is that all of the important information is passed around as Strings. The iterator and its source hint at this but she fixes the wrong problem. Ever has this been the way with Java. Despite having a statical…

Unix started it.
Post reply on HN