Best Practices

[ptc-2605080]

Anyone have some best practices they'd like to share?

Design well!

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[jbeckley-2]

Hi Geoff,

You and I have had this discussion before haven't we...? 🙂

It's always great to find a way to make your applications clearer for you to read and understand. I like to set variable names that make sense, like appending the model name to the reference name such as "BOLT_MATE_SURF" or "WASHER_CENTER_AXIS". Some folks like to truncate their names, others like to keep them long.

A major thing that I've found helpful is to append the word "_REF" or "_DIM" to my UDF prompts, so that I can visibly see in the CREATE_UDF block which is the prompt and which is the SA Variable. When I build my udf in Creo, I just simply type in the prompt value for my references and add "_REF" to them. For dimensions, I just name them "_DIM". Obviously this is if you can rename the dimensions. Some models are already named, so your stuck with what you get.

The other thing I've found useful is naming my FOR loop variable name with the "each" prefix (in lowercase). It would look something like this:

FOR eachAXIS REF ARRAY ALL_AXIS

STOP
Thanks!

[#3]

Hello Geoff,

I think generally as long as it makes sense to you and works then go with it. If you're working with others who may need to maintain or modify programs you created then it can become a little more difficult because what may make sense to you may confuse someone else. I personally do something more along the lines of what Joel talked about, using names that makes sense and using things like '_REF' and '_DIM' to differentiate those two things. Also when I have a variable that is internal to the SmartAssembly program I try to put 'SA_' at the beginning so I know it is just used within the program.

We have talked about creating some standards for writing SmartAssembly programs here at my company but it can be difficult because everyone does things slightly different. What we have done is come up with a standard template to start new programs from and have developed a library of commonly used code sections that can be copied and pasted.

I find that the two biggest things to help others understand and follow the code is to use good comments and to properly tab IF statements, FOR loops, WHILE loops, assembly statements, UDF statements, etc...

Zach Miller

[jbeckley-2]

One thing that we can not stress enough, is the importance of commenting in your scripts. I see a lot of examples from folks that have little to no comments, and I always wonder how they remember what they did.

Comments are your friend.

Joel Beckley

Application Engineer

SIGMAXIM

[cfuller-2]

I'd like to comment on that.

[cfuller-2]

One thing I find helpful is to keep a document (I call mine a "textbook") that stores any section of script that I re-use, along with a brief explanation of its logic. Instead of having to find the old script where I used that method, I can always just go to my textbook, find it, and copy it. Tsome examples of things I have in my textbook are:

• 
  
• a method to create unique pairs of objects from two different arrays
• 
  

[ptc-198847]

Charles,

Would you be willing to share your "textbook"? It sounds like you have some good information that the user community could leverage to expand their knowledge and use of Smart Assembly.

Doug

[cfuller-2]

Most of the techniques I have in my textbook are pretty specific, but if someone needs help with a problem that I have already documented, I'll definitely post any relevant info I have.

[cfuller-2]

...That being said, when I do come across something that has more general use, I'll post it up in a separate thread.