Talk:Comment (computer programming): Difference between revisions

Revision as of 08:18, 22 December 2024

Latest revision as of 12:29, 11 January 2025

(4 intermediate revisions by 2 users not shown)

Line 116:

The following proposed clarification seems fine, except if the goal is exacting precision, then there are a few issues, some of which are enumerated below:

<div style="border:1px solid black;">

<strikes>Comments are pieces of text interspersed in programs' source code for explanatory or documentation purposes.</strikes><span style="color:red;">(1)</span> Comments must be <strikes>marked</strikes> indicated in a way that allows a source code processor <strikes>(interpreter or compiler)</strikes><span style="color:red;">(2)</span> to recognize them as such. <strikes>so that no further syntactis and/or semantic analysis is performed on them.</strikes><span style="color:red;">(3)</span> This is often simplified by saying comments are "ignored" (after they have been recognized) by the processor.

</div>

Line 143:

:::'''Source language translator:''' The point you were making there was not lost on me. The problem was, by introducing exacting precision on one issue, you were (potentially) introducting *new inaccuracies* on other issues. For example:

<div style="border:1px solid black;">

other processors (documentation extractors etc.) have to choose formats which are a particular form of those <strikes>accepted by the source language translator.</strikes> consistent with the language specification.

</div>

:::That's nice, except your original proposed refinement ''did not even acknowledge the existence of other types of processors''. Moreover, you seem to be assuming "the source language translator" is some kind of monolithic, definitive authority ''rather than merely an implementation of what is *truly* authoritative: the language specification itself''. What about language translators that do not fully conform to the specification? [[User:Dreftymac|dr.ef.tymac]] 17:39, 1 January 2007 (UTC)

Line 157:

::That doesn't invalidate the accuracy of the statement though does it? The text doesn't say ''"it is both necessary and sufficient to call X a comment if it is discarded"''. It just says comments are (generally) discarded. How is it even possible to write a generally accessible article introduction if accurate-yet-not-categorically-exhaustive statements are completely forbidden, especially since clarifying footnotes are always available to satisfy more "fastidious" readers? [[User:Dreftymac|dr.ef.tymac]] 12:45, 2 January 2007 (UTC)

::I am not for or against the change. I'm just pointing out that, like ''ignored'', there are ways of reading ''discarded'' that suggest unintended meanings. [[User:Derek farn|Derek farn]] 13:58, 2 January 2007 (UTC)

'''Back to square zero - just leave it as is:''' Since this issue was previously dropped mid-topic; and since the only (cited) proposed phrasing for "introductory style text" was "comments are ignored"; and since the only provided rationale for opposing this phrasing was <strikes>1) you dont know what you are talking about;</strikes> and 2) the phrasing occurs ''where one just tries to "get started"''; and 3) it is technically inaccurate; and since this article is supposed to be accessible to a general audience (some of whom are indeed at 'tutorial level' understanding); and since the technically inaccurate text is already qualified with a clarifying footnote; and since the English language is replete with phrasings that are "technically inaccurate" and yet nonetheless widely accepted for sake of conciseness (e.g. the "Sun rises in the East and sets in the West"); I propose either: i) the text be left as is; ii) someone else provide a *cited* alternate phrasing that conveys the same idea and still keeps the intro readable and accessible; or iii) someone credibly explain why "introductory level text" is not appropriate for an "introductory level article paragraph". [[User:Dreftymac|dr.ef.tymac]] 16:06, 2 January 2007 (UTC)

== refinements to definition of "comment" ==

Line 222:

:What is the "curled corner effect"? The only thing weird about the current image that I noticed was that the last line of code (before the closing brace) is mis-indented and the associated comment is truncated:

<syntaxhighlight>

<code>

frame.pack();

frame.show(); // display the fra

}

</syntaxhighlight>

</code>

:when it should read

<syntaxhighlight>

<code>

frame.pack();

frame.show(); // display the frame

}

</syntaxhighlight>

</code>

:It might be an SVG bug, though. In any event, IMHO there's no real reason to have an image on this article anyway; it just shows the same thing the code samples show, but in a less reader-friendly fashion. --[[User:Quuxplusone|Quuxplusone]] 02:20, 10 August 2007 (UTC)

Line 377:

:Nothing heard (and I agree) so I performed the merge. -- [[User:Mikeblas|mikeblas]] ([[User talk:Mikeblas|talk]]) 01:52, 9 September 2024 (UTC)

== Off the mark in a few places ==

WRT current open: "In computer programming, a comment is a human-readable explanation or annotation in the source code of a computer program" all source code should be human-readable; not just comments. I think the point is that a comment is gibberish to the computer, yet meaningful to a human. So, "human-readable" is not wrong when describing a comment, but it's misleading since saying that implies that some adjacent concept is not human-readable. And the most adjacent concept is the non-comment code.

WRT short desc: "Explanatory note in the source code of a computer program" A comment is does not necessarily explain something. The content of a comment could be nonsensical or gibberish; yet it's still a comment. A comment is simply text embedded in source code that the translator (i.e. compiler) ignores. Often it explans something, but to say a comment is explanatory is an overreach.

To say that a comment is in source code of ''a computer program'' is overstating as well. I can write a code fragment with a comment, and IMO that's still a comment. A comment need not be part of any computer program to still be a comment.

In general, this article is written in touchy-feely wording that is close to being right and covers typical scenarios. But, it's not accurate. IMO, it should be both accurate and describe common scenarios/uses. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 11:25, 9 January 2025 (UTC)

:I edited the article relatively heavily to address these issues. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 12:29, 11 January 2025 (UTC)