# Do's and Don'ts when developing First Project with Ignition? **URL:** \ **Category:** General Discussion\ **Created:** [July 23, 2024, 8:55am UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592 "2024-07-23T08:55:09Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Mitesh\_Maniar](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mitesh\_Maniar](https://forum.inductiveautomation.com/u/Mitesh_Maniar)\ **Post date:** [July 23, 2024, 8:55am UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/1 "2024-07-23T08:55:09Z")
Hi everyone, i am learning ignition to work on first project and want to know some tips/tricks to be careful while developing first project so i do it properly and organize tag structure, graphics etc in the proper way in my project ? thanks for all your help Regards, Mitesh. ---
**Author:** ![danielps1818](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@danielps1818](https://forum.inductiveautomation.com/u/danielps1818)\ **Post date:** [July 23, 2024, 9:56am UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/2 "2024-07-23T09:56:14Z")
Don't be scared of making folders. In our team we didn't do it until it was too late and we had a tree that looked like this _(and it was hell looking for anything)_: Scripting ├ randomfolder │ ├ class001 │ ├ class002 │ ├ class004 │ └ class003 ├ randomfolder2 │ └ class18 ├ class2 ├ class4 ├ class3 ├ class5 ├ class8 ├ class10 ├ class12 └ class7 Navigation in a project is key to efficiency and organization. Is preferable to have folders than a mess of files. Also, I really recommend making templates so you could reuse views. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [July 23, 2024, 11:46am UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/3 "2024-07-23T11:46:25Z")
Put everything into the scripting library, all events, property changes, tag events, etc should be one liners that call a library script. Multiple reasons for this - 1. your script library is version controllable/diff-able as it's plaintext. 2. Makes it easier test your functions. If you put your whole script in a tag change function now the only way to test it is to change the tag, where if its a function you can make your params and run it in script console (assuming scope is ok). 3. Decorate-able. If you you put all your logic in the event script then decorators will not really work for you, you have to manually change the script. But if a tag change event is calling `foo` and all of a sudden you want to start timing or logging stuff about your function now in your script library you can do a ```python @timeAndLog def foo(*args, **kwargs): pass ``` and now all locations you call foo get this/you can use this decorator on any piece of logic you have. 4) as hinted to above now the script is reusable. 5) some old scoping issues that you will avoid if you do things this way. Other tips about your project - get your database design right. Use the right data types for the right column types (ie do NOT use string to store dates), and use named queries or at least prep queries to run your inserts/updates. Use transactions and either make a appropriate primary key that truly determines a unique row, or if you are using an `id` primary key, at least create a UNIQUE index that will determine uniqueness of a row. Last issue that comes to mind that I see a lot in the field is putting things in the inappropriate scope. If you have a function that needs to reset a database table or tag values at 5 AM everyday that should be in the gateway scope not the client scope for instance because if the client happens to be off, then it won't run, or if you have 100 clients now you're wasting resources/making things confusing by running it 100 times. Inverse applies here too - do not use gateway tags to keep track of things regarding client UI. That is for client tags/session props. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 23, 2024, 12:24pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/4 "2024-07-23T12:24:12Z")
1. Do not attempt to **push** information from tags to UI screens. That is, scripts reacting to tags should not be used to notify affected UI pages/views/windows/templates. Instead, bind those tags to UI component properties to **pull** the information into the UI, and write any change monitoring scripts/actions **there**. 2. Scripts are resource hogs. Use them only for tasks that cannot be done any other way. In user interfaces, use bindings, preferably without script transforms. 3. Simple property bindings are fastest. 4. Tag bindings and named query bindings are **asynchronous**. When triggered by startup or a reference change, they do **not** hold up any other bindings. Use them, and reference them with simple property bindings, instead of curly-brace tag references or scripted queries. 5. Expression bindings are faster than scripts, as long as you aren't using `runScript()`. 6. If you must use a script in a binding, `runScript()` in an expression binding is faster than a script transform. 7. Avoid the `tag()` expression function like the plague. Because it **is** a plague. ---
**Author:** ![Ryan\_Deardorff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_deardorff/32/63815_2.png) [@Ryan\_Deardorff](https://forum.inductiveautomation.com/u/Ryan_Deardorff)\ **Post date:** [July 23, 2024, 6:13pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/5 "2024-07-23T18:13:21Z")
1. Bind UI input values to custom properties of the view, and reference those instead of the input value itself. It not only makes for cleaner code without a bunch of `getChild/getSibling` nonsense with hardwired component names, but ensures that you can reorganize and rename components without breaking those references. 2. Name your UI components/containers. It may seem like unnecessary effort in the short term, but in the long term it will save lots of hassle when trying to navigate your way down to a specific component. 3. Browse this forum regularly. I have learned many valuable tips just from reading responses to other people's questions. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 23, 2024, 6:22pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/6 "2024-07-23T18:22:02Z")
> [@Ryan\_Deardorff](#): > > NAME YOUR UI COMPONENTS 💯 (But don't shout.) ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [July 23, 2024, 6:25pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/7 "2024-07-23T18:25:18Z")
Honestly this is something that I always seem to ping pong back and forth on a good naming convention. Coming from the VBA/RSView side of things... I automatically for the lblTitle, txtBoxInput type of thing. Any good recommendations on naming? Or a standard convention that you use? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 23, 2024, 6:28pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/8 "2024-07-23T18:28:27Z")
PascalCase, mostly. I absolutely despise those type-prefixed formats. See the Exchange style guide for more ideas. ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [July 23, 2024, 6:30pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/9 "2024-07-23T18:30:18Z")
I'm actively trying to shed that muscle memory... So you tend to name things based on their purpose then? IE EntryMotorSpeed (numeric entry), ActMotorSpeed (label), things like that? ---
**Author:** ![Ryan\_Deardorff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_deardorff/32/63815_2.png) [@Ryan\_Deardorff](https://forum.inductiveautomation.com/u/Ryan_Deardorff)\ **Post date:** [July 23, 2024, 6:31pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/10 "2024-07-23T18:31:09Z")
> (But don't shout.) Yeah, that's the kind of frustration caused by leaving one's predecessor with names like "FlexContainer\_0" 🥴 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 23, 2024, 6:33pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/11 "2024-07-23T18:33:29Z")
> [@bschroeder](#): > > based on their purpose Yes. If the purpose is served by a container of a label, entry, and button, the **container** will get the general field's name, and the inner components will be `Label`, `Entry`, and `Button`. For ease of reuse. ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [July 23, 2024, 6:34pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/12 "2024-07-23T18:34:35Z")
Gotcha... I've been doing the same lately as well, and when revisiting older stuff and a refresh. I appreciate the pointers. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 23, 2024, 6:35pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/13 "2024-07-23T18:35:56Z")
Be aware that _fixing_ container and component names will _break_ views that don't use #13. ---
**Author:** ![Ryan\_Deardorff](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan_deardorff/32/63815_2.png) [@Ryan\_Deardorff](https://forum.inductiveautomation.com/u/Ryan_Deardorff)\ **Post date:** [July 23, 2024, 6:56pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/14 "2024-07-23T18:56:21Z")
I just try to give input names that match their purpose (like maybe the column name of the database entry its tied to). Containers can be as simple as Top/Bottom/Left/Right, or Header/Footer, but usually I try to describe their contents. I don't use the naming convention you mention, partly because I don't need to reference the input itself in my code (#13). The names mostly make it easier to navigate the view tree... ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [July 23, 2024, 10:06pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/15 "2024-07-23T22:06:46Z")
> [@Ryan\_Deardorff](#): > > "FlexContainer\_0" I registered for ICC 2024 under this name. Anyone else following this pattern remember to increment. ---
**Author:** ![ROrtiz](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rortiz/32/61395_2.png) [@ROrtiz](https://forum.inductiveautomation.com/u/ROrtiz)\ **Post date:** [July 24, 2024, 2:14pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/16 "2024-07-24T14:14:15Z")
Great thread with a lot of useful tips! ---
**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\ **Post date:** [July 24, 2024, 2:31pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/17 "2024-07-24T14:31:16Z")
If perspective and if something seems impossible, you have ask on the forum and people say its impossible, tag me (if i havent seen your post already). I might have some work arounds with css and js injections... 🧙 ---
**Author:** ![victordcq](https://avatars.discourse-cdn.com/v4/letter/v/f6c823/32.png) [@victordcq](https://forum.inductiveautomation.com/u/victordcq)\ **Post date:** [July 24, 2024, 2:32pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/18 "2024-07-24T14:32:49Z")
Dont use scripts to animate things in perspective, you must use css/style animations. ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [July 24, 2024, 5:08pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/19 "2024-07-24T17:08:47Z")
Re tag structures... one of the best things with our latest architecture was using folders reasonably. Some great advice we got: - Aim for Jython-friendly naming, mainly avoiding spaces and being careful with non alphanumeric characters. - Build tagpaths that are human readable and meaningful. Concise, but clear. - A plug for @pturmel's Spreadsheet Import Tool, which creates implied folders as it writes tags and UDT instances. This solves a common critique of UDTs being inflexible with their members. - Custom properties are your friend, and you can write these from within this tool for anything that needs to be unique but won't change over time. View paths and tag paths as custom property strings are quite powerful. - Related, check out the var map functions in the Integraton Toolkit module and let your mind lead you in creativity. I can't divulge my secrets but they depend on these var maps heavily. - Folders can have custom properties, even though you cannot see these in Designer (enhancement request?). But you can write to them via system.tag.writeBlocking() and via the Spreadsheet Import Tool. > [@Spreadsheet Import Tool](https://forum.inductiveautomation.com/t/spreadsheet-import-tool/93500/1): > > Now [in the Ignition Exchange](https://inductiveautomation.com/exchange/2660/overview). While waiting on IA review, i Interested parties can also get this here: [https://www.automation-pros.com/SpreadsheetImportTool/](https://www.automation-pros.com/SpreadsheetImportTool/) I intend to publish at this link as well as in the Exchange going forward. Announcements will be in this topic. (: ---
**Author:** ![Mitesh\_Maniar](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mitesh\_Maniar](https://forum.inductiveautomation.com/u/Mitesh_Maniar)\ **Post date:** [July 24, 2024, 10:37pm UTC](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592/20 "2024-07-24T22:37:49Z")
Thank you everyone for all the tips and tricks. i will need time to go through and understand. may ask some question to clear my understanding on some of the point later. have a good day [Next page](https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition/93592.md?page=2)