Michel Fortin Wrote: > >> 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. > > Please, don't make unsupported accusations as an excuse to shoot > people. Instead, you should say what you dislike about Java and explain > why. (My guess is you find System.Out.println too long.) > > I'm tring to see how I can adapt the guidelines to accept this function > ("writefln") and I can't see any sensible rule I could add. Any idea? > > Alternatively, "writefln" could be an exception to the rules, but then > the exception would need a better rationale than "it shouldn't look > like Java". I mean, if Phobos makes unjustified exceptions to its > naming conventions here and there for no good other reason than "it > looks good", it breaks the concistency and makes function names less > predictable and less readable. > > But it'd be easier to rename the functions to fit the convention: > > write -> write > writeln -> writeLine > writef -> writeFormat > writefln -> writeLineFormat > > That way, if someone writes logging functions one day that takes > formatted strings in the same way, he can reuse the convention: > > log > logLine > logFormat > logLineFormat > > instead of "log", "logln", "logf", and "logfln". If you create a hash > function, you can reuse the pattern too: > > hash > hashLine > hashFormat > hashLineFormat > > instead of "hash", "hashln", "hashf" and "hashfln". And it goes on. > > > >> ... > >> > >> 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. :) > > By "thinking twice" you should be able to come with a good > justification; and if you can't then you should follow the rules. > That's fine by me. >
I think the real problem underlying the wish to use writefln versus writeFormatLine (or anything like that), is that C programmers are in the habit of using very short names. But in my personal experience, most languages I use have a short formatted version of write..., probably because it is necessary many times. Although I agree that writefln, if adapted to the convention, should become writeFormatLine, I also understand the clumsiness of writing it. As far as I know, writefln is with us for a very long time. But it doesn't say that it should or should not be changed. I think that no one has been given any thought to it. I want to know: do we use writefln often, or is it just convenience, when writing out a something. I would imagine to have a formatter object that accepts a delegate which writes strings. I would as thus remove writefln, and just have the function write. The formatter object could be reponsible to actually use it, for example: Formatter.out(write, "%s%s", "Hello World", newline) The function "write" can still be used to emit directly, such as: write("Hello world\n") I think this is the real problem of writefln. Not the convention, but the approach.