I'm trying to convince the designers of a language that multi-line comments with an arbitrary start and end are important, and should be included. Currently there is only a "comment-to-end-of-line" primitive.
Their line of argumentation reminds me of what some say about why you should use spaces instead of tabs. Basically that editor features can pick up the slack and remove the requirement for a different construct. (So if you wanted to comment out more than one line, you'd select what you wanted and run a macro of some kind...to add or remove a to-end-of-line comment to each line. I just read that this feature exists in Visual Studio, despite C/C++ offering a multiline comment.)
Other suggestions about removing blocks of code from execution wind up being things like "cut the code out, try it, and use the redo queue". I think this is not a very easy way to keep track of "invisible" information you might want back, and redo queues are quick to lose information the moment you hit even a stray key on accident. So this does not sway me.
I can live with the space vs. tab thing and putting that on the editor, and it's now pervasive. But to me this is different, and I'm dissatisfied with these answers. For me, being able to comment out code with just a start and end marker like /*
and */
is extremely useful. Passing the buck to editor magic doesn't let you position your starts and ends arbitrarily (how would you comment out the middle of a line if all you had was //
?) And I also don't like leaning that much on editor features.
Sorry to ask a question with overtones of an opinion poll, or about something subjective. But what I'm looking for are any more objective arguments I am not thinking of, which could provide more ammunition backing this feature I think is important. (Or I guess I could accept a powerful argument favoring NOT having a multi-line comment format, which overrides my strong desire to have it... I'm not putting high odds on that, though.)
{curly braces as string delimiters}
. Because the string delimiter is asymmetric, it can nest. However, because it has a code-as-data paradigm, that only kind of works in evaluation contexts (between complete expressions), and not in data contexts. :-/ I still really want multiline thrown-out-by-the-parser comments."
for statement grouping?