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.
Please, kill your darlings
11–20 of 84 posts
Re: Please, kill your darlings
#12It'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
#13I 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
#14@sentence.split(' ').map(&:capitalize).join(' ')
More terse and more descriptive (imo)
Re: Please, kill your darlings
#15I'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
#16Maybe 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.
@sentence = @sentence.
split(' ').
map!{ |x|
x = x[0..0].upcase
[Edit: Fixed code, thanks knodi123]Re: Please, kill your darlings
#17Earlier 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.
Re: Please, kill your darlings
#18Adding 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.