4
\$\begingroup\$

It's accepted practice to include non-standard compiler or interpreter flags in a program's byte count (most often used with Perl and Ruby, to run the program in an implicit I/O loop - but there are other use cases). However, I can't find any information about how exactly we count these, and if there is no definitive reference for this on meta, it's not exactly an objective scoring.

Several questions come to mind:

  • Most flags require a leading - or --. Should these be included in the count?
  • Should spaces between multiple arguments be included in the count?
  • If we don't count the spaces, then consider that often -option=5 is equivalent to -option 5. In such a case, should the = be counted?

What are our rules (or should our rules be) for counting command-line arguments given to compilers and interpreters?

\$\endgroup\$
0

1 Answer 1

0
\$\begingroup\$

Proposed Rule

Non-standard compiler or interpreter flags should be added to the program's total byte count. Dashes and spaces (including leading spaces) should be included as well.

Example

In the example below, -nonStandardOption 3 would contribute 21 bytes towards the final byte count of the submission. Notice that the space in front of the dash is included.

Compile with myCompiler myProgram -standardOption 1 -nonStandardOption 3

Philosophy

The large majority of users here do not mess with compiler flags at all. Requiring users to count them would be annoying. To make things easier for the majority, standard compiler flags should not count.

A small minority of users do mess with compiler flags. There is probably some potential for abuse. To circumvent that, every single character added as a result of using a non-standard flag should count. That includes spaces and dashes.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .