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

31–40 of 95 posts

Re: Code Smells: Iteration

#31

Post by hinkley »

nickbauman wrote: post #15
hinkley wrote: post #13

Earlier quoted context omitted.

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.

The first time I ran into this was on a project that was passing contact information around like String, String, String, int. Back and forth across the system in four or five workflows with extra data passed in here and there.

Of course they left off Address Line 2 and rather than try to fix this in thirty places as I was told I made an Address object instead.

With very rare exception, a street Address (Address 1) is meaningless without at least the zip code. And god help us if you had two addresses.

Later it took someone a couple hours to fix it for 9 digit zip codes. No further changes unless a new State joins the union (this was for a state court system and they required a domestic mailing address. One of the few times I didn't eventually need to process international addresses)

Re: Code Smells: Iteration

#33

Post by lstyls »

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…

Agree. What makes a pattern a code smell is that it is immediately recognizable and is almost never a false positive. Either the immediate implementation is problematic, or something about the larger context of the implementation is problematic.

A functional programming diehard could assert that iteration is a code smell, because recursion is the preferred solution. But there is nothing inherently wrong with using iteration to implement a solution in Java.

Re: Code Smells: Iteration

#34

Post by s73ver_ »

koolba wrote: post #8
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…

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.

Re: Code Smells: Iteration

#35

Post by jimbokun »

jnordwick wrote: post #26

Does anybody here really have to be told this? This is literally CS 101 (your first month of 61B at Cal). Why is this posted here?

So everyone here is required to have a CS degree now?

Lots of self taught developers, and people with business or quantitative-but-not-coding backgrounds read Hacker News, I think.

Re: Code Smells: Iteration

#36

Post by s73ver_ »

hinkley wrote: post #27
jayd16 wrote: post #17

Earlier quoted context omitted.

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

Exhibit A: The getLoadNames method returns a List of Strings, which we iterate over in order to see if a particular String value is in there. Even in describing the algorithm we aren't informed it's a list of function names. Edit: from the comments in the code it's pulling field names from a Mongo result set, so it's member variables more so than function names. One half of that relationship is still deterministic at…

Because for the purposes of example, it doesn't matter what the data actually is.

Re: Code Smells: Iteration

#37

Post by squiguy7 »

These examples seem to discuss data structure choice what I thought it might be about. I have encountered two major bugs at two separate companies all involving iteration and maps.

Both of the examples were written in Go and although language shouldn't matter, iterating over a map is non-deterministic. But each time the author intended for them to construct the returned data structure in a pre-defined order.

We had been suffering from poor caching performance and saw our Cassandra reads spiking as a result. Once we spotted the incorrect cache key construction, our reads to Cassandra dropped significantly allowing for better performance all around.

Perhaps others would have spotted this but it seems innocuous in code review. I know I will be more diligent in the future.

Re: Code Smells: Iteration

#38

Post by [deleted] »

mikeash wrote: post #21
chillydawg wrote: post #6

Earlier quoted context omitted.

It's obvious to anyone with a CS (or similar) degree, but may not be to someone who is learning to code from various tutorials. Having hints like this in your IDE can greatly improve the quality of your code and help you learn.

Exactly, this is pretty clearly aimed at beginner/intermediate programmers who haven't entirely figured out how to decide when to use List versus Set versus Map. It's probably obvious to the typical HN reader, but valuable for the target audience. Might not belong here, although the fact that it's currently at #3 on the front page suggests there's enough interest in it.

[deleted]

Re: Code Smells: Iteration

#39

Post by seanp2k2 »

nickbauman wrote: post #15
hinkley wrote: post #13

Earlier quoted context omitted.

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.

If you're just using objects to represent groupings of strings and encapsulate behavior around converting them back to strings for output at some point, why not just operate on the strings instead of all the serialization / deserialization? Maybe enough of the quick stuff I do isn't enough to warrant more complex data structures, but I get pretty far into a problem with just dicts (in Python) and generally get annoyed when something returns back objects that have no easy str representation without finagling the object into giving me what I need. I think that this is generally a bigger issue with libraries and treating object metadata (stuff like time stamps, extra attributes, etc) as of equal importance as the data it represents; if an object has one obvious attribute for what the thing is, make that the default thing you get when you just refer to the thing, instead of making everyone call some weird method to turn the instance into the representation that you likely want to get out of it.

Re: Code Smells: Iteration

#40

Post by hinkley »

s73ver_ wrote: post #36
hinkley wrote: post #27

Earlier quoted context omitted.

Exhibit A: The getLoadNames method returns a List of Strings, which we iterate over in order to see if a particular String value is in there. Even in describing the algorithm we aren't informed it's a list of function names. Edit: from the comments in the code it's pulling field names from a Mongo result set, so it's member variables more so than function names. One half of that relationship is still deterministic at…

Because for the purposes of example, it doesn't matter what the data actually is.

I'll bet you a six pack that hasName is called in a tight loop somewhere. The cost of generating the collection on every call is far greater than the cost of iterating it was.

Can we at least agree that the chosen example has too many other confounding factors in it?

Post reply on HN