This seems like its trying to force advice for one domain to another when its not appropriate.
I disagree strongly with one or two of the rules. But an even bigger problem is that some (or even most) of the advice either has little value or doesn't really apply to programming. In english, shorter is better, but I'd much rather a longer class name that I can understand than one that's abbreviated to the point where I am forced to look up what its doing. A good rule of thumb that I try to follow is that for the most part, your code should be self explanatory (comments should cover the rest). We have these rules in programming for how to write variable names, and they're better than the ones in that slide. Another rule, that trumps any other is consistency. If you're working on a project that uses the passive voice (which I think works better for some cases) then use that. The nature of programming is different than natural language writing, and so it makes more sense that these rules that are trying to be transferred over are ill equipped to do so.
I mentioned that some of the things just don't make sense As an example, this was one of the slides, "when writing a novel a writer should create living people; people not characters. A character is a caricature." What does this mean? Its ironic that the slide preaches being short and to the point, and yet is bloated with abstract fluff.
This. Some of the advice only works out of context, for example:
> What's an appointment_list? A calendar
No. Chances are that "appointment" is already a thing in your domain language -- the language you'd use to talk to your customers and stakeholders -- and so appointment_list is a much clearer name than calendar, as long as we make the reasonable assumption that it names a collection of appointments.
None of the examples of just using a single word seemed like improvements to me. appointment_list to calendar was by far the worst—calendar can mean a lot of things, and a list of appointments was not even the first thing that comes to mind for me—but in all of the cases the single word meant something significantly different than the thing it was replacing.
> the advice either has little value or doesn't really apply to programming
When I give this talk, I make this clear. I agree. The point is that there's a lot more good advice from writers over the fine details of prose than there is from coders about fine details of code, such as naming. In the talk, I conclude that the advice from writers is entertaining, but not really relevant, but that it can inspire us to try to come up with our own guidelines for naming.
> We have these rules in programming for how to write variable names
Not enough. Also, they tend to be badly written and lack humour. But please share your favourites.
> when writing a novel a writer should create living people; people not characters. A character is a caricature
This is a digression from coding to functional design, in which 'personas' can be a useful refinement of the concept of an anonymous 'user'.
I disagree strongly with one or two of the rules. But an even bigger problem is that some (or even most) of the advice either has little value or doesn't really apply to programming. In english, shorter is better, but I'd much rather a longer class name that I can understand than one that's abbreviated to the point where I am forced to look up what its doing. A good rule of thumb that I try to follow is that for the most part, your code should be self explanatory (comments should cover the rest). We have these rules in programming for how to write variable names, and they're better than the ones in that slide. Another rule, that trumps any other is consistency. If you're working on a project that uses the passive voice (which I think works better for some cases) then use that. The nature of programming is different than natural language writing, and so it makes more sense that these rules that are trying to be transferred over are ill equipped to do so.
I mentioned that some of the things just don't make sense As an example, this was one of the slides, "when writing a novel a writer should create living people; people not characters. A character is a caricature." What does this mean? Its ironic that the slide preaches being short and to the point, and yet is bloated with abstract fluff.