How to most nicely write out the parameters for a named query

Ignition
1

A named query takes in a dictionary of parameters, which it uses to build the query. How to I most cleanly write out this dictionary?

Say I have a named query, located at end_of_shift_reporting/create_report_entry, which takes three parameters: machining_shifts_ndx, operator_user_name, parts_produced_during_shift, and returns the index that this new report was created at.
I take in some data from a button event, calculate these three above parameters, and have them in variables named the same.

There are two ways I can think to approach this: declare a variable, put my params in it, and then pass it to the function, or I could have an anonymous variable instead.

# first option
params_create_report_entry = {
		"machining_shifts_ndx": machining_shifts_ndx,
		"operator_user_name": operator_user_name,
		"parts_produced_during_shift": parts_produced_during_shift}
new_report_index = system.db.runNamedQuery(end_of_shift_reporting/create_report_entry, params_create_report_entry)

#second option
new_report_index = system.db.runNamedQuery(end_of_shift_reporting/create_report_entry, {
		"machining_shifts_ndx": machining_shifts_ndx,
		"operator_user_name": operator_user_name,
		"parts_produced_during_shift": parts_produced_during_shift})

Is there any particular (personal) preference between the two?
Additionally, where do people like to put those parenthesis?

2

I normally use option #1

params_create_report_entry= {
		"machining_shifts_ndx": machining_shifts_ndx,
		"operator_user_name": operator_user_name,
		"parts_produced_during_shift": parts_produced_during_shift
}
new_report_index = system.db.runNamedQuery("end_of_shift_reporting/create_report_entry", params_create_report_entry)

I move the } to the bottom on it's own line.

I typically use camelCase insted of the my_variable naming scheme.

I also like short hand names for variable names and parameters, but long names can help with understanding exactly what it going on.

I would write what you have as follows:

queryParams = {
		"shiftsIndex": shiftsIndex,
		"opUserName": opUserName,
		"partsProduced": partsProduced
}
newReportIndex = system.db.runNamedQuery("endOfShiftReporting/createReportEntry", queryParams)

It will come down to personal preference really. I see some people do option 2 as well, and that is more compact code, but I like a variable especially when I am building the params from other variables.

4 Likes
3

I also use camelCase, but for me it less "personal Preference" and more, because that is the Java recommended scheme, and so when using Java functions in Jython, it makes my OCD not go crazy, from mixed naming schemes.

I also prefer short hand names, but don't fall into the "Microsoft" trap. I'm looking at you LPCWSTR, and Hungarian Notation.

2 Likes
4

I always notice when I see LLM stuff from people where the LLM throws the underscore scheme in there and the person puts their flavor on top of it not realizing. I probably only notice because I too have a hair of the OCDs when it comes to code.

1 Like
5

oh, I'm completely a fan of camelCase (my background is java), it's just that all the code we have uses underscores, and I'd rather be constant in that regard.

One thing that I was not willing to be consistent on (and in fact went back and refactored) was prepending the name of any variable that was used in a named query with param_.

(The main reason I refactored was because we had a giant dictionary of parameters for this application, that seven different queries went and added to/ wrote from as they went)

6

This, but (in my opinion) go a step further - if, out of frame, you're doing something like:

shiftsIndex = referenceToComponent.custom.shifts_index

Or whatever... just do that inline in the dictionary declaration:

queryParams = {
	"shiftsIndex": reference.custom.shifts_ndx,
	"opUserName": reference.custom.operator_user_name,
	"partsProduced": reference.custom.parts_prod
}
newReportIndex = system.db.runNamedQuery("endOfShiftReporting/createReportEntry", queryParams)

It's a pet peeve of mine to see "someThingName": someThingName - drives me crazy :laughing:

5 Likes
7

I actually don't mind this code, because i've definitely saved myself from bugs due to

"someThingName": someThingElseName

immediately flagging itself to my eye as wrong where a more direct approach might not have been clear

8

One of the few niceties of JS is shorthand properties, every time I swap back to Python-land I miss it.

1 Like
9

My favorite is when there is a setter and instead of using something like “newValue” the actual variable name is used, so you end up with:

public void setSomeThing(someThing) {
     someThing = someThing
}

That hurt just writing it. :laughing:

2 Likes
10

I love this about JS. It's this an spread that I miss when I come back to the world of python..

1 Like
11

wait, do people not use self (or this for java) in those situations?

12

You would be surprised.

That will compile as is assuming the rest of the context is there.

Even adding the this doesn't make it much better. this.someThing = someThing.

13

It's still goofy looking, but at least it doesn't completely make no sense.

2 Likes