Live data from Hacker News

Please, kill your darlings

blog.ikura.co

11–20 of 84 posts

Re: Please, kill your darlings

#11
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…

I agree. Someone's "darling" code might be a truly innovative or unique way of solving a problem, and providing enough commentary should help avoid the problems the author warns about.

It's amazing, their whole complaint is solved by proper software development practices - Comment your code.

Re: Please, kill your darlings

#12
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 
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. ;)

Re: Please, kill your darlings

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

Re: Please, kill your darlings

#15
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…

I agree. Someone's "darling" code might be a truly innovative or unique way of solving a problem, and providing enough commentary should help avoid the problems the author warns about.

Not to mention it may be a performance optimization.

Re: Please, kill your darlings

#16
post #3

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.

I don't know Ruby and reached the same conclusion in about 15 seconds. Could be nice to make it a function [or name the results] "capitalizeWords(text)". Possibly adding indentation could help:

    @sentence = @sentence.
      split(' ').
      map!{ |x| 
        x = x[0..0].upcase 
[Edit: Fixed code, thanks knodi123]

Re: Please, kill your darlings

#17
post #11

Earlier quoted context omitted.

I agree. Someone's "darling" code might be a truly innovative or unique way of solving a problem, and providing enough commentary should help avoid the problems the author warns about.

It's amazing, their whole complaint is solved by proper software development practices - Comment your code.

To be fair: What is proper practice, is far from what is common practice

Re: Please, kill your darlings

#18
post #4

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.

Did you try generator expressions as well? I'd hope that the interpreter would manage to make them as fast as the loop form, but...

Re: Please, kill your darlings

#20
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.
Post reply on HN