-3

This topic has been discussed before in Why are there no line numbers in the code listings?. The most powerful reason that prevents the implement of line numbers is changing code lines numbers and that will make regarding a line number cause confusion.

Numbering lines of code snippets could be maintained using Number Anchors that would dynamically update the line number regarded in the ordinary body text. Some thing like the flowing:


In the following function I have an issue with line [L:500]:

function doSomeThing(x){
    if (x){
           alert("There is no x in Line 3") [L:500]
    }
}

In the above example [L:500] in body text should be printed as 3 which is equals to line number in which [L:500] is found in the code. Also, [L:500] should not be printed in the code on reading but it should be displayed during edit.

Suppose, some one will edit the code to be like the following:

function doSomeThing(x){
    if (x){
          // Explanation comment!
           alert("There is no x in Line 3") [L:500]
    }
}

Here the [L:500] should be dynamically changed to be 4

1 Answer 1

4

I am not sure I like this idea, because it seems to add unnecessarily arbitrary complexity plus potential confusion while seemingly not solving a problem. For example, your snippet in this form instead:

function doSomeThing(x){
    if (x){
           alert("There is no x in Line 3") // Line 500
    }
}

Is way easier to deal with, and still perfectly edit-proof, if everybody just says "line 500". There's no real reason to have it be "3" or "4" or even accurate, the only thing that matters is that everybody knows what line you're referring to. Remember that the primary purpose of displaying line numbers is to make lines easier to refer to in communication, and while your solution does do that, it seems to make more sense to just skip the middle man, mark the line directly with some unchanging label in the code and refer to that when talking about it.

And also, since the author of the snippet doesn't know in advance what lines other people may want to refer to, this doesn't serve much purpose unless they label every line (or unless everybody goes in and edits labels into the lines they want to refer to), which isn't really desirable or convenient.

Another added complexity would be finding an anchor format that doesn't conflict with the code, because you don't want to accidentally parse code, and you don't want to have to require people to escape certain sequences in their code, especially in ways that make the code itself no longer valid. Then you've got the minor issue where if somebody updates their code by e.g. copying and repasting the entire block from somewhere else, they blow away any explicitly added-in labels. And the list goes on.

Plus, in addition to the problems in the linked post, now you've got all the extra confusion of e.g. stack traces (in relevant languages) not using the correct line numbers, etc. Better to have no numbers than incorrect ones.

In any case there doesn't seem to be much confusion now, as comments like // Line 500 or // This is the line causing problems generally seem to work just fine, as well as simply quoting the particular section of interest in an answer.

1
  • Looking at ordered line numbers like an any editor, will make code tracking by the reader is more easier. To be more clear, it should a text processing like occurred for tags and as I regarded It will be like an anchor i.e it may be not numerical at all i.e [L:lorem].
    – SaidbakR
    Commented May 24, 2017 at 22:50

You must log in to answer this question.

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