cmpilato@collab.net writes:
> While working in the FS code, I noticed that there are several
> question functions with return values of 'int' as opposed to the
> (IMHO) more semantically accurate 'svn_boolean_t'. Any comments about
> this sort of thing? I'm tempted to blast through there and change
> them, but am willing to live with it if there is a sound reason behind
> the status quo.
It's all the functions, in fact. I just said to Karl on the phone,
essentially, "The reason behind the status quo is that y'all are
right, and I'm wrong, but I will revert any change that introduces
svn_boolean_t into the filesystem, because I am an asshole."
Here is the honest truth: I find svn_boolean_t, TRUE, and FALSE harder
to read than `int', 1, and 0. You can't use C without knowing that
C's boolean values are really integers; these macros simply introduce
another layer of indirection between the reader and the code's
meaning. Practically every package out there introduces its own
boolean type, and defines its own named constants for true and false.
So when I'm reading code, I'm internally converting all these slightly
different forms into the canonical form: zero and non-zero.
When I read code which just uses zero and non-zero directly, I breathe
a sigh of relief. It's like the difference between using good old
char *'s for strings and some opaque datatype --- instead of having to
go find the accessors and make sure they do what you expect, you can
just say "ahhhh" and know what's going on.
svn_boolean_t does provide the benefit of being a form of
documentation for arguments. But the function's description should be
telling you that anyway. The fact that something's boolean doesn't
tell me what it does, or the sense of the value (what true means,
vs. what false means) --- I need to check the docs.
At an emotional level, svn_boolean_t smacks of an impulsive urge to
abstract and name "cool" things. It seems amateurish, like people
still so amazed by the filesystem that they choose filenames ending in
".file". But I don't expect that to persuade anyone.
That explained, I'm going to back off, and say that, as long as folks
understand that I honestly believe it makes the code less readable, if
you all really think that svn_boolean_t is the best way to go, I won't
fight it any more.
Received on Sat Oct 21 14:36:23 2006