Please, kill your darlings (opens in new tab)

I'd suggest an alternate approach: add enough commentary to your one-liners so that a reader can parse that instead of the statement. Bugs can hide in the expanded versions of code just as easily. By offering the reader of the code a clear summary of the next one-liner, they can quickly scan it if they are trying to find a bug nearby and decide if it is potentially the culprit.

On top of that, consider making every bit of clever code a reusable library snippet instead. If it becomes part of the vocabulary of your codebase it'll be easier for others to understand it by looking at call sites.

eg:

  # Capitalize the first letter of every word
  @sentence = @sentence.split(' ').map!{|x| x = x[0..0].upcase << x[1..-1]}.join(' ')

I'm curious to see how more experienced Rubyists on HN would write this. My stab:

@sentence.split(' ').map(&:capitalize).join(' ')

More terse and more descriptive (imo)

Maybe I'm still just showing off, but I don't even use Ruby that often and it's pretty clear what that code does. Split the sentence into words, capitalize the first letter of each word, and re-join the words into a single string.

Great post. This is one of my biggest pet peeves with Ruby and languages like it; they encourage developers to "show off" by using the most esoteric features they can find (even better if these features use weird symbols).

Compared to a language like Python that has few neuroses, the same developer writes much less readable code.

The post may have been better if the author included a Python sample that does the same thing:

    long_string = 'ajix mxozl xoap'
    new_string = []
    for word in long_string.split(' '):
        new_string.append("{}{}".format(word[0].upper(), word[1:]))
    new_string = ''.join(new_string)

Admittedly there are a few annoying symbols in here, mostly due to the non-intuitive operation of the join function and the well-meaning but less-than-ideal string formatting syntax (which could've been avoided if we used conventional strong concatenation, and which PEP 0498 attempts to improve). Also admittedly, coders who want to show how smart they are would try to use a list comprehension to do this, which is slightly less readable and imo shouldn't be used over this format without a good reason. But it's still much easier to parse than the Ruby version because everything is explicitly spelled out in the loop, and you generally shouldn't have to consult the language docs to look up 4 different rarely-seen operators.

Remember, debugging is twice as hard as authoring, so if you write the most clever code possible, you are by definition not intelligent enough to debug it. ;)

I understand that people can't be expected to stick to that on their own, so they need languages that promote function, uniformity, and ease of use over showmanship.

The simplicity of the code is one of the main things I look for in interviews. If you could've done something with the conventional, simple language construct that doesn't require someone to go back and refer to the docs, even if it takes more lines, but instead you used the super-arcane construct to prove how well you know the language or to "get it all on one line", I'm going to look on that pretty dubiously. The last thing I want to deal with on my projects is the residue of someone's ego impacting our ability to read their code and get things done quickly and easily.

P.S., in Python, there are a couple of shortcut functions for capitalizing each word in a sentence: str.title() and str.capwords().

In this thread are literally 300 comments saying "Huh, I don't even Ruby, and I understood it", thereby (in my opinion) completely proving the point.

It's exactly because people pull this sort of thing "Hey, it was really easy to understand for me, how about you?" that I have seen developers feel compelled to put clever oneliners in codebases. Clever oneliners that later end up causing problems for whatever unluckly newbie has to troubleshoot their edge cases.

Just stop it, and unless you're on a word budget or this drastically improves performance, do something sensible that looks like the pseudocode:

  for word in sentence.split(' '):
      word.capitalize_first_letter

(If you want to be all functional, by all means use a map instead.)

So I don't have to deal with the case where your clever function barfs on (hypothetical example, don't think this happens with the current code) the special case where there is a space between the last word and a period that ends the sentence; and you're trying to capitalize the period. [Edit: As expected, looks like this code fails with even common graphemes. Which is fine, but is an argument towards at least trying to make it more comprehensible.]

I like that type of code, so yes, maybe it's a darling.

It's easy to make it more readable by aligning the code with the dots, so that it becomes a pipeline:

  @sentence = @sentence.split(' ')
                       .map!{|x| x = x[0..0].upcase << x[1..-1]}
                       .join(' ')

I definitely prefer that to half a screen page of crappy imperative code, where people over time will add lots of side effects etc.

Besides, the middle part is clearly a strawman because

  @sentence = @sentence.split(' ')
                       .map!(&:capitalize)
                       .join(' ')

but yeah. ;)

The number of people here defending long 'darlings' (or over-generalizing 'long one-liners'), is both shocking and dimsaying to me. Beyond basic functionality one of any (serious) programmer's _top_ priorities is to maximize the readability of their code for the next (unkown) programmer that touches the source.

We all have large monitors -often rotated 90degrees to portrait. Extra lines are not a bad thing (especially if it helps visually break things into multiple smaller steps), and more work on a single line does not == elegance.

Either comment your code or move darlings to a properly named function, which is even better.

@sentence = capitalizeEveryWordInThe(@sentence)

Then you can both unit test (if you're into that kind of thing) and refactor without breaking a lot of things.

>So, why do we do it?

I do it because it reduces physical code size and helps me "chunk" code in my brain. Since I wrote it, I know what I intended it to do and how it does it, possibly with the aid of a small comment.

This helps me have a more compact complete representation of the surrounding code, both in my editor and in my brain.

Is it bad for verifying correctness and allowing others to understand the code? Sure. But there is absolutely a well-considered reason why I do it, and it's not to show off.

Every discussion of code style eventually devolves to a discussion about readability, which eventually devolves to a knife fight in a conference room because one man's readable expression is another man's opaque one-liner.

The threshold for 'darling' depends upon the facility of the developer. Some of these are obvious to those with extensive experience.

So where does it end? Dumbing down code until its so wordy, so bland, that it takes minutes to digest every phrase? To rewrite it in your minds eye until its back to that 'darling' concise expression. I recall taking a contractors 2 pages of code, and reducing it to a line. Not even a very complex line. In my view that was all improvement.

I am sympathetic to the author's argument. Programmers should strive to write understandable code. However, I think you should also assume that people reading your code are fluent in the language and its idioms. You wouldn't expect a novelist to write books at a first grade reading level just to appease people that haven't put forth the effort to learn the language beyond just the basics.

    @sentence = @sentence.split(' ').map!{|x| x = x[0..0].upcase << x[1..-1]}.join(' ')

Nobody sensible would write this code. The nearest sane version is:

    @sentence = @sentence.split(' ').map{|x| x[0].upcase + x[1..-1]}.join(' ')

But, although capitalize doesn't do the same thing, it's almost certainly what is actually wanted, so it would be

    @sentence = @sentence.split(' ').map(&:capitalize).join(' ')

Having said that, it's much more likely that a "clever one-liner" would be

    @sentence.gsub!(/\b\w/){|x|x.upcase}

Code like the article's would generally not be the result of cleverness, but of code that has organically mutated into something silly you'd never have written from scratch that way.

Adding to this, I've found from profiling a lot of Python 2.7 code that a lot of those little cute one liner list comprehension expressions are slower than the expanded for loop forms. And also the expanded loops are a lot easier to change after the fact, for example if you want to do two operations on an item in your loop, you then have to expand it out anyway.

If it takes more cleverness to debug code than to write it, and one writes code that is at the limits of one's own cleverness, then clearly one will not be able to debug it.

There are examples of code which is unnecessarily complex, or difficult to read, but this is not a very good example. I'll join the chorus of those who say they don't even know Ruby and yet they could easily figure out what the example was doing.

The most you could could say about this example, IMHO, is that it could be made more readable by breaking it up into more than one line.

The last thing we need is more people writing C code in dynamic languages that have much better and more concise programming constructs. If a programmer does not wish to learn how to use these constructs, that's their business. But I intend to use all the power available to me in whatever language I am programming in -- when it is appropriate, of course.

Just because some programmers don't understand how a particular language construct works, that does not make its use the product of a self-absorbed hacker who thinks he has "superpowers".

Yes, we should all guard against writing code that is difficult to read, but I think such code is rarely caused by the language features we use (although some languages make that easier than others -- I'm looking at you, C++). In fact, you could argue that it is more commonly caused by the features we don't use. Unnecessary verbosity is often the product of someone who is new to a particular programming language, and I think most of us are happy to discover shorter, simpler, clearer ways of expressing things.

In fairness to the author of the article, I think there is a point when you can chain a few too many things together without any intertwined temporary variables, separate function calls, or at least comments, and the reader of your code can get lost. However, in my mind, the code example given hasn't quite reached that threshold yet.

I'm all for clever code when playing around but there are limits to its usefulness. When its over the top, you're not doing yourself or anyone any favors. If something took you a while to come up with, and on top of that its not commented out, its going to annoy the next person, and maybe even yourself when you get back to it 6 months down the road. Well, either annoy or stroke your ego.. Neither contribute much to the quality of the end product.

Here's a quote from Brian Kernighan: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

https://en.wikipedia.org/wiki/Brian_Kernighan

I've come to appreciate simplicity especially when spending a lot of time dealing with other people's code. If you spend most of your time in other peoples code, simplicity will save you endless amounts of time.

I strongly agree with sentiment presented here.

In fact, I actually coined a code metric for this - Jones Complexity, which is the mean operations-per-line (My thesis is that "good" code has a Jones Complexity of less than 8.) For some reason, it looks like code density of this type wasn't ever really considered before. I value readability and maintainability of code even more than I value efficiency and speed (in most cases.)

flake8 extension PoC: https://github.com/Miserlou/JonesComplexity

As no less authority than Brian Kernighan wrote, in 1974, "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

These days I seem to like relating programming to music, so here I go again...

I think virtuosic displays like this are important for the ego of the creators at times, and should be commended as it represents a deep understanding of the craft and leads to even deeper and more interesting and perhaps profitable explorations later on.

But as in music, virtuoso's often, as they mature, realize that they work in ensembles, and that requires a tempering of their prodigious abilities in order for the "whole" to be its best.

In other words, its good to show off, but in the end the true master knows how to temper it for the greater good.

There are a lot of people asserting that, while you should be writing (in part) for readability, you should be able to assume some level of competence on the part of those who follow. I would say that is probably the case but really consideration should be given to who your audience is actually likely to be given the circumstances in which you write.

It is also the case that we often overestimate how understandable things are to others - I write above discussing goals before any compensation for this is applied.

There was an HN discussion quite a while ago on a one-line Game of Life in APL. Much more difficult to understand than using any currently popular language.

Here's the discussion: https://news.ycombinator.com/item?id=1041500

Here's a (different) one-line Life implementation, linked to in that discussion: http://catpad.net/michael/apl/

Yesterday, I was complaining that Rust encourages this sort of thing. In Rust, it comes from the error handling, though. You have to write lots of

    x().and_then(|foo| exp).and_then(|foo| exp)

to handle errors. The imperative form requires a match statement after every function call that can return an error. Or "try!()", which bails with a return. It looks like we just have to get used to this Haskell-like style.

At the very least I'll agree that terseness is not always a virtue, and the time saved in keystrokes or formatting now may be easily lost later when someone tries to figure things out. That said, not all statements of this form are unreadable or incomprehensible, and in some cases there may actually be performance implications as well. As always it is a matter of judgement.

I actually love such code, as long as the vars or funcs are named capitalizeWords. This type of code is the difference between long term investment/cure vs short term gain/steroid. I cannot imagine a boiler plate 'for loop' with assigning and re-assigning and doing all sorts of convoluted branching.

I don't know Ruby, but it looks like a very clear implementation of a function to titlecase a sentence. I am right?

I don't even know Ruby (well I did play with it briefly years ago for a week) and I didn't have any trouble parsing what @sentence was doing. There is undoubtedly much tightly packed cleverness in code but I don't think this is it.

I don't mind the implementation of this code, but 99% likely, it's in a method called `capitalize_sentence` or similar. If that is strewn through the middle of your code, it's probably breaking single-responsibility-principle.

Well, when you kill them, try not to make new darlings in the process.