expressions of disgust or horror. See also {fear and loathing}, {software rot}.
:COBOL fingers: /koh'bol fing'grz/ n. Reported from Sweden, a (hypothetical) disease one might get from coding in COBOL. The language requires code verbose beyond all reason; thus it is alleged that programming too much in COBOL causes one's fingers to wear down to stubs by the endless typing. "I refuse to type in all that source code again; it would give me COBOL fingers!"
:code grinder: n. 1. A {suit}-wearing minion of the sort hired in legion strength by banks and insurance companies to implement payroll packages in RPG and other such unspeakable horrors. In its native habitat, the code grinder often removes the suit jacket to reveal an underplumage consisting of button-down shirt (starch optional) and a tie. In times of dire stress, the sleeves (if long) may be rolled up and the tie loosened about half an inch. It seldom helps. The {code grinder}'s milieu is about as far from hackerdom as one can get and still touch a computer; the term connotes pity. See {Real World}, {suit}. 2. Used of or to a hacker, a really serious slur on the person's creative ability; connotes a design style characterized by primitive technique, rule-boundedness, {brute force}, and utter lack of imagination. Compare {card walloper}; contrast {hacker}, {real programmer}.
:code police: [by analogy with George Orwell's `thought police'] n. A mythical team of Gestapo-like storm troopers that might burst into one's office and arrest one for violating programming style rules. May be used either seriously, to underline a claim that a particular style violation is dangerous, or ironically, to suggest that the practice under discussion is condemned mainly by anal-retentive {weenie}s. "Dike out that goto or the code police will get you!" The ironic usage is perhaps more common.
:codewalker: n. A program component that traverses other programs for a living. Compilers have codewalkers in their front ends; so do cross-reference generators and some database front ends. Other utility programs that try to do too much with source code may turn into codewalkers. As in "This new `vgrind' feature would require a codewalker to implement."
:coefficient of X: n. Hackish speech makes rather heavy use of pseudo-mathematical metaphors. Four particularly important ones involve the terms `coefficient', `factor', `index', and `quotient'. They are often loosely applied to things you cannot really be quantitative about, but there are subtle distinctions among them that convey information about the way the speaker mentally models whatever he or she is describing.
`Foo factor' and `foo quotient' tend to describe something for which the issue is one of presence or absence. The canonical example is {fudge factor}. It's not important how much you're fudging; the term simply acknowledges that some fudging is needed. You might talk of liking a movie for its silliness factor. Quotient tends to imply that the property is a ratio of two opposing factors: "I would have won except for my luck quotient." This could also be "I would have won except for the luck factor", but using *quotient* emphasizes that it was bad luck overpowering good luck (or someone else's good luck overpowering your own).
`Foo index' and `coefficient of foo' both tend to imply that foo is, if not strictly measurable, at least something that can be larger or smaller. Thus, you might refer to a paper or person as having a `high bogosity index', whereas you would be less likely to speak of a `high bogosity factor'. `Foo index' suggests that foo is a condensation of many quantities, as in the mundane cost-of-living index; `coefficient of foo' suggests that foo is a fundamental quantity, as in a coefficient of friction. The choice between these terms is often one of personal preference; e.g., some people might feel that bogosity is a fundamental attribute and thus say `coefficient of bogosity', whereas others might feel it is a combination of factors and thus say `bogosity index'.
:cokebottle: /kohk'bot-l/ n. Any very unusual character, particularly one you can't type because it it isn't on your keyboard. MIT people used to complain about the `control-meta-cokebottle' commands at SAIL, and SAIL people complained right back about the `{altmode}-altmode-cokebottle' commands at MIT. After the demise of the {space-cadet keyboard}, `cokebottle' faded away as serious usage, but was often invoked humorously to describe an (unspecified) weird or non-intuitive keystroke command. It may be due for a second inning, however. The OSF/Motif window manager, `mwm(1)', has a reserved keystroke for switching to the default set of keybindings and behavior. This keystroke is (believe it or not) `control-meta-bang' (see {bang}). Since the exclamation point looks a lot like an upside down Coke bottle, Motif hackers have begun referring to this keystroke as `cokebottle'. See also {quadruple bucky}.
:cold boot: n. See {boot}.
:COME FROM: n. A semi-mythical language construct dual to the `go to'; `COME FROM' <label> would cause the referenced label to act as a sort of trapdoor, so that if the program ever reached it control would quietly and {automagically} be transferred to the statement following the `COME FROM'. `COME FROM' was first proposed in R.L. Clark's "A Linguistic Contribution to GOTO-less programming", which appeared in a 1973 {Datamation} issue (and was reprinted in the April 1984 issue of `Communications of the ACM'). This parodied the then-raging `structured programming' {holy wars} (see {considered harmful}). Mythically, some variants are the `assigned COME FROM' and the `computed COME FROM' (parodying some nasty control constructs in FORTRAN and some extended BASICs). Of course, multi-tasking (or non-determinism) could be implemented by having more than one `COME FROM' statement coming from the same label.
In some ways the FORTRAN `DO' looks like a `COME FROM'
statement. After the terminating statement number/`CONTINUE'
is reached, control continues at the statement following the DO.
Some generous FORTRANs would allow arbitrary statements (other than
`CONTINUE') for the statement, leading to examples like:
DO 10 I=1,LIMIT
C imagine many lines of code here, leaving the
C original DO statement lost in the spaghetti…
WRITE(6,10) I,FROB(I)
10 FORMAT(1X,I5,G10.4)
in which the trapdoor is just after the statement labeled 10.
(This is particularly surprising because the label doesn't appear
to have anything to do with the flow of control at all!)
While sufficiently astonishing to the unsuspecting reader, this form of `COME FROM' statement isn't completely general. After all, control will eventually pass to the following statement. The implementation of the general form was left to Univac FORTRAN, ca. 1975 (though a roughly similar feature existed on the IBM 7040 ten years earlier). The statement `AT 100' would perform a `COME FROM 100'. It was intended strictly as a debugging aid, with dire consequences promised to anyone so deranged as to use it in production code. More horrible things had already been perpetrated in production languages, however; doubters need only contemplate the `ALTER' verb in {COBOL}.
`COME FROM' was supported under its own name for the first time 15 years later, in C-INTERCAL (see {INTERCAL}, {retrocomputing}); knowledgeable observers are still reeling from the shock.
:comm mode: /kom mohd/ [ITS: from the feature supporting on-line chat; the term may spelled with one or two m's] Syn. for {talk mode}.
:command key: [Mac users] n. Syn. {feature key}.
:comment out: vt. To surround a section of code with comment delimiters or to prefix every line in the section with a comment marker; this prevents it from being compiled or interpreted. Often done when the code is redundant or obsolete, but you want to leave it in the source to make the intent of the active code clearer; also when the code in that section is broken and you want to bypass it in order to debug some other part of the code. Compare {condition
