I am not so sure.

I am all for getting rid of prefixes/suffixes in code but in ServiceNow + JS - there are different problems. 

For one thing, JS in ServiceNow can have client scripts, server scripts (read controller) and database calls. There is no easy way to identify which's which. For me, when I see a piece of code prefixed or suffixed with 'gr' I know there is query (provided it is followed properly) and my focus would turn to what it's doing, is it needed and can it be optimized. Some of the performance bugs that I have fixed have taught me to look for the dreaded 'gr'.

Secondly, it is not practicable to expect people to name everything properly. Thinking of a good and correct variable name is actually much harder than it seems for any code/statement that does something "substantial". Further, for many, english is not event the native or first language. That's no excuse to name badly, but it does affect the kinds of name we use in code. So, at least with a badly named 'gr', I know it's a query and can be looked into. I think likelihood of ServiceNow developers using 'gr' incorrectly is much less than likelihood of using a misleading name. I might be wrong on that though.

Finally, let's take the example you've mentioned:

activeIncidents might mean activeIncidents from incident table today, but we all know how software changes. Tomorrow, say, if we fetch activeIncidents from a "script" (or some process other than a table query) and not from 'incident' table. So then there are two usages of activeIncidents but both have different meaning, data source and - in all probability - intent.

prefix/suffix 'gr' won't solve this, but if you're using 'gr' all through, you know it's a query. If it's a script (and assuming you follow the 'gr' convention!) you won't prefix/suffix it with 'gr'. That way, I know one gets from table and one from someplace else.

 

I think ServiceNow + JS combination makes it usage of prefix/suffix rather valuable. I would say it's one way of reducing clutter.

But again, that's me 🙂