51–60 of 84 posts
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
Earlier quoted context omitted.
What are you suggesting? Some kind of "rich text"? Or are you suggesting visual programming?
I think OP is suggesting something akin to the magical automated dev tools of the 1980s (OOH ITS GRAPHICAL) which never actually came to fruition.
Edit: actually I'm curious how much time it will take for my gp comment to go from "downvoted eccentricity" to obvious.
More edit: I'm not only thinking in more computing power. We know a little more on usability and user experience now than then.
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
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.
This sounds a lot like "do what I mean." You have to tell the editor in some way that you want to write a block comment or not, and that you want to end it.
My editor does make somethings easier for me - if I start a block comment, it automatically inserts the block comment closing character after my cursor. It does syntax highlighting of the block comments, so it's obvious at a glance where they begin and end. I can declare or remove a bunch of single-line comments by selecting a block of text and hitting a shortcut key, or by creating a multi-line cursor at the start of the lines and adding or deleting the single-line comment characters.
I find it hard to imagine an editor with an interface which is easier and faster than entering simple text, once I'm intimately familiar with the shortcuts used with the editor and the syntax of the language I'm writing in. If one exists or could exist, I'd love to know about it!
Earlier quoted context omitted.
I think OP is suggesting something akin to the magical automated dev tools of the 1980s (OOH ITS GRAPHICAL) which never actually came to fruition.
I don't know what you refer to. But anyway, be careful with discarding ideas that didn't work in the 80's. What was unpractical then could be very convenient today. Edit: actually I'm curious how much time it will take for my gp comment to go from "downvoted eccentricity" to obvious. More edit: I'm not only thinking in more computing power. We know a little more on usability and user experience now than then.
Earlier quoted context omitted.
I view inline comments as a code smell in most languages; I can’t think off-hand of having seen even one occasion where the code couldn’t be tweaked into another nicer form that didn’t depend on inline comments.
I use them with functions that have too many arguments. It's not always feasible to fix the problem at the source. damageDealt = calcDamage(weaponType, monsterType, DamageType.FIRE, null /* specialEffectFlags /, false / hasMagicTargeting */ ); It's definitely a code smell, but it's much better than nothing and I'm always glad to see these comments when I come back to the code.
The extreme in your case would be `hasMagicTargeting = false` and then pass `hasMagicTargeting` instead of `false`.
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 t…
if (…) {
} else if (…) {
} else { // description
}
void myfunc(int a,
char *b, // optional
...)
void myfunc(__in int a, __in_opt char *b, ...)
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 sla…