2 ms·

I work on code that uses `pid` pervasively, and it would drive me crazy if someone insisted I write out `processId` every time. Same with `tx` or `rx` for chann

I work on code that uses `pid` pervasively, and it would drive me crazy if someone insisted I write out `processId` every time. Same with `tx` or `rx` for channel endpoints, `i` for loop variables, `txId` or `tid` for transaction ID in databases, etc. If something is very common in the domain you're working in it's more annoying _not_ to abbreviate it.

Kim_Bruning 2y ago
In certain contexts, I'm ok with eg (off the top of my head): * x, y, z (coordinates) * r, g, b, a; c, m, y, k; y, u, v (colors) * i, j, k matrices and such * p, i, d; Kp, Ki, Kd in process control * rv (return value), where it is clear what The Thing To Be returned is. * common variables from eg physics Generally because these are well known and defined in particular contexts. I don't always make it, but sometimes an argument can be made that single letters are better known/recognizable by their single letter name. Compare: * total_energy = mass * light_speed_constant ^ 2 vs * E=m*c^2 Or: * process_control_setting = proportional_component + integral_component + derivative_component vs * q=p+i+d (for those of us who know PID control)
fwip 2y ago
Recently, I saw somebody writing that in their projects, they define a Glossary.txt of terms, and then set up their tooling to flag any use of an identifier that isn't a word or defined in the Glossary. (Allowing also for compound words like camelCase and snake_case, of course). So in their project they could define `pid: process identifier [...]`, and then their tooling would be allow a variable named `new_pid`. Upsides: consistent vocabulary in your project, a centralized place to look up jargon, and a subtle friction to avoid adding new terms that people might not immediately grok. I wish I could remember the source; because it sounded like a nice setup to steal.
kstrauser 2y ago
That "in the domain" bit is an excellent callout, and I'm stealing it. "Why don't you write out 'process_id'?" "Because the people who maintain the sort of code that cares about pids all refer to it as 'pid'."

Kim_Bruning 2y ago

In certain contexts, I'm ok with eg (off the top of my head): * x, y, z (coordinates) * r, g, b, a; c, m, y, k; y, u, v (colors) * i, j, k matrices and such * p, i, d; Kp, Ki, Kd in process control * rv (return value), where it is clear what The Thing To Be returned is. * common variables from eg physics Generally because these are well known and defined in particular contexts. I don't always make it, but sometimes an argument can be made that single letters are better known/recognizable by their single letter name. Compare: * total_energy = mass * light_speed_constant ^ 2 vs * E=m*c^2 Or: * process_control_setting = proportional_component + integral_component + derivative_component vs * q=p+i+d (for those of us who know PID control)

fwip 2y ago

Recently, I saw somebody writing that in their projects, they define a Glossary.txt of terms, and then set up their tooling to flag any use of an identifier that isn't a word or defined in the Glossary. (Allowing also for compound words like camelCase and snake_case, of course). So in their project they could define `pid: process identifier [...]`, and then their tooling would be allow a variable named `new_pid`. Upsides: consistent vocabulary in your project, a centralized place to look up jargon, and a subtle friction to avoid adding new terms that people might not immediately grok. I wish I could remember the source; because it sounded like a nice setup to steal.

kstrauser 2y ago

That "in the domain" bit is an excellent callout, and I'm stealing it. "Why don't you write out 'process_id'?" "Because the people who maintain the sort of code that cares about pids all refer to it as 'pid'."