Suggestion for new node name formatting guidelines

Question

Once upon a time, there were no nodes, the world was still simple then.

There were main menus, context menus, input fields, keyboard shortcuts, etc. and the highest of feelings were a few lines of Python code. That's probably when the style guide on BSE evolved.

But then came nodes.
And more and more came.

And no one thought to consider a new style element for it consistently!

As surely some of you might have noticed, in all my posts I write the names of the Geometry Nodes available in Blender in backticks.

Why do I do this?

I have noticed with some test persons (primarily beginners and students) that there is much less misunderstanding, because it is always clear that a certain node is meant.

I generally understand the desire not to use this kind of formatting in other posts, especially when it really is about code, or just to highlight certain parts of the text.

In the case of Geometry Nodes, however, we are dealing with a universe all its own.

There is no code here, there are no submenus scattered anywhere in the game, here we have a playground largely separated from all other areas.

The problem I see here is that in my experience the recognizability of input values, socket identifiers (inputs/outputs), and node identifiers are given too little distinctiveness if you don't allow formatting with backticks. Writing the name of a node in italics or bold is not a solution and only causes confusion.

For example, I do not distribute points on faces, no, I use the node Distribute Points on Faces. And if I mean a certain input of this node, then I write e.g. Distance Min. This is clearly stated in the universe of Geometry Nodes and does not get in the way of a nice line of code.

I ask for some thought and discussion here before another one of my posts becomes a victim of styleguide corrections and I have to revert these changes.

My goal is that the current style guide states: "Use backticks only to mark up code, or when you want to express a particular node.".

Another possibility I see is a new formatting tag, such as <node></node>.

---

I'll use a concrete example:

In this text I write:

3. So that I can also control the rotation of the object, I use the Tilt property of the curve. However, so that the value defined via Group Inputs also always generates a rotation from one end to the other end of the arc, I use the node Map Range and feed it additionally with the value Factor, which the node Spline Parameter gives me.

Here you can see that I mean the Group Inputs, but not the node Group Input. I could of course write Group Input and Group Inputs, but the difference would then no longer be clear from the text in extensive descriptions.

However, writing a node in italics is not practical because it is quite possible to mention a node in an italicized text.

Here I mean the Node Cube, and not the Cube created before.

But i could write:

Here I mean the Node Cube, and not the Cube created before.

But bold text should not be used to highlight nodes, as this type of highlighting should rather mark places in the text that are of appropriate importance.

---

Furthermore, I write in the example above:

PS: I have hidden some of the irrelevant sockets to save some space. You can show them again with the key combination CTRL+H.

But I could also write:

PS: I have hidden some of the irrelevant sockets to save some space. You can show them again with the key combination CTRL+>H.

Or even:

PS: I have hidden some of the irrelevant sockets to save some space. You can show them again with the key combination CTRL+>H.

Why don't I do that?

Quite simply because a key is something that, although it is actually quite clear and understandable in the text, is a kind of marker and reading aid when someone is trying to follow instructions and filter out the essential steps from a text.

This has been common practice here for a long time, and it makes sense.

But now it's time to create such markers for nodes as well, since the existing stylistic means are not sufficient in my opinion.

---

Or a fictional example:

Create cubes with the Node Cube and instantiate them with Instance on Points at the corners of your cube previously created with Cube. Then instantiate them on the grid you created with the Node Grid.

It would be better to write:

Create cubes with the Node Cube and instantiate them with Instance on Points at the corners of your cube previously created with Cube. Then instantiate them on the grid you created with the Node Grid.

---

Here is another fictional example:

Plug the geometry from Group Input into the input Geometry of Group Output to make your geometry visible with Geometry Nodes.

Plug the geometry from Group Input into the input Geometry of Group Output to make your geometry visible with Geometry Nodes.

---

Summary

_{Thanks to Duarte Farrajota Ramos for the wonderful picture!}

In summary, the question "Backticks or no backticks?" can be answered with the following words:

The code is more "guidelines" rather than actual rules.

There are (especially here on Stackexchange) obviously at least two dominant camps of users:

• One relies on structures and approaches that have grown over a long time and are generally considered proven and stable. This tends to be the logical type (I won't say "older").
• The others (mostly younger users) are fast-moving and flighty and are used to "skimming" texts and are dependent on certain "markers" that, from their point of view, increase the readability or comprehensibility of a more complicated text. This tends to be more the visual type.

In fact, it's not about breaking or following rules, but about providing purposeful answers.

The solution is what matters, not the backticks!

So, strictly speaking, this question remains unanswered, but not because there are too few profound positions on it, but because we humans are simply too different to lump them all together.

Different generations, and different learning types, different cultures & perspectives.

And that's a good thing! Long live diversity!

Answer 1

I think the current formatting is sufficient. Italics to indicate node names feels adequate for highlighting them, I don't think they deserve any further distinction from other UI elements like menu structures, panels, buttons or other interface components.

Contrary to what this question suggests, nodes have been around for quite a while, we've had Cycles Shader nodes for what feels like an eternity now, for more complex computations in the modelling area before Geometry Nodes existed we've had Animation Nodes and Sverchok, and long before all of them we've always had legacy Blender Internal Material nodes and Compositing Nodes.

I don't feel geometry nodes are any different nor deserve special treatment.

When I mentioned "the formatting rules" I probably used too strong a word. That was not what I meant, they are more guidelines than actual rules.

They've been around for a while, far before I was even participating here, and we do tend to stick to them for consistency sake. You're free to follow them or ignore them (though we'd prefer if you stick to them), the same way other users are free to enforce them by suggesting edits. I never really questioned them because they seemed adequate, and judging by how consistently they've been used so far, and how this never came up before despite the visibility our edits provide, I'd say most users would tend to agree as well, or at least are not bothered enough to question them.

Now I don't feel strongly against using different formatting for node names, nor stronger highlighting. If we do decide as a community to use something different I'm all for it, but I still think using code ticks are too disruptive and potentially misleading so I'd go against that specifically.

As suggested by Campbell Barton backticks can be used for actual code or some times for values, but for node names may cause confusion with actual code, file paths, driver expressions or other truly monospaced data which may coexist in the same answers.

As moderators we don't have the ability to introduce new formatting markup or methods, that would require an accepted feature, and corresponding development and testing from the site administrators.

One possible alternative if you really feel any node requires further highlighting, and I may actually be useful and educational is using documentation links in node names like Curve Circle Node or Add > Geometry > Convex Hull in addition to Italics. This seems to create enough distinction and value, at the expense of extra work for the writer.

I wouldn't enforce it for the overhead it creates neither for answerers nor editors, but would certainly welcome users who went to the trouble of including documentation links in their post.

This has to be a community decision, I'm open to other suggestions, so lets see what others have to say about this.

Answer 2

I am more of a passive user in this part of StackExchange (reading posts only). I just read through all of this and very much have to agree with @quellenform that for new users its almost impossible to understand alot of the things written about Nodes. Not just Geometry Nodes.

Having an extra formatting available for them would be great. The post which was litterly linked here and blames about missuse of Backticks has a lot of informations about Backticks and that they are quiet often used for other things than code as 0.5 Numbers or telling where to find options File > Settings > Window > Mode. Also for keys to better differentiate between l and I.

Me as a fairly new user in this area can hardly ever understand post about Nodes because of bad formatting and have to read the same part 2-3 times. This post here I understood the first time reading it.

I understand that having an extra formating as html tag would not fit the html rules but it is fairly often used to have an addapet version of Markdown in use. Even _Subscript, Stroked, underlined or ^Superscript was not always 100% default Markdown Syntax (sad enough <u> does not work here) and in some Editors have to be enabled first. Still they are widly used as ~sub~, ~~stroked~~, __underlined__ and ^superscript^. Sometimes they may have slightly different chars as marker but they still are part of a Markup language just maybe not the 100% default Markdown.

What I am trying to say is, that one could just add a new type of char that then translates into some html tag or html div box with inlinestyle. I understand that the div box may not be appropiate but a standard would be to have ==highlighted==. Which is fairly widly used and still does not exist here on StackExchange.

I think having some more options to style your questions/answers easly would be very helpful and would lead to less "Wrong" Styles.

I know these were not needed the early days but we have alot more technical things to talk about today than we had some years ago. In that way also the ways to Style your questions may have to adept to the greater amount of information, technics and problems we have today.

Answer 3

This is a bad idea for at least these reasons:

• Perversely, adding typographic styles to text often makes it less readable: It's hard to use consistently and used inconsistently leads to confusion.

• English has had a convention for such situations for at least 100 years and it is called out in most style guides, especially those used for technical publication. If you have 'foo type A' and 'foo type B' and you need to disambiguate you either

1. Always specify the second part of the phrase; or
2. Specify in advance that if the second part is left off it always means 'type B' and always specify the second part of the phrase for 'type A'.

Here are two contrived examples:

Now we apply the cube node to the cube object and see that the cube object has been transformed by the node.

Now we apply the cube node to the cube and see that the cube has been transformed by the node.

• This is the convention followed in the Blender manual and I'd score 'consistent with manual' much higher than 'another convention to learn'.

• Meanwhile text is reserved in technical stack exchange for code and other computer text to simulate what the text would look like on a monitor. I think it's a bad idea to overload that meaning with what amounts to an attempt to use bold text.

Aside: The manual uses Modifier–Key to signify that a key is typed while a modifier is used. I prefer this endash format over other ways of tying the modifier to the key for consistency; and wish that were part of our standard.

Answer 4

So as Duarte Farrajota Ramos recommended, here is my suggestion so this can experience votes:

Bold and italic are essential for formatting text and giving certain words a specific meaning. They are not an option for highlighting nodes.

What is not an option is:

• italic
• bold
• underlined
• Key

Which sounds interesting, but is not practical:

• linked
• other highlighting that would require HTML code

What might get in the way of code:

• Backticks

But since in the universe of Geometry Nodes usually no paths, code fragments or things are used, and if then only in absolute exceptions, only one possibility remains: Backticks.

So, since there is no single way to format a node differently, my recommendation is:

Use backticks (`) to delimit a (geometry) node as such from the text

...but avoid it if it is not really necessary

This allows to distinguish Cube from Cube.

_{But the irony of the whole story is: Those who would benefit from the better readability and subsequent comprehensibility don't even read (and vote) these meta posts, but it's only those who make the rules anyway or are already so familiar with all the stuff here that any irregularity immediately catches their eye...}