Just a simple suggestion today. I know that this isn't so exciting - they're just comments after all and functionally don't do anything. But I can't stand working with the current comment feature. It's finicky, and always gets in your way.

I propose two new comment blocks, a standard version and a c-block version, for writing comments and organizing your code


I wrote “REM” as the name of the block as a homage to the BASIC language - it stands for “remark”, but you can just as easily have a nameless version of the blocks:

Support! I don't really use comments because I find them messy, but if this was implemented I would certainly use them, they are much neater. The C-Block comments are a brilliant idea!
How would you get the comments? Would you right-click as in the current system, or drag them from the block menu?

Yeah totally! I haven't been using comments much either because of the current implementation, and I've noticed by looking through quite a number of other projects that hardly anyone uses them. Which is a shame - scratch is completely about the idea of sharing code! What's the use of sharing code if it's a mess that other users can't understand? This would help a ton I think

I'd imagine you'd simply drag them down like any other block. No need for the right-click stuff.

+1

+1. The inline blocked comment used to in older versions of Scratch.

They won't do inline comments because new people were confused by them.

Look here. There were inline comments in Scratch 1.2 beta, but new users got confused when the block did nothing and their sprite wasn't making a comment.

Here is a way to comment inline:

think (letter (0) of [comment here])

Or if already using ‘think’ or ‘say’ then wrap like so.

if <>
think [comment here]
end

And for C block:

if <> then
    think [comment here]
else
... code ... ::grey
end

Or use a custom block with no definition.

note [ ] ::custom

if <>
   note [comment here]
else
   ... code ... ::grey
end

define note [ ]

Or

define comment []

The color and the font in the Handle Physics definitions look really nice. Wish we had a way to replicate.

support C-Block!

Support, nice idea.

Support!

They were removed because of confusion.

And, there is an easy workaround, so no support:

define REM (comment)

when gf clicked
REM [This is run when the program starts.]
go to x: (0) y: (0)
REM [This resets the sprite's position.]
if <not <[This is a C block comment. They aren't found in any other programming languages in existence.] = []>> then
forever
if <not <[This checks to see if the user is pressing space.] = []>> then
if <key [space v] pressed?> then
say [Hello!]
REM [This will say "Hello!" when the space key is pressed.]
else
say []
REM [This will say nothing when space isn't pressed.]
end
end
end
end

savaka wrote:

They won't do inline comments because new people were confused by them.

djdolphin wrote:

Look here. There were inline comments in Scratch 1.2 beta, but new users got confused when the block did nothing and their sprite wasn't making a comment.

So I totally appreciate that they were removed for a reason - that's good to know. I didn't know they existed before. But what's more important to me than knowing that they were confusing to users is knowing *why* they were confusing. In-line comments are great for a whole multitude of reasons, but I don't think it was the “in-line” part about the block that made it confusing.

It seems like the main reason they were confusing was because they weren't set apart enough from blocks that provide function - such as “say”. I think the main fault lies on naming the block. If you label the block “comment” users will think that the block actively, in the verb sense, comments. But if you label it with nothing then there's no room for confusion. There's nothing to suggest it does anything at all besides hold text. For this reason, I dont like my “REM” version anymore. I'd go with the completely blank one.

But it got me thinking. It could probably benefit from even more visual separation than that. I whipped up new mocks…



This is the same idea as last time, but I removed the white box and changed the font. The white box gave the impression that it's contents could be interactive in the same way regular block's have text boxes that you can drop sensors or variables to. By removing it, we also remove the confusion in that regard. By changing the font to something that appears hand-written, it visually sets it apart as being a note rather than important data.



This idea pushes the concept even further. Instead of thinking of comments as blocks at all (which scratch claims was confusing), what if they were treated as extensions to any block. I think this was the line of thinking scratch was going for when they changed them, but in doing so they destroyed the friendliness and clarity of them remaining in-line. This idea solves both problems. Right click any block and click “add comment” like you normally do, but instead the note is added to the top of the block. This absolutely removes all ambiguity.



This could also be coupled with the idea of free-standing line-blocks and c-blocks, but isn't too necessary. The only argument for them is sometimes you want comments that aren't associated with any particular block or you want them associated with chunks of blocks, and these can make that more clear.

TimothyLawyer wrote:

Here is a way to comment inline…

AonymousGuy wrote:

They were removed because of confusion. And, there is an easy workaround, so no support:

Before I made this suggestion, I've been using the workaround of using a custom defined block called REM that does nothing. It's done the job for now, but it has a few major downsides compared to making it a dedicated option:

• Readability: Because they're the same color as custom blocks, it's hard to immediately spot which things are comments and which are not. the c-block hack is even worse in this regard because it starts to look like actual game logic
  
• Performance: I'm not entirely sure of any performance hits that are caused by the overhead of running empty code including custom blocks and if statements.
  
• Single-line only: Sometimes your comments need to be quite a bit of information. If you try this with the work around you'll end up with a super long string of text that you'll need to scroll to read. The only way to break it down into multiple lines is to do a new block for every line. It's pretty ugly.
  

At the end of the day, I believe my suggestion better fits the goals of scratch. It's easier to read and use, and addresses the issues that the first iteration of scratch had with them. The fact that nobody is using new comments as much as they should is pretty telling that it's not the best approach.

-Dan

I like the new design idea! To reduce clutter, maybe instead of having separate stack and c-shaped comment blocks, there could be a stack-shaped comment that opens into a c block when you drag blocks over it and closes again when you drag them out.

Edit: Or maybe keep the old comments, but they would snap into scripts and become block shaped, and then they would be able to do what I said above. There would need to be some degree of backwards compatability with the current comment system.

Support!

support

warning: offtopic starts hear.

although could you not name iit REM?
REM already stands for rapid eye movement which is a state when you are asleep and dreaming.

warning: offtopic ends here

also these were 1.2 comments but were scrapped due to new scratchers getting confused leading to syntax errors

Support for the new idea - less confusing for new scratchers.

I also have a few ideas for it - I might make some mock-ups if I want to.

@djdolphin: I absolutely love that idea. Could work very well.
@seanbobe: REM is also commonly used in BASIC programming that means “Remark” Your other points are also addressed in the rest of this thread
@AonymousGuy: I'd love to see them!

Slight update:

just refined the colors of last image a bit more to better message that the c-block is a stand-alone note, but also keep the same visual language that it's a note attached to a block.

support :: control

It'd be great for this to be implemented!

fezzinate wrote:

Only problem is that it would take a long time to create a completely new block type like that.

AonymousGuy wrote:

They were removed because of confusion.

And, there is an easy workaround, so no support:

define REM (comment)

when gf clicked
REM [This is run when the program starts.]
go to x: (0) y: (0)
REM [This resets the sprite's position.]
if <not <[This is a C block comment. They aren't found in any other programming languages in existence.] = []>> then
forever
if <not <[This checks to see if the user is pressing space.] = []>> then
if <key [space v] pressed?> then
say [Hello!]
REM [This will say "Hello!" when the space key is pressed.]
else
say []
REM [This will say nothing when space isn't pressed.]
end
end
end
end

Sorry. No support. ^ Explains the workaround.
I liked it until i realized that some new scratchers would think that the comment block actually does something and be confused when there sprite doesn't “Jump like crazy” or whatever they put in there.