Please, kill your darlings
blog.ikura.co
Please, kill your darlings
1–10 of 84 posts
Re: Please, kill your darlings
#2I'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 Re: Please, kill your darlings
#3Maybe 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.
Re: Please, kill your darlings
#4Adding 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.
Re: Please, kill your darlings
#5[deleted]
Re: Please, kill your darlings
#6The 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.
Re: Please, kill your darlings
#7I'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.
Re: Please, kill your darlings
#8At 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.
Re: Please, kill your darlings
#9Maybe 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 have written my fair share of ruby and yeah, that line didn't take superpowers. The point of the article is still valid, though.
Re: Please, kill your darlings
#10The 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…
It's about clarity, if you reduced all those lines to a single understandable line of code, that's great, if you obscured logic by using a one-liner, I'll say it was not an improvement, but it is indeed a thin line