drw@cullvax.UUCP (Dale Worley) (07/31/87)
It's true that testing someone's ability to read (and write) such monstrosities as Keller's test isn't testing for their ability to read and write readable code. But it is a very good way to filter out people who are (1) a bit dense, or (2) don't have a good grasp of C. After all, how many of the readers didn't catch the extra '*' on 'char ****cpp', or didn't know that an extra ',' is allowed at the end of an initializer list? I've worked with people who were slow, and it's a real pain, and this test would have surely eliminated them, as garlic does a vampire. Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw From the Temple of St. Cathode of Vidicon:
keir@vms.macc.wisc.edu (07/31/87)
In article <1418@cullvax.UUCP> drw@cullvax.UUCP (Dale Worley) writes: >It's true that testing someone's ability to read (and write) such >monstrosities as Keller's test isn't testing for their ability to >read and write readable code. But it is a very good way to filter out >people who are (1) a bit dense, or (2) don't have a good grasp of C. An even better way is to NOT hire people who pass the test, hence filtering out those people who are (1) hung up on esoterica, or (2) don't have a good grasp of programming. Oh, okay -- you can hire those who pass the test, but only if they ask what moron writes junky code like this. "Real programmers never comment -- if it was hard to write, it should be he:e, ane, anet
jcs@odyssey.UUCP (j.c.schwebel) (08/01/87)
I would much rather have an employee who could design, code, and test in a clean, logical, and understandable manner than one who could exactly count the number of asterisks on an obscure line of code. Let the machines do the counting.
oleg@quad1.quad.com (Oleg Kiselev) (08/06/87)
Well, it could have been worse.
On the other hand, if the job involves maintaining code written in this style
(we are talking MANY megabytes here), or rewriting and expanding it, you
BETTER be able not to get lost in the pointer stew. And be able to tell
that a pointer to "char **xxx[]" is a "char ***", and not "char ****".
Because that's the kind of error you will often find in code that was never
linted and constitutes the heart of the product you are supposed to make
(somehow!) work. Remember, there is a chance that the guy who worked on the
code before you was incompetent and got fired for it -- and you are being
hired (in part) to clean up the mess. (I should know -- part of our job here,
aside from developement and posting to the NET :->, is to fix bizzare
"artifacts" left in our products by the "earlier generations")
--
Oleg Kiselev -- oleg@quad1.quad.com -- {...!psivax|seismo!gould}!quad1!oleg
DISCLAIMER: All grammatical and spelling errors are inserted deliberately to
test the software I am developing. In fact, that is the only reason I am
posting. Yeah, that's the ticket! All my postings are just test data! Yeah!!