AppSource; Prefix, Suffix & Intellisense

This article was triggered by a discussion on Yammer yesterday that I felt went a bit sideways.

Business Central is a first class cloud citizen and it beats born in the cloud solutions easily but fact remains that it’s based on Navision, an ERP solution with a 30-some year legacy.

Part of that legacy is a requirement for unique names in the objects, also in the cloud.

Microsoft is working hard to remove this requirement hence it’s a temporary fix but the result is that every app on AppSource needs a three letter prefix or suffix.

You can register your TLA with Microsoft and when this is done nobody else can use it.

With Per-Tenant extensions you don’t need prefixing and I would actually recommend against it since there may be a fair change you’ll use one that is used by one of the apps.

At ForNAV I am primary responsible for the App we have on AppSource and we Prefix everything with ForNAV, hence we reserved “FOR” as a prefix.

I am probably a little autistic and I like stuff that looks clean, so my C/Side looks like this:

Had I suffixed everything it would have been so ugly to look at.

What about Intellisense?

If you watch my YouTube video’s or if you attended one of my classes you’ll have heard me say I recommend suffixing so this sticks into peoples heads.

However this is on a totally different topic. This recommendation is for people who are so stubborn that they want to cling on to Hungarian notation. This will affect Intellisense.

With an AppSource solution I would recommend (and use this myself) to leave our your Registered TLA of your variables all together.

Here is an example:

As a sidenote, Intellisense in Visual Studio Code works smarter than just the first characters, it would actually do a smart search and also suggest results that contain the characters even with small typos. It’s one of the things that make VSCode better than C/Side. (One of the few things though 😊).

3 thoughts on “AppSource; Prefix, Suffix & Intellisense

  1. Brian Juhl

    Actually i think we should use prefix for per tenant apps, just not your appsource prefix.
    What i do is use my registered prefix with microsoft, and append a L (for local).
    The chances that, that would cause issues is minimal, rather than hitting a ms refactor name.
    Just my 2 cent.

    Liked by 2 people

    Reply
  2. James Crowter

    Using the one TLA prefix/suffix is a solution when you have one app, when you have multiple and when you work at a partner trying to reuse custom apps they haven’t decided to put in AppSource its important. Adding an additional three letters gives you 46,656 extensions before you run out of possibilities.

    Liked by 1 person

    Reply
    1. Mark Brummel Post author

      I would be careful still using the same TLA on custom apps. You probably want to run both side-by-side when you decide to move it from custom to AppSource.

      Still not sure I see any reason to use this “technology” with Per Tenant apps.

      In my Master Class I always tell people the following: Give your objects meaningful names using words from the NAV Data Dictionary. If you somehow get a message the name is already used it’s most likely you are reinventing the wheel and you can reuse an earlier object. This means getting the error is positive, not negative.

      Not sure if the Data Dictionary is still published by Microsoft. Most of the Design Patterns project seems to have been forgotten.

      Liked by 1 person

      Reply

Leave a Reply to Brian Juhl Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.