5 ms·
Recombine to avoid naming when naming is hard
- PaulHoule 11y agoYeah, I have been looking at why production rules systems (OPS5, Drools, IBM ILOG, etc.) have not caught on and I think one of the problems is that most of these systems make you give every rule a name, which is like saying every line of source code has to have a name.
- frobaldo 11y agoI've spent half a year of my professional life programming custom business rule engine and my experience aligns with a sarcastic note I've read somewhere: "Business builds business rule engines so they can change their rules and workflows without the need for expensive programmers, but in the end they need to hire even more expensive Business Rule Engine Programmers". Declarativeness of the system was really nice and named rules really made sense, if the actions you can take are really meaningful. It was more like naming every function set while doing FP.
- braythwayt 11y agoI call this "Duck Programming:" https://unspace.ca/dev/2012/duck-programming https://unspace.ca/dev/2012/duck-programming
- stephengillie 11y ago> Naming is hard because it's a different kind of thinking from the rest of programming. We are coding along, in a nice engineering flow, and all of a sudden, we need a nice, human-readable name. We need to find compassion for the reader from within our cold, calculating programmer trance. This is very difficult. This makes me think of prescription drugs, and how they all have 2 names, one for marketing to the public, and one for marketing to doctors. [e.g. "Ask your doctor if Savator is right for you. (Dipromelexeline)"]
- nightcracker 11y agoBleh. I think the software development industry should stop doing such a disservice to itself, and start funding more scientific studies in software development. Random, almost shower-thought hypotheses like 'naming things is hard - we should stop doing it' are given way too much credibility with nothing to back them up.
- braythwayt 11y ago> the software development industry should stop doing such a disservice to > itself, and start funding more scientific studies in software > development. Yes. > hypotheses like 'naming things is hard - we should stop doing it' are given > way too much credibility with nothing to back them up. Also yes, but let's separate generating hypotheses and discussing them from giving them credibility. It's a net win for people to share their shower-time hypotheses with each other. It's a net win for sites like Hacker News to feature them so that the "long tail of thought" can stretch ever longer. But as you say, we need to keep some perspective and grant that these are hypotheses. For example, a lot of times, people try turning a dial to eleven: Long iterations are hard, what's the shortest iteration cycle? What if we try releasing every two weeks? Code review is valuable, what if we review 24/7/365 by pairing or even mob programming? Long methods are hard to understand, what if we make a rule that they can be no longer than five lines? And so forth. And they get good n=1 anecdotal results. My hypothesis is that there's a Hawthorne Effect going on: When you turn a dial to eleven, you find yourself forced to observe and think about what's going on very thoroughly, and in the process of doing so, you get better results. Then you keep doing that, and eventually the new way of doing things is internalized, and you stop being forced to think very hard about things, and you regress to your old level of hand-wavey productivity/quality/whatever. This little pet model of mine explains why things like this keep popping up, why they are often valuable exercises, but also why, as you say, we should do some real measuring before pronouncing that we're DoingItWrong™.
- seiji 11y agomore scientific studies in software development. There's an entire field called Software Engineering. But, it's more fun to just do what feels quick and satisfying instead of binding yourself to processes other people dictated.
- anton_gogolev 11y ago> There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
- king_magic 11y agoPosts like this give the illusion of saying so much, but at the end of the day, they really say almost nothing at all. What actionable advice is this post really giving? What examples is it pointing to to illustrate the author's point? > Use threading. Instead of naming each intermediate value, thread the value through the process without naming it. What does that even mean? To be honest, I'm not even really sure what the author's point is. Naming is hard? Naming is bad? Don't name things? Name everything? It just feels like an abstract nonsense piece.
- userbinator 11y agoWhat does that even mean? It means don't do this: int x = k + 3; int y = v * x; int z = y - foo(); return z; Instead, do this: return (k + 3) * v - foo();
- king_magic 11y agoMakes sense, terribly worded by the author, though. Threading generally means, well threads. Throw the word "process" in there and it makes things even less clear. Also, for the record, I totally disagree with the author on this. This: return (k + 3) * v - foo(); works great, until you need to debug it. Good luck then.
- icebraining 11y agoWhat's the problem? Just put the breakpoint on that line, then check the intermediate values (e.g. with PyDev, you can select parts of the expression to check their results).
- king_magic 11y agoNot every IDE is as helpful or forgiving for that kind of debugging. If you have things broken out, it's much easier to step through the intermediate states of expressions like that, and much easier to tweak when you need to fix something. Having everything together in One Expression To Rule Them All is a code smell, IMHO.
- PythonicAlpha 11y agoI don't agree. I agree, that naming is hard, of course. But I don't agree, that you should avoid it at all costs! Sometimes, the costs are just to high. When by avoiding naming things, you make the program more difficult to understand, you loose much. This could cost you nearly as much, as a bad name and very likely much more than a half-good name.
- mkozlows 11y agoThe article is maybe overblown, but I think there's a good point there. A lot of functionality is one-off stuff that doesn't need to be re-used and won't be, and so trying to come up with a name for a little chunk of code just ends up making the program harder to understand. So, sure, you can write: function processData(err, data) { //blah blah does stuff } db.getData(processData); But it's actually a lot simpler and more understandable if you just write: db.getData(function (err, data) { //blah blah does stuff }); If and when you ever need to break that function out into something re-usable, give it a name then, but don't bother with a name unless you need it.
- codygman 11y agoBut one of those functions processes data and the other gets data.
- Ma8ee 11y agoI hope that the very generic names you have chosen is just for the example, but otherwise that is exactly the type of names that make a codebase incomprehensible. How about something like function CalculateSalesBonus(err, salesmenEmployedByTheLastOfMonth) { // do stuff } which actually contains much more information than db.getSalesmenEmployedByTheLastOfMonth(function (err, data) { //blah blah does stuff });
- greenyoda 11y agoOnce you turn processData() into an anonymous function, how could you write a unit test for it?
- gweinberg 11y agoSounds like terrible advice to me. Names make it a lot easier to keep track of things. Even a meaningless name is generally better than no name.
- natch 11y agoThis article is taking its readers down a really dumb path. "At all cost" even at the cost of readability? It also ignores the possibility that good names do exist, and that they contribute a lot to maintainability. The suggestion made is when a good name "cannot" be found, you should try to avoid naming. No. Bad suggestion. When a good name cannot be found, you probably have muddied up the problem, and should rethink it. Or try harder to find a good name. Also re-examine your ideas about what is "good", avoiding false metrics such as "names need to be under three characters long".
- dasil003 11y ago> When a good name cannot be found, you probably have muddied up the problem, and should rethink it. Absolutely. Software as we know it could not exist without abstration, and abstraction can not exist without names for things. Sometimes a new name is required because a particular concept or application is relatively novel, but if you decline the challenge of naming it then progress stops immediately. No future applications will be built on top of an unnamed abstraction.
- abrgr 11y agoAs I read it, this article is, quite intelligently, recommending (or at least a consequence of their logic would be a recommendation for) using a point-free style wherever it's applicable. Programming is, primarily, data transform and a focus on the transform, rather than naming the intermediate data items, is typically a lot nicer to read. Name your functions, avoid naming your data if you can.
- haberman 11y agoThe Phil Karlton quote is fun and clever. But people should not mistake it for actual wisdom. Read this paper (for example) and tell me that naming and cache invalidation are harder than that: http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf
- AdrianRossouw 11y agoi prefer the varian't that says : There are only 2 hard problems in programming: 1. naming things. 2. cache invalidation. 3. off by one errors.
- andallas 11y agoI see this same issue come up from time to time and I always recall a little saying I heard (unfortunately I don't remember the source). "If you are having trouble naming something, then you don't fully understand that something." What I get from that saying is that if I have a function that I am struggling to name, it means that I don't fully understand the problem, and there's a good chance that it is doing to many things. Keep your functions to performing a single task, so they have just that one purpose, then name it after what it does. This improves readability and makes naming things much easier. You have a variable you can't name, well, what data is it actually holding? If it is holding more than one piece of data (reused) then you are doing something wrong or very hacky. Follow the same rule as with functions. Keep your variables to holding just one specific piece of data, and name it after that. Both of these rules not only make naming things much easier, I've found they produce much more readable code, easier to debug code, and generally much less bugs in the code.
- ggchappell 11y agoThere are some good thoughts here, but it isn't all quite coherent yet. So, to add my 2 cents: There are basically two reasons to name things. 1. Because something is lacking in either the syntax of our PL or our skill in coding, so that we end up giving something a name, when it does not really need one. 2. As a handle on some abstraction, indicating what it is for. When #1 is the issue, names are best avoided. When #2 is the issue, names are a Good Thing, but a poorly chosen name can be very harmful.
- vmorgulis 11y agoIt is similar to sociology or psychology problems. They use models or paradigms with lot of names mainly because of lack of theory than can connect human sciences to mathematics or physics. In each model they can solve some aspects but the whole. It looks like zoology or biology before DNA.
- harel 11y agoIgnoring the fact I think this is bad advice, I actually find 'naming' things to be good fun. I enjoy finding names for projects. Sometimes I won't write the first line of code until I either find a permanent name for the project or a good enough temporary one to name the code directory. Can't reason this really, but its definitely important to me to know I'm working on a named project.
- nine_k 11y agoWhen naming things is hard, it's exactly the reason why you should stop, think, and find a good, fitting name. If you have hard time naming something in your code, chances are it's because you have a nebulous understanding of that elusive thing. This is obviously bug prone. It's usually a good idea to spend a few minutes searching for a good, precise, descriptive name, and add enough comments if the entity being named is not a temporary variable. Doing so not just makes later code maintenance easier, it tidies up your understanding and can even lead to finding a bug or another problem (happened to me more than once).
- tetha 11y agoIn my team, we're starting to take naming problems as a very, very red flag. Especially if the name makes sense for half the team, and no sense for the other half. In the most extreme case, we've taken like half a day off with the entire team to discuss just about everything. We went from a name to one of our software to our architecture to our domain and it was just half a day to a day of discussion and merging understandings. After this, we spend another half a day to a day just cleaning up a huge mess of potential bugs, and after that, naming was simple. And now, a few month later, hell it was worth it.
- AnimalMuppet 11y agoThere are times to break some code out into a separate function, even though the function will only be called in one place, simply because the name of the function will make it more clear what the code is doing. Note well: This is not "always". Do not do this with every single line of your program. This is not even "often". But once in a while, it can dramatically improve clarity.
- a3n 11y agoGood idea, sometimes. On the opposite end, I will sometimes go out of my way to name something when there isn't an immediately apparent need. Also naming can often shorten up a long line. Trivial example: In [15]: SortByLen = lambda x: len(x) In [16]: SortByLast = lambda x: x[-1] In [17]: listOfInterest = ['123', '234', '432''12', '12345', '123'] In [18]: sorted(listOfInterest, key=SortByLen) Out[18]: ['123', '234', '123', '43212', '12345'] In [19]: sorted(listOfInterest, key=SortByLast) Out[19]: ['43212', '123', '123', '234', '12345']
- deleted 11y ago[deleted]
- castratikron 11y agoJuliet said it best; What's in a name? That which we call a rose by any other name would smell as sweet.
- Ma8ee 11y agoI agree with those that thinks this is horrible advise. If the function of what you are naming isn't clear and precise it is of course hard to give it a clear and precise name. But the solution isn't to avoid giving name. The solution is to make sure that function of what you are naming is clear and precise. That is the hard part, but must not be avoided.
- dang 11y agoThreads like this are so sensitive to initial conditions. When one initial condition is a dumbed-down, provocative title, we nearly always get a dumbed-down and provoked discussion. That's too bad, because there are some good ideas here. We changed the title to a representative sentence from the article.
- deleted 11y ago[deleted]
- CmdrKrool 11y agoThis sounds like the currently fashionable argument to avoid comments because they can be inaccurate, go out of date, and after all the code itself should be self-explanatory - just shifted a bit further up the chain.
- k__ 11y agoFP isn't a golden bullet, but at least it often helps to get rid of those temporary variable names that clutter the code.