Suggestion for custom blocks - use JS variables

For custom block libraries that create their own variables that take up space in the variable pallet and could easily be changed, I suggest you use

[scratchblocks]run (javascipt function () @delInput @addInput [variableName = variableValue]::operators)::control[/scratchblocks]

and

[scratchblocks](call (javascript function ()@delInput @addInput [return variableName]::operators)::control)[/scratchblocks]

for hidden, not easily changeable variables.

better yet, maybe do something like

[scratchblocks]
run (JavaScript function [variableName][variableValue] @delInput@addInput [libVars = {}; libVars[variableName\] = variableValue;]::operators) with inputs (name) (value)@delInput@addInput::control[/scratchblocks]
for setting vars and

[scratchblocks](call(JavaScript function[variableName]@delInput@addInput[return libVars[variableName\] || false;]::operators) with inputs (name)@delInput@addInput::control)[/scratchblocks]

What is the scope of these variables? Can any block see/set them?

probably

Any block can see and set them, the scope is the entire window.

[scratchblocks]
run (JavaScript function [variableName][variableValue] @delInput@addInput [libVars = {}; libVars[variableName\] = variableValue;]::operators) with inputs (name) (value)@delInput@addInput::control[/scratchblocks]
will reset the libVars variable every time you set a variable in libVars.

Try using:
[scratchblocks]
run (JavaScript function [variableName][variableValue] @delInput@addInput [libVars[variableName\] = variableValue;]::operators) with inputs (name) (value)@delInput@addInput::control[/scratchblocks]
for multiple variables in libVars.

and to reset libVars use:
[scratchblocks]
run (JavaScript function @addInput [libVars = {};]::operators)@addInput::control
[/scratchblocks]

you should use (varName) and (varVal) instead of (variableName) and (variableValue). It's much better to abbreviate variable names.

No, no, no! I bet you also think it's desirable to put comments in your code, but the former is the reason for the latter. Programs should be self-documenting, which means, among other things, that it should be clear from a variable name what the variable is for. One of the great things about block languages is that you can have a 200-character-long variable name, and you only have to type it once! (Of course this is also true if you have a good text editor such as Emacs so you can define abbreviations for the long names. You type the abbreviation and the editor inserts the long name into your code.

What is the alleged virtue of short names?

easier typing, actually, you're right. Maybe long names are good too.

Long names translate to unwieldy blocks, which lead to hard to manage scripts. Without the ability to collapse sections of blocks, it leads to very unsavory block manipulations. Ever try to insert a block into another group which includes rather lengthy other blocks? The highlight won't let one accurately pick the exact location easily. It is much easier to edit when most of the script is of uniform shape and block lengths. imo.

I take your point, although expressions also become wide through composition of functions. For me (no surprise) that's more common than a problem with long names.

But also, there's long and long. The example that started this subthread was varName vs. variableName, and that's enough of a difference to be much more self-documenting, but not, I think, long enough to bring on the problem you describe.

don't use Scratchblocks.github.io just use SNAP! block pictures

we can use whatever we want. And scratchblocks were added to the forum because users asked for it.

C'mon, guys. Assume good faith, and all that.

There is no way to use Snap! "pictures" in ScratchBlocks. ScratchBlocks build dynamic SVG images. To change the blocks shape JS must be modified.
:snap: has easy and quite convenient features "script pic...", "result pic...", so ScratchBlocks slowly become obsolete.

I agree; I've never felt a need to use Scratchblocks. Especially since Result pic, it's really easy to document projects.

On the list for someday is to be able to drag a picture into a comment in Snap! itself.