I’m working on an Ignition Project Development Style Guide. It is here: perfectabstractions.com/perf … guide.html
Any style suggestions are welcome.
I’m working on an Ignition Project Development Style Guide. It is here: perfectabstractions.com/perf … guide.html
Any style suggestions are welcome.
Hei,
Thats nice!
This is based on the polling result, isn’t it? Now it becomes a “norm”.
[quote=“ian”]
This is based on the polling result, isn’t it? Now it becomes a “norm”. [/quote]
I’ve never been accused of being normal…
Normal is overrated
Haha… it is a compliment…
Thanks Nick.
Hi Chris,
You are welcome
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.
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.
lowerCamelCase
when creating jython scripts, or something else, or no effort to standardize that at all?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:
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.
IA has a best practice style guide that was written for the exchange.
It recommends the use of system.util.getGlobals()
in gateway/Perspective scope with no warnings whatsoever on what is safe to put there.
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.
@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.
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.
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.