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

71–80 of 95 posts

Re: Code Smells: Iteration

#71

Post by marcosdumay »

throwaway613834 wrote: post #67
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…

One problem in C++ is if you define a struct then you have to define a bunch of operators yourself (operator<, etc.) which gets annoying after you've realized you've needed them a bunch of times.

Does C++ Pair define operator?

That's surprising, and for me looks completely uncalled for.

EDIT: Just looked into Haskell (because it's easier), and tuples do derive Ord there. Is there some universal convention I'm missing?

Re: Code Smells: Iteration

#72

Post by mikojan »

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.

This. I've seen FP features (and incidentally OOP features as well) misused so hard, I'm thankful for every plain loop (or struct for that matter).

Re: Code Smells: Iteration

#73

Post by khedoros1 »

s73ver_ wrote: post #34
koolba wrote: post #8

Earlier quoted context omitted.

That was my take as well. It's like seeing code with the same constant inlined in multiple places rather than centralized: // Use some inlined string as a magic code value: doStuff("Some Magic Code"); ... // Later on same inlined string: doOtherStuff("Some Magic Code"); versus: // Define it once: const GOOD_NAME_FOR_MAGIC_CODE = "Some Magic Code"; // Use it: doStuff(GOOD_NAME_FOR_MAGIC_CODE); ... // Use it somewhere…

"If that triggers an "ah-ha!" moment for you then you've likely got bigger problems." Or you're just not as experienced. Remember, every day there's someone born who hasn't seen the Flintstones.

It seems like "inexperienced" should fall under the umbrella of "bigger problems". It also (hopefully) falls under the umbrella of "temporary problems".

Re: Code Smells: Iteration

#74

Post by [deleted] »

jdmichal wrote: post #66
glibgil wrote: post #14

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

Not sure what you're trying to get at. Indexing by surrogate index, yes. Indexing by value? That doesn't help. The best you can do is binary search -- O(log n). Hash-based structures are average amortized constant time -- O(1). This works because the key is a function of the value, rather than a surrogate key which is unrelated to the value. Straight from Wikipedia: "In many situations, hash tables turn out to be mor…

[deleted]

Re: Code Smells: Iteration

#75

Post by throwaway613834 »

marcosdumay wrote: post #71
throwaway613834 wrote: post #67

Earlier quoted context omitted.

One problem in C++ is if you define a struct then you have to define a bunch of operators yourself (operator<, etc.) which gets annoying after you've realized you've needed them a bunch of times.

Does C++ Pair define operator ? That's surprising, and for me looks completely uncalled for. EDIT: Just looked into Haskell (because it's easier), and tuples do derive Ord there. Is there some universal convention I'm missing?

> Is there some universal convention I'm missing?

Tuples are always compared lexicographically, is the universal convention. Not sure if that's what you might be missing?

Re: Code Smells: Iteration

#76

Post by khedoros1 »

marcosdumay wrote: post #71
throwaway613834 wrote: post #67

Earlier quoted context omitted.

One problem in C++ is if you define a struct then you have to define a bunch of operators yourself (operator<, etc.) which gets annoying after you've realized you've needed them a bunch of times.

Does C++ Pair define operator ? That's surprising, and for me looks completely uncalled for. EDIT: Just looked into Haskell (because it's easier), and tuples do derive Ord there. Is there some universal convention I'm missing?

> Does C++ Pair define operator?

It does.

std::sort(pairarray.begin(),pairarray.end()) works about how you'd expect, as long as operator< is defined for the constituent types of the pair.

Re: Code Smells: Iteration

#78

Post by OtterCoder »

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.

Even Excalibur can be used to mince garlic, and even a supercomputer can be used to play Zork.

Re: Code Smells: Iteration

#79

Post by needcheapbw »

KirinDave wrote: post #54

Reading this article, I got a bit bothered. I agree with the sentiment: people repeat entirely too much code. There are very few cases where a for-loop is the right thing to write. Using generic methods which can be tested and shipped in isolation is basically always better. But the article seems to imply there are performance concerns in some cases with its talk of using "a data structure". This irked me, because it…

> 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?

Re: Code Smells: Iteration

#80

Post by jstimpfle »

nemetroid wrote: post #28
jstimpfle wrote: post #18

Earlier quoted context omitted.

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…

Map-style iteration carries more semantic information than a C-style index based loop. An index based loop might be doing anything with the data being iterated over. When you do collection.map, already at first glance you get an idea about what the code is doing.

Yep - and nobody cares. Write clean code instead. Much harder than simply changing the looping style.
Post reply on HN