cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Documentation of code - ThingWorx best practices

SOLVED
Highlighted
Level 1

Documentation of code - ThingWorx best practices

Hi, I work for an FDA regulated company that requires a stringent documentation process of code. Is there a best practice or strategy for using the 'documentation' section of each entity?

Tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions

Re: Documentation of code - ThingWorx best practices

Hi Thomas,

I don't think so.

The options you have to documentate code:

  • Entity level Documentation as you said
  • Services
    • Description field at Service Level
    • Each Input parameter has it's own Description section
    • Output has it's own Description section
    • Code
      • You can use standard Javascript comments ( /* */ and // )
  • Properties
    • Have a Description field
  • Subscriptions
    • Doesn't have any Description Section you will have to relay on Inner Javascript comments or enforce to always on the inner code call a Thing's Service which it's documented
  • Events
    • Have a Description Section

Just one last perk, when you save an entity on the composer if you click on the button next to Save you can write a comment on what's modified.

As you can see TW it's well designed to documentate everything, where it fails it's then if you want to generate a "printable" version of everything you had write on previous parts. But you can enter on "Server" view and see everything you documented: "yourServer"/Thingworx/Server

3 REPLIES 3

Re: Documentation of code - ThingWorx best practices

Hi, Thomas.

I'm not sure that we have specific documentation that calls this out. Let me see what advice I can get for you here.

Thanks,

-- Craig A.

Re: Documentation of code - ThingWorx best practices

Hi Thomas,

I don't think so.

The options you have to documentate code:

  • Entity level Documentation as you said
  • Services
    • Description field at Service Level
    • Each Input parameter has it's own Description section
    • Output has it's own Description section
    • Code
      • You can use standard Javascript comments ( /* */ and // )
  • Properties
    • Have a Description field
  • Subscriptions
    • Doesn't have any Description Section you will have to relay on Inner Javascript comments or enforce to always on the inner code call a Thing's Service which it's documented
  • Events
    • Have a Description Section

Just one last perk, when you save an entity on the composer if you click on the button next to Save you can write a comment on what's modified.

As you can see TW it's well designed to documentate everything, where it fails it's then if you want to generate a "printable" version of everything you had write on previous parts. But you can enter on "Server" view and see everything you documented: "yourServer"/Thingworx/Server

Re: Documentation of code - ThingWorx best practices

This is helpful, thank you!