For each customization project we work on, we use a 5 digit integer as the ID. This value is used as a reference across Epicor:
BPM group name
Start of screen customization ID followed by dash, ie 10000-1
Beginning of description on BAQ followed by dash, ie 10000-JobSchedule.
Beginning of description of dashboards followed by dash, ie 10000-Job Schedule Dashboard
Solution ID (pretty much useless because definition cannot be exported, but cab name becomes project id)
Documentation references in BPM code, stored procedures for RDLs, OneNote, etc
As projects evolve, the assets are then exported to a designated project folder and renamed with date stamps so we have a crude form of source control. This has simplified changes and also makes it possible to query relationships across the system to pull documentation together.
I often wish I worked for a company that had predefined standards for coding structure. I find myself constantly changing - and not always for the better. Or “slipping” back to lazy (yet still functionally correct) coding styles.
Sometimes I get in an ultra-strict mode and prefix all variable names with their type strFirstName, intCounter, edvMyView, etc… But other times just want to get the job done.
Is the following really more self documenting than the latter?
int intIndex;
for(intIndex=0; intIndex<MAX_INDEX; intIndex++){
foo(intIndex);
}
int i;
for(i=0; i<MAX_INDEX; i++){
foo(i);
}
I have found over time that sticking to the longer camel case variables are much easier for others to follow the larger programs that are written. Having 4 IT personnel working on different projects can really cause a lot of confusion if you are having to look up what “i” or “j” or “x” is.
I’ve used “i” since BASICA days, so I always assume it’s an integer
I used a heirarchy. In general the convention is type_module_specificname_version.
For type, it’s the general context: Dash = dashboards, Form = form controls/dropdowns, etc. There’s a generic class as well.
Module is the the next step. Which Dashboard, or Form, or dataset it’s interacting with. JobEntry, ProdCode, etc.
Third entry is the specifc BAQ: JobsOnHold, ActiveEngineers, etc.
Finally, version, though I don’t often use this one since I don’t really roll back dash or BAQ changes once I push them out. For versioning, I export the item and put the exported file in a local hosted GIT.
I don’t need to sort by who created the BAQ (which is usually me anyway), because the system already tracks that. I also don’t do Company-specific ID’s, because I find that if a query/dash is useful for one organization, it will probably be useful for another. If I need to filter by company, then Company will be an parameter within the BAQ.
Finally, while we all have to deal with char limits, I avoid acronyms where possible. Truncated descriptions? Sure, they’re necessary. I just don’t leave people with stuff like D_JE_JHS. Dash_JobEnt_HoldStatus or Dash_Jobs_HoldSt.
MS has a style guide for C#, though it uses the generic “var” for a lot of variable declarations in its examples, which isn’t best practice. VS will always suggest you change “var” to the actual type.
Also, as a general rule, strongly typed languages like C# frown upon including the type in the variable name. Declaring “int intIndex” is duplicative.
I’d love to be able to work out how to override the default file save location for the different components. Then I’d be able to just save into the correct location instead of having to navigate all the time.
Eg. Save a BAQ and it opens up the documents folder. Save a dashboard and it opens \3.2.400.0\TT\shared\Export folder the Programdata/. Download an RDL and it saves to Documents\Reports\CustomReports\
haha… back in the really olden days, I had a standard where all reports started with a 2 digit “system” code (PR = Production Control, SL = Sales, PU = Purchasing), and then a 3 digit numeric…
PR908 = Production Control Job Detail listing
SL908 = Sales backlog Detail
PR201 = Production Control Job Summary
SL201 = Sales Backlog Summary
Note that the numbers actually meant something too… the first digit “9” meant it was a detail, vs 2 meant it was a summary report. There were many other variations too, but that was 30+ years ago… The point is, there was a system, and that is how i remember it this long after.
Wow - interesting to see all the naming convention ideas. Everyone is trying to achieve order out of chaos.
My key contributions to this are:
Since there are generally a HUGE number of BAQs, I have found that the most helpful thing to do is to prefix each with one of the following:
TEMP_, DASH_, REPO_, QUIK_, POST_, SUPP_.
Each of these indicates the purpose/use. Probably the most important is “TEMP_”, so we know which ones we can safely delete to clean up the ever-growing list.
REPO is for BAQ Reports, QUIK is for Quick Searches, POST_ is used occasionally within Posting Rules, and SUPP_ is for support reasons, but kept permanently.
For Screen names, I definitely standardize on the word “ACTIVE”, so that you don’t have to keep updating all the menu items that refer to that screen. But, I also save a copy of the screen customization using just the date as the Name (in the format YYYY_MM_DD), so the history is there. All of this sorts well alphabetically, with ACTIVE at the top.
