3 ms·
My favorite aesthetic on naming things is to try to avoid it. Evidence that this is on the right track: - Refactoring is often for eliminating temporaries, or
by akkartik 16y ago
My favorite aesthetic on naming things is to try to avoid it. Evidence that this is on the right track:
- Refactoring is often for eliminating temporaries, or for segregating them into their own call.
- A more functional style leads to fewer intermediate variables.
This isn't a rule, or a metric to be optimized to the exclusion of all else. Often the way to clean up code is to get rid of names that don't help you read, coalescing code blobs, until new names occur to you. Then you tease out code blobs again.
- Peaker 16y agoNames are great places to put documentation. Documentation in comments isn't as likely to stay up-to-date. If your names are merely for binding (e.g: f(x) = .. x ..) and don't contribute much, then getting rid of them can be helpful. In Haskell, you can use "points-free" style to get rid of names like that. For example, you can replace: f x = 1 + 2 * x With: f = (1+) . (2*)
- joe_the_user 16y agoThat's a nice simple explanation of the points-free style, thanks! But still, I don't feel like this approach would become useful unless/until you reached the point that it could condense a two-line formula into one line (ei, five or six applications further). I strong suspect that in that case you'd have the kind of formula you only grasp at a glance after you'd working with it intensively for a while. And this gets into the realm of "write only code" - code too compressed for anyone but it's original author to approach.
- iman 16y ago"There are only two hard problems in Computer Science: cache invalidation and naming things." -- Phil Karlton
- NickPollard 16y agoI've only heard the version: "There are only two hard problems in Computer Science: cache invalidation, off-by-one errors and naming things."