more about programming style

[Richard Welty]

> did, and wouldn't ignore it.  As for the comments (not made by DHowell,
> I'm just concatenating followups) about experienced C programmers, how
> many people put non-experienced C programmers on a big project?  If
> they don't know a language, they shouldn't be mucking with the code!

The world would be an extremely nice place if you could always get
experienced C programmers when you need them.  But consider the following:

My company has three large projects right now - the two older ones are
written in an old Fortran preprocessor called Pixel, and the newer one is
written in VMS C.  Suppose that we have an excess of manpower on a Pixel
project, and a critical need on the C project.  Should we lay of a Pixel
programmer who is not necessary and hire an experienced C programmer?
That is lousy labor relations.

Suppose we start converting one of the Pixel projects to C (something that
is being considered).  Should we fire all the Pixel programmers who
understand the application, the algorithams, and the concepts, even though
they have been with the company for years, and hire experienced C
programmers to replace them, even though the C programmers know
nothing about the application, etc?

I am not arguing against the use of "i++", and am not too bothered by
assignment to a file pointer inside an if.  On the other hand, I used to
write assignments in if statements a bit.  I stopped about 6 months ago, and
a month ago I went through and ripped all the old ones out of my code.  Why?
Because I felt that it took too much effort to read my own code.  It isn't
that I can't understand the construct, hell, I wrote it.  The problem is
that I have better uses for my time than decoding stuff that can be easier
to read.
-- 
				Rich Welty

	"Here young Walter is remembering his early days on the
	 planet Krypton, with his father Jor-El Cronkite"
					- David Brinkley, on SCTV

	CSNet:   weltyrp at rpi
	ArpaNet: weltyrp.rpi at csnet-relay
	UUCP:  seismo!rpics!weltyrp