Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please, kill your darlings

blog.ikura.co

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Please, kill your darlings

#41

Post by ludamad »

mmastrac wrote: 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'd wrap it in a function called capitalizeWords and be done for the day. I also had 0 problem understanding the meaning of this line. If your code base is consistently made of small functions that look like this I actually don't see a major readability issue. (The article remains very valid)

Re: Please, kill your darlings

#42

Post by reddit_clone »

greydius wrote: post #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.

Yes! I was scrolling down looking for this.

Long long ago when I encountered the string copy idiom in C 'while (s++ = t++)' for the first time, it left me scratching my head for a bit. Then it becomes a part of your vocabulary.

Native idioms make communication better.

People often misunderstand 'basic' for 'simple'.

Re: Please, kill your darlings

#43

Post by 123jay7 »

ludamad wrote: post #41
mmastrac wrote: 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'd wrap it in a function called capitalizeWords and be done for the day. I also had 0 problem understanding the meaning of this line. If your code base is consistently made of small functions that look like this I actually don't see a major readability issue. (The article remains very valid)

Pero ¿qué pasa con tu madre ? (But what about your mother?)

Re: Please, kill your darlings

#44

Post by Mizza »

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

Re: Please, kill your darlings

#45

Post by Kenji »

mmastrac wrote: 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 haven't written a single line of Ruby in my life and I guessed that it would do that. While I 100% agree to make code readable, maybe this darling was a bad example. And yes, a comment would help with the problem of not understanding it.

Re: Please, kill your darlings

#46

Post by cubano »

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.

Re: Please, kill your darlings

#47

Post by neilparikh »

cookiecaper wrote: post #34

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…

Something like the following:

   capitalize = lambda word: "{}{}".format(word[0].upper(), word[1:])
   new_string = ' '.join(map(capitalize, long_string.split(' ')))
or:

    new_string = ' '.join(["{}{}".format(word[0].upper(), word[1:]) for word in long_string.split(' ')])
is much clearer and simpler to me, because it explains the intention of the code: split the string into words, map each word to it's capitalized version, then join it again. With the loop, I have to mentally "run" the code to realize that the for loop and append are to go through the split version and add the converted words to a new list.

Obviously, this is a pretty subjective topic, and which version you prefer will depend what you're familiar with/the languages you use.

Re: Please, kill your darlings

#48

Post by knodi123 »

mmastrac wrote: 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. :-)

Re: Please, kill your darlings

#49

Post by jqm »

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.

Re: Please, kill your darlings

#50

Post by knodi123 »

pacala wrote: post #16
d883kd8 wrote: 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]

you want the . at the end of the line, so the interpreter knows to expect a continuation.
Post reply on HN