Naming things in Phobos - std.algorithm and writefln

[Sjoerd van Leent]

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.