Live data from Hacker News

Block Comments Are a Bad Idea

futhark-lang.org

41–50 of 84 posts

Re: Block Comments Are a Bad Idea

#41
post #25
post #14

This is one of the signs that we're doing it wrong with programming languages. We're dealing with text. A program can be expressed in text, actually every piece of information can be converted to text some way or another. The question is if it's the right way to do it. It's not. I know why we chose text at the time. It doesn't make sense today. In this case, we should be using a tool that would let us write comments…

What are you suggesting? Some kind of "rich text"? Or are you suggesting visual programming?

I was just thinking about some kind of code side-car file format which stores comments/docs separately. You'd then have a vertical split view with code on one side and the linked comments/docs on the other. You could select some code and use that to insert/link comments in the other pane.

I'm not entirely sure if I've ever seen something like this before - maybe as a feature in a specific language, but not as an IDE feature for all languages.

Re: Block Comments Are a Bad Idea

#42
post #9

The D Programming language has a neat trick to block commenting out code for debugging purposes. Wrapping code in a version(none) {} block will exclude the block from compilation. The code inside the block must still be syntactically valid so it avoids the problem mentioned in the linked post. The D Programming Language - Conditional Compilation: https://dlang.org/spec/version.html

D also supports nesting block comments with /+ +/, which helps when you have example code in your documentation

Re: Block Comments Are a Bad Idea

#43
post #41
post #25

Earlier quoted context omitted.

What are you suggesting? Some kind of "rich text"? Or are you suggesting visual programming?

I was just thinking about some kind of code side-car file format which stores comments/docs separately. You'd then have a vertical split view with code on one side and the linked comments/docs on the other. You could select some code and use that to insert/link comments in the other pane. I'm not entirely sure if I've ever seen something like this before - maybe as a feature in a specific language, but not as an IDE…

as for using comments to disable code - you probably should have the active code in source control and then you are free to simply delete it.

Re: Block Comments Are a Bad Idea

#44

I will second this from bitter experience. Was translating a very old Pascal program. My editor didn't have syntax highlighting for it. Spent a couple hours translating a very large function. Wasn't until I finished that I realized it was wrapped in a very large block comment. That, and most decent editors have a "comment current selection" feature that makes single-line comments easy enough.

Decent editors have lexical highlighting as well as commenting selection; this argument cancels itself out.

Personally I like having two block comment syntaxes to choose from, like Pascal's { } and (* * ); normal comments use { }, while if you want to comment out an entire block of the program and not have the comment terminate early, use (* and * ).

Most of my professional life editing Pascal code was done from command-line editors that didn't have support for commenting the current selection, other than piping the selection through a command like sed. I appreciated being able to narrow down bugs using (* and *).

Re: Block Comments Are a Bad Idea

#45

I will second this from bitter experience. Was translating a very old Pascal program. My editor didn't have syntax highlighting for it. Spent a couple hours translating a very large function. Wasn't until I finished that I realized it was wrapped in a very large block comment. That, and most decent editors have a "comment current selection" feature that makes single-line comments easy enough.

Why do you fault multiline comments and not your code editor?

Re: Block Comments Are a Bad Idea

#46
Rust had an RFC at one point that considered removing (some) block comments, which generated a good argument in their favour (see also the longer comment 5 replies later): https://github.com/rust-lang/rfcs/pull/1373#issuecomment-205...

Essentially it's very annoying (slash slash) for blind programmers (slash slash) if their screen readers (slash slash) keep reading out (slash slash) line comment delimiters (slash slash) during long comments.

Re: Block Comments Are a Bad Idea

#47

I really appreciate class-level and method/function-level comments, in languages that have a special format for them to assist with generating documentation (e.g. Javadoc, Scaladoc, JSDoc, etc). A couple of years back, the company that I work for had a series of lunch-n-learns where each presenter did a chapter of Robert Martin's "Clean Code". One of the chapters deals with comments. Not using them as a crutch, and f…

Before starting, I was expecting this piece to be about semantics, not syntax. Something like line comments encouraging concision, where block comments are too large of a canvas.

If I had to distill my criticism about block comments, it would be that my inclination to read someone's multi-line block commented description of the purpose of some variable or loop approaches 0 as number of lines grows past 1, let alone some lengthy TODO blather.

I was reminded of some of the Java best practices, eg. http://www.oracle.com/technetwork/java/javase/documentation/....

Re: Block Comments Are a Bad Idea

#48
post #25
post #14

This is one of the signs that we're doing it wrong with programming languages. We're dealing with text. A program can be expressed in text, actually every piece of information can be converted to text some way or another. The question is if it's the right way to do it. It's not. I know why we chose text at the time. It doesn't make sense today. In this case, we should be using a tool that would let us write comments…

What are you suggesting? Some kind of "rich text"? Or are you suggesting visual programming?

"Visual programming" seems to have too many meanings. "Rich text" too.

I meant code editors that "know" that you are writing code and make things easier for you. In other words, exactly the opposite to one that prompts absurd debates about if multiline comments are a good or a bad idea.

Re: Block Comments Are a Bad Idea

#49
One can call it BAD too, but I’ve done this several times:

  if (self-describing) {
  }
  else if (self-describing) {
  }
  else /* description */ {
  }
and

  void myfunc(int a, char *b /* optional */, ...)
  {
Block comments are not only block, but also inline. You cannot end line comment on the same line. (Though it is easy to work around).

As of good/bad: if you don’t like it personally, then don’t use it. If in group, then put that in group style guidelines, because these are required to read and follow anyway, for project to be consistent. To prove something is a bad idea in general is a hard work not worth doing.

Re: Block Comments Are a Bad Idea

#50
I like how Lua handles the problem, with multi-level open and close comment strings (and string strings). From Programming in Lua [1]:

> A comment starts anywhere with a double hyphen (--) and runs until the end of the line. Lua also offers block comments, which start with --[[ and run until the corresponding ]]. A common trick, when we want to comment out a piece of code, is to write the following:

    --[[
    print(10)         -- no action (comment)
    --]]
> Now, if we add a single hyphen to the first line, the code is in again:

    ---[[
    print(10)         --> 10
    --]]
> In the first example, the -- in the last line is still inside the block comment. In the second example, the sequence ---[[ does not start a block comment; so, the print is outside comments. In this case, the last line becomes an independent comment, as it starts with --.

Furthermore, the pairs of so-called long brackets ([[ and ]], which match the syntax used to declare multi-line string literals) prefixed with hyphens can be converted to 'level-n' long brackets by inserting an arbitrary number of '=' signs between them:

    local commentDescribingString = 
    [===[Lua allows for multiple comment syntaxes.
    You can use two hyphens: '--' for single-line comments.
    Opening 'long brackets' with these hyphens (--[[) start block comments.
    Long brackets can contain '=' signs to form different bracket pairs.
    Closing long brackets must match the number of '=' signs, and do not
    require the hyphens (but they look better and are more convenient)
    These would be comments if they weren't in a string literal:
        --[[ Level 0
        --[=[ Level 1
        --[==[ Level 2
        print("this is really thoroughly commented out.")  -- It is!
        --]==]   -- Closed level 2
        --]=]    -- Closed level 1
        ]]       -- Closed level 0 without the hyphens
    I had to use level-3 long brackets to declare this string.
    ]===]

    print(commentDescribingString)  -- Prints above paragraph
Single-line comments go to the end of the line, of course, no matter how many hyphens there are. Single-line strings can be declared with any number of single- or double-quotes:

    local singleLineString = """This string with 'single', ''double single'', ""double"", or ""double double"" quoted words might be hard to write in other languages!"""
Of course, there's also 'if (false) then (block of code) end' as in every language. The code still goes through the parser, so it takes compilation time if not execution time, and you can have scope conflicts, but that's OK IMO. Surrounding it in an 'if (false)' block is one quick step away from changing 'false' to 'true' to re-enable it, or changing 'false' to a variable to make it optional, which is nice.
Post reply on HN