J
Jon Masters
Guest
Hi there,
I would like advice on VDHL source code beautifiers.
Cheers,
Jon.
I would like advice on VDHL source code beautifiers.
Cheers,
Jon.
N
Nial Stewart
Guest
Jon Masters <jonathan@jonmasters.org> wrote in message
news:vpcpif664t54d5@corp.supernews.com...
They're a pain in the arse
In a previous contract I was working in a multi engineer team,
any one of who could be asked to fix problems in any source
file.
One guy would automatically run the emacs beautifier on any
source code as soon as he'd checked it out, work on it
then check it back in. (Only 1/3 of the team used emacs).
To anyone consequently doing a diff on his version and the previous
one it looked like the whole design had changed instead of
the line or two he'd altered.
If the diff tool had been configurable to ignore whitespace this
might have been a bit better, but there would probably have been
other changes to cloud the issues.
While I'm on this subject, someone else used to move big chunks
of code about to where he thought they should go, even when doing
minor changes to the source. This had the same affect as above when
later doing a diff.
I'd say
1) Learn to write clear, structured commented code. Look at as many
different peoples as you can and copy the one that looks right to
you. If you've a sytle guide stick to it.
2) If you're editing someone else's source code stick to their style
while you're doing it, especially for small changes (as recommended
by Jack Ganssle, http://www.ganssle.com/ although don't ask me exactly
where).
Nial Stewart
------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk
news:vpcpif664t54d5@corp.supernews.com...
They're a pain in the arse
In a previous contract I was working in a multi engineer team,
any one of who could be asked to fix problems in any source
file.
One guy would automatically run the emacs beautifier on any
source code as soon as he'd checked it out, work on it
then check it back in. (Only 1/3 of the team used emacs).
To anyone consequently doing a diff on his version and the previous
one it looked like the whole design had changed instead of
the line or two he'd altered.
If the diff tool had been configurable to ignore whitespace this
might have been a bit better, but there would probably have been
other changes to cloud the issues.
While I'm on this subject, someone else used to move big chunks
of code about to where he thought they should go, even when doing
minor changes to the source. This had the same affect as above when
later doing a diff.
I'd say
1) Learn to write clear, structured commented code. Look at as many
different peoples as you can and copy the one that looks right to
you. If you've a sytle guide stick to it.
2) If you're editing someone else's source code stick to their style
while you're doing it, especially for small changes (as recommended
by Jack Ganssle, http://www.ganssle.com/ although don't ask me exactly
where).
Nial Stewart
------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk
E
Eric Smith
Guest
"Nial Stewart" <nial@spamno.nialstewart.co.uk> writes:
the guy to be drawn and quartered. It is NEVER acceptable to reformat
an entire source file when making minor modifications, and usually not
even when making major mods.
In the places I've worked, this would have been sufficient grounds for
the guy to be drawn and quartered. It is NEVER acceptable to reformat
an entire source file when making minor modifications, and usually not
even when making major mods.