(fwd) article on open source

[jc at trillian.mit.edu (John Chambers)]

Scott Lanning <slanning at buphy.bu.EDU> writes:
	 John Chambers <jc at trillian.mit.edu> wrote:
	 >Au contraire, this is about the worst possible basis for
	 >rewarding  the  programmers.   It is incredibly easy to pad
	 >code to produce a large line count.
	 
	 print
	     'J',
	     'u',
	     's',
	     't',
	     ' ',
	     'a',
	     'n',
	     'o',
	     't',
	     'h',
	     'e',
	     'r',
	     ' ',
	     'h',
	     'a',
	     'c',
	     'k',
	     'e',
	     'r',
	     '.',
	     '.',
	     '.',
	     "\n"
	 ;
	 
	 __END__


Excellent example, for several reasons (though you could have  padded
it by five more lines with the usual "... perl ...").  Writing a long
constant string as a list of single chars is a  nice  way  of  making
sure  that  "complexity  analysis"  gives you a higher score, since a
function call with a long list of args  counts  for  more  complexity
than  the same call with only one arg.  And the spurious __END__ is a
nice touch, too.  It's needed sometimes, so you might as well include
it always.

This is sometimes called "Chinese" coding style, since  Chinese  text
is traditionally written vertically like this. It has become the norm
in much of the corporate world, because it easily leads to high  line
counts. Judicious use of blank lines "for readability" also helps, as
long as you don't overdo it so that it's  obvious  that  you're  just
padding  the  line  count.   Also, put tokens like braces, 'then' and
'else' on separate lines.

There are a lot of other subtle techniques.  I've known a few  people
who never use operators like ++ or +=, since {foo++} gives you only a
single unary operator, while the equivalent {foo = foo + 1} gives you
credit for two binary operators.

With a bit of care, you can not only get a high score,  but  you  can
spread  out  the  code  so much that nobody can ever get a meaningful
chunk into a single window, making your code impossible to read. This
adds a lot of value to your code, on the principle that "I understand
it and you don't, so I must be smarter than you."

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).