A Simple Disclaimer
A style guide is opinionated, on purpose.
While many people perceive the act of writing code as logical and un-biased, any developer who has seen their share of spaghetti understands first hand that code is mostly (for now at least1) written by humans - and humans are deeply opinionated. For those coming to TouchDesigner from other text based languages, you're probably familiar the idea of a Style Guide. In other languages these often provide anchoring ideas about the best practice for a particular project or how an organization writes its code. Many are familiar with conventions found in the Google Style Guides or in PEP 8 - this resource makes no assumptions of importance, but does recognize the value of strong anchors for developers when they're writing code or connecting nodes.
Style guides are just that, guides. The suggestions outlined here aren’t hard and fast rules, but form and style conventions from people who have tried lots of different approaches, and made plenty of mistakes of their own. For any standard there are likely to be exceptions, challenges, and issues. Code the way you want to code, but also remember that you’re making something that other programmers (your future self included2) are going to return to, pull apart, question, interrogate, curse, praise, and judge. Your act of fixing an idea in an operational structure is both a creative act, as well as a measured and considered one. TouchDesigner networks are challenging to share and collaborate in – they are sprawling, nested, multi-layered collections of signal flows. That is to say that they are already challenging to decode – you don’t have to use this standard, but cultivate and implement one for your own sake, and for the sake of your collaborators.