Ignition Project Development Style Guide

General Discussion
1

I’m working on an Ignition Project Development Style Guide. It is here: perfectabstractions.com/perf … guide.html

Any style suggestions are welcome.

2

Hei,

Thats nice! :smiley:

This is based on the polling result, isn't it? Now it becomes a "norm". :smiley:

3

[quote=“ian”]
This is based on the polling result, isn’t it? Now it becomes a “norm”. :smiley:[/quote]

I’ve never been accused of being normal… :wink:

4

Normal is overrated :slight_smile:

5

Haha... it is a compliment... :thumb_right:

6

Thanks Nick.

7

Hi Chris,
You are welcome :slight_smile:

8

Both PEP 8 and the Google Python Style guide advise using lowercase, with words separated by underscores (lower_with_under) when naming variables, functions etc. in python scripts.

I'm curious as to what rationale you have for standardizing on use of lowerCamelCase for custom property names, parameter names, as well as python variable names, python function names etc. as indicated the current version of your style guide.

Is there any deeper rationale beyond the poll you ran in 2015?

I'm in the middle of attempting to generate my own style guide and am looking for as much best/standard practice info as I can find. Thanks.

1 Like
9

This was 8 years ago and Nick Mudge is no longer doing Ignition work.

But my take on it is that since Ignition uses Jython, not Python, and there is frequent interop or calls into Java code where the lowerCamelCase convention is used, it actually ends up looking more natural than the style you'd otherwise use in pure Python development.

4 Likes
10

@Kevin.Herron...

  • Does the IA development team tend to use lowerCamelCase when creating jython scripts, or something else, or no effort to standardize that at all?
  • Does IA have a style guide or any sort of best practices guide for internal development use a that could be made available for integrators (officially, or unofficially)?
11

PEP8 also says something along the lines of "this is a guide line, but what's really important is to be coherent with already existing styles". Java tends to use camelCase, so it makes sens to use it for jython too.

That said, I absolutely do not follow this rule, for 2 reasons:

  • I feel dirty when I use camelCase for variables and functions names
  • having them in snake_case allows me to make a distinction between built-in and custom stuff.
3 Likes
12

We generally use lowerCamelCase, you can see it in the signature and parameters of the system scripting functions. Scripting examples in our documentation tend to use this style as well.

I don’t know if we have a style guide available. Maybe sales engineering does? For most users their Ignition project isn’t and doesn’t need to be treated as if it were a sizable software development project.

13

IA has a best practice style guide that was written for the exchange.

Exchange Resources Style Guide v1.pdf (1.0 MB)

3 Likes
14

:man_facepalming:

It recommends the use of system.util.getGlobals() in gateway/Perspective scope with no warnings whatsoever on what is safe to put there.

2 Likes
15

When I see mixed naming conventions, I feel like something about it just seems untidy, and given that Java typically uses UpperCamelCase for classes and lowerCamelCase for methods, I have adopted the same convention in my Jython scripting. However, there's a compelling argument to be made for employing varied casing to prevent potential naming conflicts. Not long ago, I read a forum post where a library script's folder name coincided with an imported class name, leading to unforeseen issues that were challenging to pinpoint. For custom methods, Ignition provides a safeguard that won't allow naming clashes, but nevertheless, I can imagine many script reading scenarios where being able to immediately recognize a custom method from a built-in one would be beneficial, and as Pascal noted, using mixed cases effectively allows this.

16

@jlandwerlen, where did you acquire this from (web page URL please)? I was surprised my previous searches had not turned this up and am now even more surprised that I cannot find the source given I already know the filename.

17

I think IA sent it to me when I wanted to upload an exchange resource. I assumed it was available publicly, perhaps it isn't.

18

Hey Tyler, we're actively working on pushing through a couple updates for the Exchange Style Guide and are also working to make it more publicly available.

1 Like