-2
\$\begingroup\$

We need a definition of comment. I have seen challenges that need comments or ban comments. What is a comment?

I will propose a definition in the answers. Users should assume that the highest voted answer with double upvotes vs downvotes is the definition.

\$\endgroup\$
4
  • 10
    \$\begingroup\$ No, we don't need a definition of a comment, we need to avoid writing challenges with poor specifications. \$\endgroup\$ Commented May 27, 2017 at 22:12
  • \$\begingroup\$ @feersum But challenges sometimes need comments, wouldn't a meta definition be good? \$\endgroup\$ Commented May 27, 2017 at 22:17
  • 1
    \$\begingroup\$ No. Closing as unclear any challenge that refers to "comments" without objectively defining it would be good, though. \$\endgroup\$ Commented May 27, 2017 at 22:18
  • 1
    \$\begingroup\$ Looks like half the people here are talking people commenting on challenges, and half the people are talking about /* comments */ within the solutions themselves... \$\endgroup\$ Commented May 28, 2017 at 12:13

2 Answers 2

Reset to default
3
\$\begingroup\$

There's a standard definition of "comment-free" in challenges

Typically, if a challenge asks for "comment-free" code, it defines that as code in which deleting any single character would cause the program to change its input/output behaviour (sometimes with exceptions for whitespace, particularly in challenges, because languages often vary with respect to how much whitespace is required). This has the advantage of being objective, fitting the intuitive understanding of a "comment" fairly well, and being of a familiar form for PPCG (it's basically the exact opposite of ). It also fits the intuition that "a correctly golfed program contains no comments" (if you're aiming for and not , then all winning programs must be comment-free by this definition, as otherwise you could trivially save a byte).

Despite being the best definition I'm currently aware of, it also has a few known issues:

  • Probably the smallest issue: in languages with multiple-character comment markers (like C's /*…*/), it allows the code to contain empty comments without issue (because deleting any single character from /**/ causes it to not be a comment, and have some impact on the code).
  • There are some languages, like Burlesque and A Pear Tree, in which any deletion from the source is likely to radically change the way it parses (because the language thinks in terms of blocks of characters rather than single characters, and any deletion must be from some such block). These languages can often trivialise this sort of challenge.
  • There are universal techniques for creating arbitrarily long "comment-free" no-ops in most programming languages. (Typically, this requires creating a long literal, normally but not always a string literal, and then doing some sort of checksum operation on it to ensure that it hasn't been changed.) This means that this definition does not really help with attempts to remove the many loopholes from .
\$\endgroup\$
2
  • \$\begingroup\$ Under this definition, unnecessarily long string literals, long function names, and long unused variable names, without checksums, are comments. Is that intended? \$\endgroup\$ Commented May 31, 2017 at 19:50
  • \$\begingroup\$ @StephenS: In the original challenges where this was used, it was intended, as those are all trivial methods of storing unexecuted data and/or blowing up the byte count of code. \$\endgroup\$ Commented May 31, 2017 at 21:19
-4
\$\begingroup\$

A comment is any code that could be trivially removed without changing the behavior of the program

All of these are valid comments in Python:

# comment "comment" (None, "comment")[0] def some_function_which_is_never_called(): pass

The exception to this being if the program reads its own source (this is subject to the same rules as quines).

\$\endgroup\$
9
  • 5
    \$\begingroup\$ The last three most definitely aren't comments. If the challenges wishes to ban these, comment isn't the appropriate term. \$\endgroup\$ Commented May 28, 2017 at 16:23
  • \$\begingroup\$ @Dennis As long as it's on its own line, I don't see why "comment" isn't a comment in Python. It's used in e.g. docstrings and string literals are the idiomatic way to do multi-line comments. \$\endgroup\$ Commented May 28, 2017 at 17:03
  • 4
    \$\begingroup\$ Docstrings can be, and oftentimes are, used in place of comments, but they're not comments simply because they're not comments. No matter how many times you use a shoe to drive in nails, even if it's the best tool available to you, it will always be a shoe and will never become a hammer. \$\endgroup\$ Commented May 28, 2017 at 17:24
  • \$\begingroup\$ @Dennis I have to disagree. When we say comment at PPCG, that means a no-op. I don't care what Python calls a "comment", as languages are defined by their implementation, not their spec. Unless that "comment" line makes a difference to the execution, its a comment. \$\endgroup\$ Commented May 29, 2017 at 0:33
  • \$\begingroup\$ @NathanMerrill Just because a different definition would suit PPCG better doesn't make it right. Call it unexecuted code or whatever you like, but inventing our own definition of comment when it already had a universally understood definition is bad idea, as it will confuse anyone who hasn't read the corresponding meta post yet. \$\endgroup\$ Commented May 29, 2017 at 0:40
  • \$\begingroup\$ Positive proof that docstrings aren't comments. \$\endgroup\$ Commented May 29, 2017 at 0:46
  • 2
    \$\begingroup\$ @Dennis there isn't a universally understood definition. There might be an understood definition for Python, but it isn't universal across all languages. We cannot go with what the language says, because otherwise, I create a language entirely made of comments, or a language where nothing is a comment (depending on what will help me). That said, in your example, that string obviously isn't a comment. The post isn't saying that all strings are comments, but that all no-ops (which in the case above) are comments. \$\endgroup\$ Commented May 29, 2017 at 1:16
  • 1
    \$\begingroup\$ @NathanMerrill All the more reason to not simply say no comments, but actually explain in the spec what is expected from answers. \$\endgroup\$ Commented May 29, 2017 at 1:18
  • \$\begingroup\$ I can agree with that :) \$\endgroup\$ Commented May 29, 2017 at 1:24

You must log in to answer this question.