Yakk wrote:There should not be a space between the * and the p on the variable declaration.
But what if putting spaces on both sides is designed to annoy adherents of both Type* p
and Type *p
Flumble wrote:I'd expect in a software company that there'd be such a code formatter though.
I wouldn't; I doubt most companies would. It's sort of a fantasy of mine where everything would be standardized to a specific style on commit, and then on checkout you could automatically transform it to whatever you
like. Then heathens that like 2-space indents
could be happy as well
as God's chosen (I am
in the religious wars subforum, right? O:-)).
But instituting this on an existing project would be hard I think, because you'd have a commit that is just formatting and that would break lots
of tools. For example, we use Subversion. svn blame
doesn't seem to have an option to ignore whitespace changes, so that'll give you the reformatting commit. And what about branches? You can
tell svn to ignore whitespace changes when merging, but I can also imagine if this goes wrong it could easily cost hours or days. We have both Trac and ViewVC for repo browsing; Trac nicely offers a toggle for ignoring whitespace, but ViewVC, from what I know, doesn't. There is a configuration option, but that's global. diff
has options for ignoring whitespace changes, but they're off by default. (You could say "use better tools" but I don't think that's a good argument here for a few reasons, as much as I'd love to switch to Git or Hg, for reasons I'm too lazy to type out now.)
I was going to highlight an example of a file in our codebase that, mostly through historical and organizational accidents, has some really terrible formatting (e.g. mixed 2 & 4 character indents, sometimes within a function). I've been really tempted to just run indent-region on that file, but I can't help but think I don't know how much that would screw up merging etc.; but after thinking about it I think I'll at least investigate it.
See if I can figure out how many branches have changes to that file and how extensive they are... it might be worth it there.
(And incidentally, when I wrote "But I'm not sure I want to debug that now..." I knew I was lying and would figure out where NULL was coming from, and I did. Well, not lying, because I really didn't
want to debug it... but I didn't not
want to debug it ever more.)