You are reaching in my view. First off, fixing it so there is no doubt is like trivial. Second of all when we're talking about tight coupling of functions that in my view is questionable practice. Further more I know you know it is questionable practice. Third of all since it is actually easy to fix it just makes for a more stable code base especially in regards to code maintenance because the coupling is much looser. If it was really complicated to fix and the inputs were validated well I guess that could be a reason but I have my doubts.

To simplify the example further, most people who think that code snippet is the worst also prefer:

over

correct?

For something that on surface has nothing to do with functional programming, I think it's just a litmust test for affinity towards functional programming.

fwiw, performance/static data considerations aside, i find your array version much more readable. the distance between the mental concept and its expression in code is almost non-existent -- whereas the switch statement more than doubles the code size with syntactic ceremony.

I still prefer the case statement, but I don't really care in this example. I think what really bugs me is:

Because of the way the code is written it seems like he's creating invalid objects (or ones that should never be created) and then just never returning them. Its 'confusing', imo.


Syntactic ceremony (at least in this context and to a point) is pretty correlated with readability, imo. Especially for younger/junior developers.

But my main feedback would be that the code should use one style or another and not mix them.

highly correlated. inversely :P

i would argue that familiarity is a confound here, and that the case statement is probably more "readable" to you to the extent that you have spent more time with codebases written in that style.

eg, i've talked to lifelong java developers who swear that java is more readable to them than ruby, and i think they're being honest. however, i've never encountered someone who has spent a significant amount of time developing with ruby that feels the same (say, 6mo - 1yr full time). while it's not impossible, i think it's unlikely, as removing extraneous information is almost universally associated with easier cognition for humans, whether that's extra words in prose, extra syntactical cruft in code, or extra lines in an explanatory diagram. "Make things as simple as possible, but not simpler" and all that.

The majority of people are probably more familiar with the case statement, imo. But if a group of developers are very comfortable with the list version, then by all means I think thats fair to call it the more readable version for them.

There's a difference between crappy boilerplate like Java and something like the case statement example here.

Edit: The removing extraneous information argument doesn't seem very powerful to me in this case. It's a minimal amount in either case and its not really a good argument since the most concise version of 'a program' is rarely the most readable.

also, especially if the list is long, you can always do this too:

serious question: other than one of degree, what difference do you think there is?

there is some tipping point where you get into obfuscation/code golf territory and things turn arcane, and i guess that point is different depending on your experience level, but i want to say that as long as you're not relying on implicit, hidden logic or on idioms that few are familiar with, more concise is more readable most of the time.

The switch statement is a pattern. You see it and your brain says "Yup, I know exactly what this is".

If boilerplate helps you identify the pattern - then its helpful. I think the switch statement falls into this category - in the sense that the 'boilerplate' is minimal and useful. It neatly separates the condition portion from the dependent code portion.

Java boilerplate almost always has more than is necessary to identify the concept being used and adds nothing. "Foo f = new Foo()" is a good example in that "f = Foo()" is still clearly an object of type Foo being instantiated and assigned the name f.

Meh. I feel like I don't really agree in that one concept per line is usually more readable imo, regardless of idioms/syntax. But I'm honestly not sure if I'm just feeling this way because we're having an argument.

Edit: My pattern matching comment is why I have no problem with people that use the list syntax a lot saying the list style is more readable. If its a common pattern they're use to, then it probably is more readable to them.

Why can't we just create the array outside the function again? I think that's my biggest sticking point. Any code that creates an array every time the function is called - only to consume one element of that array - is just really bad to me.

You could. I'd also find that significantly better.

This seems relevant to that debate on AngularJS vs React/mithril/etc a few months back.

Facebook's React tutorial rewritten in AngularJS

could and should. just wasn't the point we were discussing atm.

It helps you identify the pattern because you're used to it, doesn't it? There's nothing inherent in retyping "return" and "case" a bunch of times that makes it easier to identify at a glance. If you saw the multi-line array version a bunch of times, that would be a "pattern" for you too.

And at that point, which of the two patterns is better?

If you arguing that more developers are familiar with the switch, and I want a code base that optimizes for new developer ramp up time, I think that's at least a valid argument.

But I think the pattern matching argument above is a chimera that feels true to you, again because of familiarity.

I don't think I've said anything that disagrees with what you just wrote.

i guess we'll just have to agree to agree, then

Do you think that someone who doesn't understand the micro can really be an expert at the macro?

I get there could be an exception, but have you, in your experience, ever met a good writer that struggles with grammar or a coder that struggles with for loops (wtf is the point of fizz-buzz then?)?

Or they could be coming from languages that don't have case statements, like Python.

Not only is my answer yes, but it's almost more common than not in the case of writing. Many, many people who understand character, story, and dialogue well could not for the life of them diagram a sentence or even write a long piece of prose without making grammatical errors (though they would be of the technical variety, and not of the jarring awkward variety, for the most part). The two skills have little to do with one another.

of course not this, but it's a straw man of my argument. what i have seen (and again, it's pretty common) is people who can put together large projects with solid high level architecture but whose code on a micro-level is kind of sloppy. you can open up pretty much any code base of any major open source project and find things that could be improved, often significantly, on a micro level. it's usually not that they couldn't make it better, but that the specific effort it takes to polish the code sentence by sentence, as it were, bores them, so they don't put much value on it. or they'd rather be shipping a new feature, or whatever.

and i say this as someone who does put much value on it. but objectively, i think the micro is easy. that's why people like to obsess over it.

So I'm in like an intro-level software engineering class and 2/3 of our grade is based on a 5 man group project.

UCI decided that every group must do the same project for the credits to count towards a transfer, so my dumbass teacher spent half the class trying to get 60 dumbass kids to agree on a piece of software to design. Of course no one can agree so he tells us we're making a restaurant POS application.

boring but whatever. the stupidest thing is his grading metric - 15% of it is on how well the application works, the other 85% is our SRS. And his grading metric on the SRS is how long it is - he expects 300+ pages. Great. Now I gotta compete with a bunch of overachieving asians that are gonna crank out 400 pages of fluff just to break even on this damn thing.

How the **** can something like that generate 300 pages of documentation?

Luckily I'm not the leader for this thing but my leader is a bit of a slacker. He's trying to convince us he doesn't need to do any documentation. Um, **** you, yea you are.

Dear god what a horrible horrible project. What is an SRS?

basically just UML stuff

Ever hear of 60pt font?

drop out obv.

I had a course like that. ****ing painful and useless.

Does anyone even use UML anymore outside of satellite systems and stuff?

This: http://en.wikipedia.org/wiki/Message_sequence_chart is about the only useful thing I learned from UML. And even there I just use the basic idea and ignore all of the bull**** dashed/dotted/solid/hollow arrows and boxes.