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

71–80 of 84 posts

Re: Please, kill your darlings

#71

Post by cookiecaper »

trevyn wrote: post #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? Sur…

Any code whose readability depends on information stored only in your brain is bad code, sorry. Perhaps there are times when bad code is excusable, but there is no argument that such code is high-quality. The best code expresses an idea in the simplest way possible, which is not synonymous with the fewest number of lines possible.

Re: Please, kill your darlings

#72

Post by cookiecaper »

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

I think there's an objective way to resolve a good chunk of this, which is language exclusivity. If the code expresses an idea in a way that a programmer familiar with a similar language can understand without having to refer to the docs, it's great. If the code uses language-specific operators or functions, there needs to be a reasonable justification for it.

This basically means that these keywords and operations are always OK:

  * function definitions

  * if conditionals

  * full for loops

  * full while loops

  * return statements
and these things should only be used when it would be unreasonably intrusive or problematic to perform the same operation using only the above flow control mechanisms:

  * classes

  * lambdas/closures

  * language-specific shorthands like list comprehensions

  * language-specific operator aliases, like
The goal is to keep the program as simple and straightforward as possible. Of course you're going to need some of the things in the second category to do that sometimes. But my opinion is that one should start with the basic building blocks, and if one finds that it will save a lot of effort and time in both reading and writing the code to use one of the secondary things, only then should those things be deployed.

For example, if you're using a lambda, you should have a good explanation for why a function definition wouldn't have worked. "Lambdas take one line and defs take two" isn't a good reason.

Re: Please, kill your darlings

#73

Post by cookiecaper »

JoeAltmaier wrote: post #27
parennoob wrote: post #24

In this thread are literally 300 comments saying "Huh, I don't even Ruby, and I understood it", thereby (in my opinion) completely proving the point . It's exactly because people pull this sort of thing "Hey, it was really easy to understand for me, how about you?" that I have seen developers feel compelled to put clever oneliners in codebases. Clever oneliners that later end up causing problems for whatever unluckly…

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'.

Code should be written in the easiest to understand form that both works and provides the necessary performance characteristics. Often that is the form that "newbies" also find easy to understand, for obvious reasons.

I've used Ruby somewhat actively for almost 10 years now and I still hate it when people barf out a bunch of Ruby-specific shorthand and think they're clever for doing so. Write it in the simplest form that works. I don't care if it takes 10 more keystrokes.

I've seen people write fizzbuzz with lambdas and such thinking that it would signal they're super-serious Ruby all-stars, but all it really does is let me know I should keep my distance, because they're going to be writing needlessly convoluted code.

Re: Please, kill your darlings

#74

Post by mchahn »

trevyn wrote: post #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? Sur…

> I do it because it reduces physical code size

And aren't the number of bugs loosely related to the number of lines of code? A darling has fewer chances of a typo bug.

Re: Please, kill your darlings

#75

Post by sriram_iyengar »

I actually love such code, as long as the vars or funcs are named capitalizeWords. This type of code is the difference between long term investment/cure vs short term gain/steroid. I cannot imagine a boiler plate 'for loop' with assigning and re-assigning and doing all sorts of convoluted branching.

Re: Please, kill your darlings

#76

Post by brbsix »

kylebgorman wrote: post #68
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…

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(" "))

Agreed. My first thought was to use `new_string = long_string.title().replace(' ', '')` or the generator you mentioned.

Re: Please, kill your darlings

#77

Post by djur »

cookiecaper wrote: post #72
jschwartzi wrote: post #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.

I think there's an objective way to resolve a good chunk of this, which is language exclusivity. If the code expresses an idea in a way that a programmer familiar with a similar language can understand without having to refer to the docs, it's great. If the code uses language-specific operators or functions, there needs to be a reasonable justification for it. This basically means that these keywords and operations a…

What about languages like Haskell that don't have for loops, while loops, or return statements? And anonymous functions exist in most languages and cannot be avoided in many of them.

Re: Please, kill your darlings

#78

Post by djur »

cookiecaper wrote: post #51
neilparikh wrote: post #47

Earlier quoted context omitted.

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, t…

For me, readability is about how intuitive something is, how much can be understood with basic knowledge of programming in general and perhaps a quick primer on the specific language. I think this is the best measurement because it emphasizes a reliance on the most commonly used, general concepts, and encourages people to use those unless there's a good reason not to. A side benefit is that the more basic language pr…

Not having touched Python for many years, four things jump out at me:

1) .format, which isn't immediately familiar and doesn't resemble similar string formatters in other languages 2) [1:], which I believe is a string slicing syntax that doesn't resemble similar syntax in other languages 3) Bug: nothing is done with the capitalized words, since the return value is thrown away 4) Bug: the name of the function was misspelled when used.

The last one may seem like a nitpick, but it is true that when you add a name to your code for the sake of clarity, you also take on the additional burden of ensuring the name is used consistently and accurately everywhere. This can be a particular pain in cases where you are generating a lot of uninteresting temporary values -- which is precisely why people end up writing chained function or method calls.

Re: Please, kill your darlings

#79

Post by dllthomas »

mhurron wrote: post #56
prodigal_erik wrote: post #53

Earlier quoted context omitted.

Code that's clear enough not to need a comment is better than code that has a comment. Comments can be outdated or mistaken and they consume screen real estate.

You still need to document intent. No code is self documenting.

In some cases, naming may be sufficient to communicate intent.

Re: Please, kill your darlings

#80

Post by dllthomas »

There are a lot of people asserting that, while you should be writing (in part) for readability, you should be able to assume some level of competence on the part of those who follow. I would say that is probably the case but really consideration should be given to who your audience is actually likely to be given the circumstances in which you write.

It is also the case that we often overestimate how understandable things are to others - I write above discussing goals before any compensation for this is applied.

Post reply on HN