Live data from Hacker News

Please, kill your darlings

blog.ikura.co

61–70 of 84 posts

Re: Please, kill your darlings

#61

    @sentence = @sentence.split(' ').map!{|x| x = x[0..0].upcase 
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.

Re: Please, kill your darlings

#62

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 (especiall…

I consider the priority to be to help maximize the productivity of the next (competent) programmer that touches the source.

Optimizing my source for incompetent programmers isn't something I care about.

Additionally, optimizing the source to aid understanding for competent programmers is only something I care about to the extent that it doesn't otherwise impair their productivity.

Code spread over five lines instead of one might be easier to read, but not necessarily easier to edit.

Code should be written to be easy to edit first, and comments used to patch up where that conflicts with making it easy to understand.

Re: Please, kill your darlings

#63
post #54

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.

I've found I often prefer reading and writing the actual guts of the inlined function, over naming it something semantically significant. It's often difficult to craft a good English name for the function. It can inhibit understanding to have to change context to learn what a function does by looking at its code (OtherModule.capitalizeEveryWordInThe). There can be small semantic variations (capitalizeEveryWordInThe,…

Yeah, I guess it depends on how many instructions are in that one liner and how intelligible it is three years from now. The expressiveness of the language also helps a lot.

a.map { x in x * 3 } is probably intelligible enough (in Swift) so no need for util.multiplyEveryElementBy3(a)..

Re: Please, kill your darlings

#64
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?"

Re: Please, kill your darlings

#65
post #2

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 b…

Why use "map!"? you're already working on a disposable copy of your data, there's no need to mandate "in place". Could this be done with one gsub regex? why use "x = x[0..0].upcase And why not use the already-written "titleize" function, which capitalizes the first letter of each word? Frankly, I think your darling needs to be put out of its misery. :-)

> already-written "titleize" function

Which is a function provided by ActiveSupport. It's not part of Ruby itself.

Re: Please, kill your darlings

#66

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 (especiall…

We also have nice wide monitors. Tons of short lines with unnecessary names tying them together is usually less clear though, and less robust. (Not that there are only two solutions either.)

Target semi-skilled developers and up, format the code for domain readability and ignore rules that get in the way.

Re: Please, kill your darlings

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

Re: Please, kill your darlings

#68

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…

In Python, I'd use use a generator comprehension and str.title(). Assuming I haven't screwed up, then it's just:

    new_string = "".join(word.title() for word in long_string.split(" "))

Re: Please, kill your darlings

#69

Earlier quoted context omitted.

Oooooor, its not a 'clever one-liner'. Its just a piece of code. Which, in its native environment e.g. Ruby is what you're expected to understand to be a journeyman of the trade. The code is not written for newbies. It never will be. That's why they're 'newbies' and not 'professionals'.

As I said, until it hits some kind of edge case. Again, I'm not trying very hard here, but this oneliner doesn't give the expected output if your sentence has a string like "æsir". irb> @sentence = "\u00e6sir are gods" => "æsir are gods" irb> @sentence = @sentence.split(' ').map!{|x| x = x[0..0].upcase "æsir Are Gods" (Expected output being "Æsir Are Gods") If you want to understand why this is failing, the code I ga…

Its all a matter of what gets the algorithm into your head most clearly. If extra names and steps do it for you, then cool. But at some point extra names get in the way - they can suggest the wrong thing (what was intended but not what is actually happening). That's how troubleshooting goes astray.

Re: Please, kill your darlings

#70
post #14

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)

  titleize = ->(sentence) { sentence.split(' ').map!{|x| x = x[0..0].upcase 
:'
Post reply on HN