Michel Fortin wrote: > In std.algorithm, wouldn't it be clearer if "splitter" was called > "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function > shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps?
This is a specious argument. splitter's only purpose is to return an instance of a Splitter struct. You can't call it "splitLazily" or "splitLazy" because that implies that the function is doing work, when it really isn't. Following this line of reasoning, all structs should be renamed to verbs. "makeSplitter" is OK, but needlessly verbose. I think when you have a function whose only purpose is to construct something, or is strictly or conceptually pure, it's OK to use a noun for its name. > And what about the "array" function? Wouldn't it be clearer if it was > "toArray" so we know we're preforming a convertion? Same reasoning as above. toArray is also fine; it's possibly more in line with other conversion functions. > As you know, I tried to write some guidelines[1] for naming things in D. > Those guidelines looks well at first glance, but then you look at Phobos > and you see that half of it use some arbitrary naming rules. Take > "writefln" for instance: following my guidelines (as they are currently > written) it should be renamed to something like "writeFormattedLine". > > [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines> I think that's a problem with the guidelines. Anyone trying to turn D into Java should be shot. It's not clear what "fln" means, true... until you look up ANY output function with a f, ln or fln suffix and then it's obvious. > ... > > What does everyone thinks about all this? I think it's a good idea to have a good style guide; but rules only exist to make you think once before you break them. :)
