Thingworx Coding Best Practices

[PreetiGupta]

Hello All,

What do you follow as coding best practices within Thingworx Platform. I see that there are Thingworx Modeling best practices videos available.

Can you share what you do as code review best practice in Thingworx?

Preeti

[wposner-2]

Being that coding in TWX is all Javascript, it's best to just leverage common best practices around Javascript development.  For code review, I tend to enforce the following:

service named correctly (Services begin with uppercase)

service has a description

service has a header (at a minimum, developer name and date created)

service has appropriate comments

service has error handling

service input params named correctly (params begin with lowercase)

service has associated unit test

[PreetiGupta]

Thanks Wayne.

Wondering if anyone has any other suggestions?

[CarlesColl]

Here you have exactly the same question: https://community.ptc.com/t5/ThingWorx-Developers/Thingworx-Coding-Best-Practices/m-p/615944

[Constantine]

Hello,

My personal top-15:

1. Check naming against your naming convention for everything (entities, services, properties, etc.). You'll need to define and document it first, there's no "standard".
2. Make sure there's as few code as possible. ThingWorx (currently) has very little (if any) support for code refactoring, so you should always try to reduce amount of code you need to maintain.
3. General sane coding practices (small services, no deep nesting, ...)
4. Define user groups and org. structure first. Think about visibility and permissions early, ideally before writing any code. Refactoring it at the later stages may be very painful.
5. ThingWorx has little to offer in support of OO encapsulation, so I advise to use naming convention instead. For example, I use the following:
   1. External... (e.g. ExternalGetDevices) to specify a service as something callable from REST API;
   2. Private... (e.g. PrivateCreateUser) to say that a service is private to this Entity and won't be called from mashups, other entities, etc.;
   3. Protected... (e.g. ProtectedAfterCreate) to indicate a service to override;
   4. No prefix means "public" by default;
6. Make sure you and all your team members understand clearly how Nulls and Undefined values work in JavaScript in general, and in ThingWorx in parcicular. Make sure your code handles "empty" values.
7. As in any programming language, avoid masking / catching exceptions. At least don't do it too early.
8. Define some logging convention (log priorities, message prefixes, message format, etc.) and stick to it, this will save you a great deal of time troubleshooting.
9. Use batching operations for Infotables, adding to Streams, etc. whenever you can. Generally speaking avoid loops whenever possible.
10. Prefer using ThingShapes over ThingTemplates whenever possible -- this will give you additional flexibility to mix them later. Avoid deep inheritance hierarchies.
11. Use Projects and Tags to modularize your work. Reduce public API perimiter via naming convention as described above. Test those modules separately, if possible.
12. Test critical parts of your application, at least via calling REST services. My company is currently working on a TwxUnit framework, which will help writing proper unit tests for ThingWorx, should be available for public usage by the end of Summer.
13. Keep your entities under Source Control and implement code review as part of your pull request process. Ask your most experienced developer to check all code before merging commits. You won't believe how many bugs we avoided by taking this simple measure.
14. Retire old and/or unused code ASAP to keep your codebase small.
15. Don't document too much too early. ThingWorx encourages trial-and-error type of development, and your documentation risks to become outdated very soon.

That's all I have in mind for the general coding practices. There are plenty of tips-and-tricks for using different storage mechanisms, mashups, REST calls, etc. -- but the scope is too wide, so for this I would recommend you to take a training, read the docs and ask questions as they arrive. One of ThingWorx strongest points is its ability to prototype very quickly, so the best way to learn it is to practice more.

Regards,
Constantine