Alexander Klenin wrote:
> Is there any coding style guidelines for TortoiseSVN?
No, there is no formal guideline. It just hasn't been
an issue so far because Stefan Küng was (and still is)
by far the main code contributor. Maybe that will change
in future. I, personally, don't think we need a
discussion right now.
The only informal rule that actually affects readability
is where you put the brace opening a scope. We put them
on a new line. (K&R's style would be just as good, but in
TSVN people are simply not used to it.)
> Most of them can be glanced from existing code, but, for example, I
> just found out that Stefan prefers class member functions to file
> scope functions. If I would know that, surely I would code it
> according to his preferences ;-)
And there are at least two Stefans to chose from ;)
Free functions may raise the argument of "that's not OOP"
while they are actually improving encapsulation. On the
other hand, they have some (minor) technical issues.
TSVN is not very complex w.r.t. it's internal code /
class dependencies (the complex use-case makes designing /
writing TSVN hard). AFAIK, scoping issues have never been
So, no big deal here. Member functions should be prefered
just to be consistent with the rest of TSVN.
> On a related note, is it really necessary to parenthesize even single
> variables and function calls in inside conditionals? For example is,
> if ((!bLogRes)&&(!m_path.IsUrl()))
> really preferred to
> if (!bLogRes && !m_path.IsUrl())
We don't overload the operator!() to mean something different
than !x <=> x == NULL. And, as a general rule, one should keep
expressions short. From my point of view, there is no reason
to emphasize the use of the ! operator nor to preserve operator
preference "just in case that thing gets more complex".
Personally, I don't place brackets around negations. Binary operators
always get their brackets, except for assignments. To structure
may code, I prefer spaces and space lines.
> I realize this topic is highly "flammable", so I will follow whatever
> guidelines are accepted, just wanted to re-confirm unusual ones.
The only important rule we tend to violate is "don't copy'n'paste".
Patches are welcome ;).
Received on Tue Sep 4 11:12:28 2007