Larry McVoy wrote:
>
> By the way, this sort of thing is a big deal around here, I spend a
> lot of time getting people to do it all the same way. It's worth it.
>
Larry, you can save yourself a lot of trouble, time and money: Create an
indent configuration file and tell your people to use it. That is
exactly why indent was written many years ago.
Better still, change your commit scripts to automatically run indent
when checking files in. This works on private projects - it is not
recommended for a public project like GNU/Linux, unless, Linus would
call a halt - indent all files and then carry on, which I'm sure he
won't do, since it is waaaay too much trouble.
With indent, everybody can be happy: You don't like the curly braces
here but rather want them there? ==> Run indent on your private copy.
BTW, occational windoze users can get the GUIfied 'windent.exe' off my
web site at http://www.aerospacesoftware.com. This presents a simple way to
play around with indent; to figure out exactly what schtooopidttt
switches you need to make the code look the way your SQA dork wants...
Also, if you want the whole kernel to be commented and clickable in
html, 'doxygen' does an amazing job with that, even though the kernel
code is not written with doxygen tags.
Since I discovered these two tools, I totally relaxed about code
formatting, since it is simply not an issue anymore.
Cheers,
--
Herman
> Larry, you can save yourself a lot of trouble, time and money: Create an
> indent configuration file and tell your people to use it. That is
> exactly why indent was written many years ago.
Indent is fine as a first pass, it doesn't handle everything properly.
If it did, I think I would have figured it out by now. And no, I'm
not going to go fix indent, I looked at the problems and the fixes
and decided to pass. Some of them just aren't worth fixing in
indent.
Besides, I really don't believe in giving people crutches, I believe
in teaching them what it is I want and why. That tends to stick.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
I found that if you force people to use indent, by hooking it into the
CVS commit script, they end up writing the code so that it looks exactly
right and indent ends up doing nothing. Somehow people also manage to
learn what not to do, so that indent doesn't screw up!
The trouble with indent is that many combinations of switches causes it
to screw up royally. The documentation is also bad and outright wrong
in some cases. Once you managed to find a workable set of switches, it
is mostly OK. The few glitches are nothing to worry about, but to find
the sweet spot can be tiresome. However, once you got a proper config
file that works for you, all your troubles are over, so it is worth
while experimenting with it a bit.
Larry McVoy wrote:
>>Larry, you can save yourself a lot of trouble, time and money: Create an
>>indent configuration file and tell your people to use it. That is
>>exactly why indent was written many years ago.
>
>
> Indent is fine as a first pass, it doesn't handle everything properly.
> If it did, I think I would have figured it out by now. And no, I'm
> not going to go fix indent, I looked at the problems and the fixes
> and decided to pass. Some of them just aren't worth fixing in
> indent.
>
> Besides, I really don't believe in giving people crutches, I believe
> in teaching them what it is I want and why. That tends to stick.