Snapblocks Style Guide

From Snap! Wiki, made by Snappers for Snappers

This page details the best practices when writing snapblocks, either on the wiki, or elsewhere.

Overrides[edit | edit source]

Always put a space before and after ::.

block :: motion // good
block::motion // bad

The only reason why no space before :: was used on the wiki before, was because of a bug that has since been fixed.

Whenever writing code, try not to set the category or shape, unless the block doesn’t exist in Scratch or Snap! (Snap! libraries are not included).

move (10) steps :: motion command // bad
move (10) steps // good

vee :: looks // good

Comments[edit | edit source]

Put spaces before and after // when writing comments.

// good
//bad
block // good
block//bad

Put spaces around inputs.

Inputs[edit | edit source]

move (10) steps // good
move(10)steps // bad

Indentation[edit | edit source]

C-Blocks[edit | edit source]

Indent scripts inside a c-shape.

if <> {
  say [Hello!]
  if <> {
    move (10) steps
  }
} // good

if <> {
say [Hello!]
if <> {
move (10) steps
}
} // bad

Indents can be 2 or 4 spaces, but should stay consistent.

Multiline Blocks[edit | edit source]

Indent multiline reporter and predicate blocks to the opening bracket.

multiline\
block

(multiline
 block)

 <multiline
  block>
  
move (x position
      with extra stuff) steps

Multiline Inputs[edit | edit source]

Don’t indent multiline string inputs, as the spaces are placed inside the input.

say [Hello
world] // good
say [Hello
     world] // bad

This is due to a limitation, it would be indented if spaces weren’t included.

Shapes[edit | edit source]

Don’t use shape overrides, unless neccessary.

(block) // good
block :: reporter // bad

Define Block[edit | edit source]

When creating a Snap! define block, use define+ instead of manually placing in plusses, so you don't accidentally miss a plus sign.

{custom block} :: define+