I have always used the format field-name, but since we now have no character restrictions I’m wondering if anyone has any thoughts on sensible naming conventions for fields, or ways of making the most of our new-found freedom?
I’d say: “Don’t fix it, if it isn’t broken”. …
So once you have the need to change your current workflow, just do it. It may need several iterations till you find you new “base ground” that fits your need.
IMO there is no “one size fits all” convention. It will always be user and project specific.
While TW 5.2.0 brings many flexibility for naming fields! BUT I believe in good programming style!
Normally fields name are hidden from readers and that is the author which use them!
I stick with alphabet in lower case, no number, and only dash or underscore nonalphabetic symbols I use!
You may get idea from Soren GTW book also!
1 Like
I think this is a case of rules were meant to be broken, but on the whole stick to the rules.
I intend to maintain my own naming rules as needed because it is a good practice, it helps memory anyway because you know how you would have named it eg; no caps spaces etc…
But then I love the opportunity to break the rules, and I will when it has real value, this will also mean when I see a field breaking the rules I will know it is from a different subset of fields.
In my thread on “quicklist” you will see how I am using fieldnames based on a line in tiddler text. With this we discover that we could quickly “pollute the field namespace” because these field names appear in the new field dropdown. This is ok for quick list because its intended to be a temporary ad hoc solution and the fields disappear with deletion of that tiddler.
I think it worthwhile to consider some fields as system fields, that is we do not want them exposed to the user or field drop downs, such fields need a prefix or suffix to indicate them or be registered somewhere, the most obvious would be $:/ but $ may be sufficient. Once this standard is in place we can hack or change the core to hide these from the dropdown.
Perhaps we could detect fields containing prose, or spaces and handle them differently.
I think this is yet to be established so I would be conservative in my field naming in the meantime.
I don’t go by any convention. Whatever I choose at any moment, it is by that moment’s whimsy, the mood of the moment, a creative flow that fits whatever I’m working on.
Doesn’t really matter much. If I had a standard convention, I’d still always be looking up field names just as much as without a convention.
If you really want to get into naming conventions, there are all kinds of inspirational sources on the web, for example:
If conventions help you, use conventions. If conventions hinder you, don’t use conventions. Whatever keeps you from getting your wheels stuck in the mud and keeps you from getting sticks in your wheels.
Often conventions are particularly helpful in collaborative/team efforts.
In contrast: when incorporating into one’s own TiddlyWiki tiddlers from various authors, maybe differing conventions reduces conflicts?
Easy to overthink it…
Charlie,
I think written between the lines is the scope of this. A new and single purpose wiki or one relying on multiple plugins and macros. I would encourage total freedom, experimentation playfulness etc… but then more complex wikis or those designed for publishing on the internet , multiple plugins and macros or sharing as an edition etc… need a little more caution. I am only saying caution not rules, to avoid being Hoist with his own petard - Wikipedia
Caution? Maybe.
Off the top of my head, I don’t remember any moment in which I looked at something and thought “thank goodness for the naming convention.”
It might be easier for me to relate with a real-world example of when a naming convention saved the day, or lack of naming convention caused a nightmare.
A data/fieldname dictionary, that’s good stuff for some things.
I try to think of a field name as a variable name (and field value is the value of that variable). So even though we can use space or other characters for field names, I tend not to. (Perhaps, for a good practice as what everyone has said). It also ensures that I can use that field in the future (for other uses maybe) without worrying that something might break). But if the field will be used only for a specific use-case then I think that’s fine.
I am a little confused here. You are often writing about “going down the rabbit hole”, and now you are “Hoist with his own petard”. 
I guess the TW user is down in dark solitary confinement, with an exploded TW distributed all over the place. 
Apart from that I agree.
Well. simply put - With tiddlywiki,
- One can run down a rabbit hole and end up a long way from home and somewhere you did not expect.
- One can also do almost anything and everything such that sooner or later you trip over yourself, or cause an explosion of complexity to ignite.
With power comes responsibility, even if it is only to yourself.
I bring my own flexible rules to what ever I do, these are more often than not conceptual rather than black and white, but it allows me to do things quicker, simpler and more reliably.
I thought it a gift to others to share how I cope with design and complexity. But clearly my literary style of expression does not work for some.
It has being a lifelong interest of mine to attack even the most complex problems, because they are to me the most interesting, these approaches are essential in that quest. As is the process of repeatably returning to the fundamentals.
Whilst sometimes I do things without any rules, they may have taught me something, helped me innovate yet they lay on the floor as experiments I have moved on from. They find a new life as concepts.
Yeah, I can’t help myself (apologies for off-topic) …
Although very possible (or likely?) that @TW_Tones is a rabbit hole traveller, if he has explicitly mentioned it, I sadly missed it.
I’ve often mentioned I am forever in rabbit holes. Such is ADHD (attention regulation challenges) … my scatter-brained self.
But if it is both of us (and who knows how many others): yay !!!
However, do know that my rabbit holes may have a little bit of “Alice in Wonderland” going on, to the tunes of Jefferson Airplane’s White Rabbit and/or Steppenwolf’s Magic Carpet Ride.
As enlightening as rabbit hole travel can be, it can be bad when it turns into wheels in the mud and sticks in the wheels.
Back to topic
Like all things, naming conventions or other, don’t let yourself get bogged down, learn from mistakes, and try to do all things such that they can be adapted to new insights and wonderfully creative solutions that fit whatever problems.
Yeah, I may often ooze math-logic-science, but artsy-fartsy-creative is at the core.
Do what works for you and helps you make your solution solid and easy for you to maintain as the owner of it.
Don’t worry about the future. If you build something in TiddlyWiki, the future will be fine. When it isn’t, deal with it then. Focus on the Now, create, learn, and you’ll be better equipped to deal with the hiccups of the new “Now’s.”
I am calling for examples of when naming conventions saved the day, or lack of created misery. Proof-in-the-pudding examples that make the case for naming conventions would be oh-so-awesome.
@TW_Tones
Thank you for your patience and explanation. Do know that I have learned a lot from you over the time.
Very good explanation!
But I do. Aint nothing worse than opening a TiddlyWiki I haven’t opened in a year and wondering what the hell is going on.
Within reason, try to be explicit, if a field needs to be alphanumeric for clarity’s sake, go for it: screen-1-left-coord, status-3, flag-6 etc.
@Mark_S made a point earlier about field pollution – oh boy, tell me about it. “Fundamental particles” in my wikis.
Yeah, that’s why I tend to prefer Data Tiddlers, although seemingly not a generally popular option.
1 Like
That’s where breadcrumbs become really useful. That could be a great thread of discussion in its own right.
1 Like
Charlie,
If by breadcrumbs you are referring to a history of actions within the wiki so one can look back, I think the 5.2.0 release will provide some new methods to capture activity in the wiki in addition to merely opening and closing tiddlers. I just need to persuade someone with more dev skills to have a look at it. Simply a time stamped log of navigation, buttons and new/edit tiddlers.
This would be a good case for data tiddlers.
Nah, I just meant in a general / ad-hoc / informal sense. Reminders related to the purpose of a field.
hihi, Yea, it would probably be good practice to have tiddlers tagged: “thoughts”, which document decisions made, just to be sure you don’t forget them.
@CodaCoder - from programming point of view, naming convention is quite important! I believe debugging and maintaining Tiddlywiki scripts is difficult and have some naming procedure will make this task much easier!
Example: Tiddlywiki itself uses namespace for tiddlers! for example all images have a name like this $:/core/images/
As I intimated/implied. It takes a lot of practice and repetition (40 years and counting - it aint over yet).
Not sure why you felt that needed pointing out to me? I’ll put it down to miscommunication.