https://netsuiteprofessionals.com logo
Join Slack
Powered by
When entering scriptids for objects in NetSuite, w...
# suitescript
b
When entering scriptids for objects in NetSuite, why do consultants usually use an abbreviation/acronym of the customer's company name? If putting a prefix at all, wouldn't it make more sense to use the consultant's own name instead?
s
One motivation to do this is to make it clear that the object was added on behalf of the company for their customization use and to avoid naming conflicts.
Consider, when that same customer adds some SuiteApp to their account, it too may create a bunch of similar objects. Having a naming convention helps eliminate naming collisions
that said, I'm not the biggest fan of a company name prefix on objects... In my opinion the company should get the 'global' namespace and any installed bundles/suiteapps should ensure unique names (i.e. they are the ones that should be using special prefixes)
I can't think of any situation where naming an object based on the consultants name would make sense? please tell what you're thinking there.
b
Consultant using the customer's name instead of their own makes it harder to identify the consultant as the maintainer of the field
⭐ 1
custbody_stalbert in stalbert's account offers no hints to who created and uses the field
s
not sure what you mean by 'maintainer' but to me a field's name should clearly indicate its purpose
b
custbody_battk in stalberts account means you should probably find battk if you have questions about the field
😂 2
s
I don't think who creates or uses the field is something that should even attempt to be encoded into a field name.
that field should be named custbody_the_field_meaning without any names or other changing information attached.
knowing how/where that field is used is a separate concern, and often one that can't possibly be handled by any naming convention
if the field maintainer changes but its purpose remains the same, do you update the field id and all references to it?
b
honestly depends on your consultant
my personal answer is you chose the wrong consultant if they aren't confident enough to change the id
b
I agree with @battk. That's exactly what I was thinking. I work for a NS partner and many of my coworkers use the client's prefix as I've seen done at many other companies. This was especially annoying when creating an SDF project. In the SDF add-on for WebStorm, you can search for objects to import into the SDF project from NS. The only way to search is by object type and scriptid. It would have been so much easier if they had used our company's prefix. Then I could have just searched for that prefix. Instead I had to meet with many of my coworkers to find out exactly which objects we needed.
💯 1
c
Damn that's a stupid solution
The only place I've seen the clients name used is in the GIT repo. Why would you encode that sort of metadata in a field or object name? You now supposed to care who wrote the original code, that person will be long gone at some point.
b
to be clear, i dont actually mean a person's name
s
I'm with Craig on that.
c
Or does your code / fields / objects only live as long as the consultant? Do you change the ID's when a new consultant takes over?
b
thats mostly useless, more aimed at company
b
Usually consultants will create their own folder in the file cabinet for their own scripts
c
Damn that's even stupider
Actually - that's less stupid
but still stupid
s
We do that - create a folder to act as a virtual root
c
the folder names should relate to your domain
b
Haha, well it's extremely common
s
subfolders of that can be domain/solution specific
c
many things are common
SuiteScript is full of cowboys of all varieties
s
but doing so is an easy way to avoid file name conflicts and support relative paths
b
Yeah not saying common means correct
c
You're literally encoding a time limited meaning to a piece of work. It won't age well
s
If you have a better argument for folder naming I'd like to hear it, though it's a bit off topic
c
domain driver language should drive your naming conventions
*driven
s
with the case of the folder name - the name itself is rather irrelevant - it's only acting as a virtual root folder.
c
If you find a 'craig' folder at lonelyplanet.com - what're you going to do about it?
I guess company/partner name might be ok - just like java package namig conventions
c
Having a set naming rule for your company & accompanying documentation is good, but I get that smaller companies don't have that option when they hire externals to deliver outsourced shit
c
In defence of outsourcing, it's not all shit!
c
I know 🙂
4 Views
Open in Slack
PreviousNext
Powered by