Best Practice: Variable Naming in WikiText Scripting

#1

While there is no or few recommendations for naming rule in Tiddlywiki (it seems you have almost complete freedom for naming), but reading WikiText scripts () developed by others and maintaining WikiText script can be quite difficult.

So what is the best practice for naming variables in WikiText scripts?

Note:

A WikiText variable can be creating using a widget like

  • $let
  • $set
  • $vars
  • $list
  • $wikify

Also macro is a variable, ( it is not a real function/subroutine as in other programming languages)

Some recommendation/restriction

  • TW variable names shall contain only letters, numbers, and underscores.
  • TW variable names shall start with a letter or an underscore, but they cannot start with a number.
  • Spaces are not allowed in TW variable names.
  • TW variable should not contain keywords and widget names as variable names.

References

Best practices: Tiddler Naming - Discussion - Talk TW (tiddlywiki.org)

Please share your idea opinion?

#2

Some crude thoughts:

  1. stick with lowercase name convention or CamelCase
    1.1. use dash(-) for multipart name if you use lowercase name
    1.2. If use CamelCase, then start with lowercase like currentTiddler

the macro variable can prefixed with m- or mac

  • like m-actions, or
  • like macActions
    …
2 Likes
#3

A good coder understands the meaning of the variables on an emotional level so it is important to only use emojis as variable names.

:biking_man: (cycling recursion)
:spaghetti: (spaghetti code)
:older_man: (just some old variable hanging around)
:brick: (yes, that’s a foo bar)

Sorry if I’m stating the obvious.

2 Likes
#4

Hi Mat,

First I thought you are joking, as I have never seen a programming language or anything similar can use Emoji as variable name! BUT surprisingly Tiddlywiki supports this! May be @jeremyruston intentionally added such feature:

Example

  1. Open
  2. Create a tiddler with below text
  3. Save and see the results
<$list filter="[tag[Learning]limit[10]]" variable="đź“°">
<$link to=<<đź“°>>/> - number of words: <$count filter="[<đź“°>get[text]splitregexp[\s+]]"/><br>
</$list>

So in above code đź“° is a variable name!

We should apply for Guinness World Records.

#5

Modern Emojis are just Unicode characters (often more than one underlying part creating, in combination, one visual “character-image”). TW has very good support for Unicode :slight_smile:

I hope @twMat is joking!
But he does illustrate a point on “modern naming” :slight_smile:

Best, TT

#6

Right, like @TiddlyTweeter says, emojis really are characters (not, for example, svg or other imageformats). So, as you found, we really can use emojis for e.g variable names. While obviously inappropriate as variable names, I can see a limited use as tiddler titles for some visually oriented presentation :slight_smile:

2 Likes
#7

I… actually want to try and use emojis for variables now. I know it started as a little joke, but it could actually be a fun innovation.

feels like we are going full circle from how the Egyptians used hieroglyphics.

An image is worth 1,000 words after all, so it could be a very efficient method of doing things!

#8

Interesting. Of course an “Emoji” is just a Unicode font character.

There seem to be two aspects:

1 - The "look" of your Unicode (font design)

and

 2 - it's number.

I’m interested to see how it goes! :smiley:

TT

#9

( I totally derailed poor @Mohammad 's thread… sorry man :sweat_smile: )

2 Likes
#10

There’s some “prior art” of bad naming of macros in the French tiddlywiki.com translation like:

\define :() ...

\define ;() ...

\define ?() ...

\define !() ...

These macros are used to ensure proper use of French typographical rules. Using them is quite convenient thanks to their short names, although single character macro names is not something I would recommend.

Fred

2 Likes
#11

I support @Mohammad’s providing guideline where we say unless you have a good reason we recommend you follow the conventions.

  • But I think rules are meant to be broken and from this we get innovation
  • Ideally when you do decide to step out side the standard you should document this fact so when others are trying to understand your code they can.
  • wandering from the standard should be fine but if you wander from it too much and in too many directions it becomes more complex and you may even make life difficult for your self.

For example I would do something similar for fieldnames, I personally keep to the older standards of field names with no spaces, lowercase and words joined by “-” but since 5.2.0 (I think), we can include spaces and a lot more. When and if I step out side this restricted naming I do so for a reason. eg the fieldname is also a tiddler name.

Philosophically,

  • if you do not stray into using a larger set of naming standards they remain available for when you need them.
  • Naming standards can quickly help you identify what you are looking at, they do not force to to need to refer to anywhere else, just to see what you mean. The meaning is in the name. Dare I say rather than “the message is the medium”, “the name is the message”.

As with fields I also support using clear and meaningful, plain language variables. Now some will say but that means you may clash with other plugins and macros but 90% of the time this is not true because variables typically are constrained by there context and can be redefined/reused as many times as you want - fields not so easily, global macros somewhat.

Did you know you can use in filters fieldname[fieldvalue] so you can in effect write your own filter operators display-details[yes]well now we can use macros with parameters in filters we can possibly do this with macro names.

  • In these cases plain language code is easy to use (at least in a language you speak)
1 Like