cancel
Showing results for 
Search instead for 
Did you mean: 

Code Object Names > 40 Chars long : Problematic?

Former Member
0 Kudos
1,288

Dear Sr PowerBuilder Developers

I am wondering about this issues and its potential long term effects:  What does your experience say?

Help Doc: Section --> Identifier Names describes them as a term given to name "variables, labels, windows, controls, menus and anything else you refer in scripts"

Among the rules for identifier names:  Can have up to 40 characters but no spaces

BUT in the help doc section "Naming the DataWindow Object" it says "The DataWindow Object name can be any valid PowerBuilder Identifier up to 255 contiguous characters"

We have many code objects with names that are longer than 40 characters.  In some cases names are not unique until beyond 40 characters

Painter Save dialogs do not limit the number of characters entered and allows saving with a name that is greater than 40 characters

The compiler permits declaring both and identifier names longer than 40 characters.  Both References and assignments are legal

Source code control (with TFS) properly exports / checks In / checks out / imports long named code objects

BUT I encountered one problematic situation:  Export - The Export dialog displays the name truncated at 40 characters.  It does this both in both v12.5 & v12.6


We are considering launching a project to shorten object names.  - But I'm not sure of the real value of the effort.

To your knowledge are there other issues that arise from super-sized names?  Aside from the Painter bug/quirkiness are there other potential pitfalls?

Thanks

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi Yakov;

  FWIW:

  Just an FYI that the <= 40 rule for object names is also the expected standard in Appeon Web & Appeon Mobile as well. So just in case you wanted to enable your PB applications in either of these realms - I would strongly recommend adhering to the 40 maximum character object naming restriction.

Regards ... Chris

Former Member
0 Kudos

I just re-read the documentation I have for the PBL internal structure and it looks like the object name is variable length so the limit is whatever the painters say it is.

I would lean towards saying the inconsistency is due to poor coding practices rather than some half done upgrade.

Former Member
0 Kudos

I just opened a case with SAP about the Export dialog name truncation. 

I just sent and email to Appeon support asking exactly what happens when a long name object is deployed.  (unfortunately our Appeon eval just expired)

Let's see

Thanks all for your input

Former Member
0 Kudos

Here's another thing I just about concluded (what a time drain) perhaps this 40 character "limitation" only applies to actual code objects.i.e. Class Types 

As I mentioned above,  the help doc section "Naming the DataWindow Object" it says "The DataWindow Object name can be any valid PowerBuilder Identifier up to 255 contiguous characters"


The 40 char limitation only applies to "variables, labels, windows, controls, menus and anything else you refer in scripts"  Not DataWindow Object names.  They are never referred to in scripts

I'm arriving at the conclusion that all the hullabaloo doesn't apply to datawindow object names to begin with, It's not an identifier.  Yes, it's the name of a packed definition string in a PBD - but it's not a powerscript object type - It's just a value assigned to a string type a property named dataobject.

Chris, What does the Appeon Doc says about DataWindow Object names?

ricardojasso
Participant
0 Kudos

Coincidentally, I just happened to run into a case today of a datawindow with a name longer than 40 characters. When I open the datawindow in the datawindow painter and select the Save As... option from the File menu PB crashes miserably with a GPF (PB 12.5 Build 2511).

I could create the datawindow with such a long name though. The problem is when trying to save it with another name. PB crashes before I can even get to the Save As window.

Maybe it is a bug fixed in later builds but this tips the balance in favor of staying within the 40 character limit....

Former Member
0 Kudos

Thanks Ricardo,

It took me about 1 second to duplicate the bug.  Picked one of my long named DWOs, Opened it and did a Save As.  -- Boom Boom Bye Bye

Former Member
0 Kudos

Yep, stay <= 40. I seem to remember way back when, when a really safe length was <= 38 (really safe zone) for object names. That coiuld have been a bug in an older PB version. Then again, maybe I'm just loosing my grip on reality ... LOL!

Former Member
0 Kudos

Hi Yakov;

  The latest Appeon documentation still says <= 40 characters for all object names - regardless of their type.

FYI; Also from the Appeon help ...

Unsupported

  • Objects of different types cannot have the same names.
  • Objects of the same types, even if they are in different PBLs, cannot have the same name.
  • The “Ω” will not be automatically converted to “ω” in Appeon. 
  • Identifiers cannot be reserved words in Appeon: appeondatawindow, appeondatastore, appeonservice, appeon_nvo_db_update, appeonextfuncs, appeonfileservice, ejbserial, ejbobject and parse_retval_object.

Regards ... Chris

Former Member
0 Kudos

DW Control Property Sheet - Name Property - chops at 40 chars

But with long window and datawindow names Deployed to Appeon and ran both mobile and web with NO issues
Here's the proof

.

Former Member
0 Kudos

Thanks for the efforts to do a quick test! 

FWIW: For now, I would advise people to stick with the PB naming limitation of 40 characters as Appeon also reflects in their documentation just to be on the safe-side until Appeon states otherwise.

Just my $0.02 ( as they say in construction - "safety is job #1") 

Former Member
0 Kudos

Thanks for giving your 2cents plain Chris

I conducted this investigation because I am working on a system with several hundreds of preexisting long named objects.  I needed to fully understand the risks and implications and weigh them against the significant effort to refactor their names.

I am going to issue 'an advisory' about long names to my team members. I will describe the development time risks (painter bugs)  But based on what I know know, they pose no significant runtime risk. I am now concluding, despite what I said above, that it is not worth the significant development effort to refactor (shorten) object names

Former Member
0 Kudos

I agree .. if it works now - then you are "most likely" OK and its not with the refactoring effort for now. If a situation occurs that is caused by a long name, then open a ticket to fix it as each situation occurs. In the mean time ... an advisory to try and keep the developers perspective on this potential problem for new work is a very wise move IMHO.

Hopefully, Appeon can officially address lengthening the identifier name limitation in one of their releases as part of their new 5 year plan that Armeen outlined on March 8, 2016.

Have a SUPER day! 

former_member1333806
Active Participant
0 Kudos

FWIW, PBL Peeper got a bug report on objects exceeding 40 characters years ago; I'd tend to buy into Roland's suggestion that it was around PB10. I believe I looked found documentation in a place I considered obscure (e.g. In a ReadMe instead of help). It's been like this for years, so if there were more bugs than the export, I'd be surprised. I'd agree that the effort is probably a waste.

Good luck

Former Member
0 Kudos

Hi Yakov;

  The official answer is 40 characters for class names since way-back-when. I know that you can often save object names > 40 - but, I have been caught later on on full builds and compiling to machine code when names are > 40.

FWIW: I'm an old ANSI standards guy - so like to try and keep all my names around 32 characters. That gives me a little "safety margin". To effect this length, I have a pretty stringent naming convention and acronym replacement that I use. I don't shorten names <= 32 characters - although, I have standard prefix & suffixes that I ways append. Once a base name is > 32 characters I start substituting acronyms until the length drops below 32 (starting right to left).

For example: custom non-visual user object that controls offender address information for the Correctional Services Canada system that works in English. Note: System identifier is known acronym right off the bat.

Format:  prefix_system_entity_extension_qualifier_suffix

1st cut: nc_csc_offender_address_manager_en      => 34 characters (I might even leave this "as is")

Final:   nc_csc_offender_address_mgr_en              =>  30 characters

   Note1: If name was still > 32 .. Address => Addr

   Note2: If name was still > 32 .. Offender => Offndr

IMHO: You should never need more than 40 characters to name something and still have it meaningful. Conversely, creating useful names <= 15 characters could certainly be too cryptic to understand easily. Some common sense needs to prevail. However, the bottom line IMHO is naming consistency.

Regards ... Chris

PS: I use the same approach for events, functions, variables, etc.

Former Member
0 Kudos

Thanks for sharing Chris,

Unfortunately, in the almost two decades this system has existed many minds coined descriptive object names while their hands merrily typed those  long names into the PB Save dialog with total impunity.

So, while you are preaching to the choir, please recall the non-members on the outside

Former Member
0 Kudos

Yes, I've seen a lot of Application systems like that.

Sounds like you maybe just need a name clean-up project for just those names > 40 characters? Should be easy to write a PB application to scan for large names in your PBL's. 

Former Member
0 Kudos

I have a list of over 400 code objects.  On the implementation cycle, it's a mechanical refactoring job.  But since PB doesn't have built in refactoring tools, it's not a trivial task.  Deriving new names is the most formidable task.  Your guidelines might prove useful in the quest to standardize naming going forward.

But I'm not convinced that the effort is totally necessary.  Most of these code object have been in production for years to no ill effect.  I suspect this whole situation is the result of a few painter flaws and lack of clear guidelines. Until I went about exporting & testing painter Save and references lengths, I wasn't aware of the mess.

I posted this with the hope that someone knows the internal spec and can make a clear statement.

I will open a case about the Save name length and the export name chopping and see what response I get.

Former Member
0 Kudos

Infomaker (10, maybe even 12) definitely had problems saving reports (datawindows) with names > 40 characters even though the painter allowed it.  As far as I know, the IM IDE now restricts all objectnames to 40 chars or less. I've always stuck to using < 40 for all my PB objects.

Former Member
0 Kudos

When the IDE automatically exports the object in preparation for a source control action (add or check-in) does the name get cut off or is it only when doing the manual export?

My understanding of the PBL internal format leads me to believe that PB 10 and higher have a limit of 113 characters for object names (including the .sr*) part. Is that something you can verify?

As long as the source control auto export/import process works, that it will probably not be an issue.

Former Member
0 Kudos

Hi Roland,

SCC exports are correct. (Otherwise we would have dealt with this a long time ago).  It is only with the IDE export

I just tried a PowerGen Library export on one PBL contain long names objects. It choked on one of the long named objects

I suspect there is some legacy undocumented modification behind this phenomena

Former Member
0 Kudos

Using the ol' 1 Mississippi 2 Mississippi count, I got to 12 before the IDE blew on SaveAs
(but it still saved to PBL)

But the export dialog defaults to 3mississippi

Hike!

Former Member
0 Kudos

Hi Yakov;

  FWIW: My bet is that Sybase were secretly expanding the object name support from 40 to 100+ characters (maybe even 255 like the new ASE) but never completed the task. That is why you can get away with longer names in some areas of the IDE.

  Personally, I would always still use the < 40 character name rule to be safe.

In Newfoundland Canada when anything blows, they say: "Whale Oil Beef Hooked Bye"! 

Regards ... Chris