Some discussion has already been made in the other sections regarding how long each line of BASIC depending on if it's a PUR-80, PUR-120 or EXTREM-256 and while I was interpreting the Rules as count the number of keypresses, it's open to interpretation because BASIC tokenises Keywords, so classic commands like PRINT which contain 5 Characters, is tokenised to a Single Byte (or Character).
However, I recently discovered while coding with Locomotive BASIC on my Amstrad CPC, a character line could be more than the number of characters typed when I made a small routine which obtains the values that Locomotive BASIC stores before the beginning of each line:
60000 a=&170
60010 v=PEEK(&170)
60020 n=0
60030 FOR l=1 TO 10
60040 PRINT v
60050 n = a + v
60060 a = n
60070 v = PEEK(n)
60080 CALL &BB18
60090 NEXT lIn Locomotive BASIC programs begin at &170 and this is where the 1st Line Length is stored into the 'v' variable, the 'n' variable is used to add the existing address (&170) with the length stored in 'v' and this then points to the address of the Line Length for the 2nd line and so on. CALL &BB18 towards the end of the code is the Amstrads way of Wait for Keypress, it's not really necessary here has the code only displays 10 Lines and their lengths, but kept in it so it doesn't throw off 10 Lines at Once as I'm not printing the Line Numbers.
I feel somewhat foolish I started this discussion because I felt people were asking if they were meant to be counting the Tokens per line or the number keypresses. The code I posted above actually showed that if you had Locomotive BASIC, then a Line Length could actually be longer than the number of characters pressed, though it could also be shorter if a lot of Tokenised Command/Fuction statements were used (which is what Locomotive BASIC does).
I'm familiar with the abbreviated tricks Atari BASIC used which came from the early Tiny BASIC (possibly Palo Alto) due to the short amount of memory (~4kb) Microcomputers had in the mid 70s, the TRS BASIC also adopted that approach despite being Microsoft, when the Amstrad came along in 1984, machines had 64k and could simply had any Command or Function represented as a Byte. Things like PRINT can still be represented as a '?', apart from that it's Control Codes and using the Copy Cursor to insert Characters into a String instead of using CHR$() to abreviate.
Atari BASIC (and some other flavors) also tokenizes the intructions and other reserved words, as well as variable names through an internal table and numbers into a floating point notation. Then, the tokenized lines usually use less bytes than the source, but if the line has many numbers and formulas, it might be longer, because any number like 0 or 1 requires exactly 6 bytes each in the internal storage.
But that is only a technical info, as the soul of this contest, AFAIK, is that the printed source listing should have a maximum length. 120 chars was the original category because it was the longest "logical" line (3 "physical" lines of 40 chars in the screen) that could be typed in the Atari while entering a program from scratch.
In Atari BASIC, instructions can be abbreviated to save typing and include more statements in the listing, so "PRINT" (5 chars) could be abbreviated to "PR." (3 chars including the dot) or the special case of just "?" (1 char). "GOTO" can be typed as "G." to save 2 chars, but "GOSUB" as "GOS." saves only 1 char. "IF" cannot be abbreviated because "I." is used for "INPUT",and it wouldn't save any typping anyway. Also, most of the spaces between line numbers, instructions and variables or constants can also be omitted, helping in the save of space. I invite you to visit my page with a compacted view of the source listing of all Atari PUR-120 entries from 2016. You can find some easy-to-read listings mixed with extremely abbreviated programs. All those special chars inside string constants are just data to set up bitmaps for sprites or other graphical elements; they are neither BASIC tokens nor hidden setup code.