Kodigo

There is no support to create our own Enumerations in PB. Fortunately there is the workaround of creating a nonvisualobject and declaring public instance varables as constants. This approach enables us to get the value without having to instantiate the nvo.

In the previous Kodigo, i prefixed all enumerations with "c" (e.g. CRet, CSvc, CString, CColor, etc)

For the new version, I will still follow this approach but will refrain from abbreviation (e.g. CReturn, CService, etc)

You can post any ideas regarding constants in this thread.

The common naming convention is a prefix of 'scope type underscore'. Example ls_xxx being a local string. Lately I have been thinking that naming convention used in C is nicer. That is to have the prefix in lower case followed by wordcapped name. I am thinking that the type part of the prefix is not needed since the compiler gives an error if you have a type mismatch. For example iFirstName would be an instance variable string containing first name.

How about using the underscore? The existing cret object would be _return.

OK, please correct me if I'm wrong. Let's assume we have a variable named FirstName

Scope:

• Local: lFirstName
• Instance: iFirstName
• Shared: sFirstName
• Global: gFirstName
• Argument: aFirstName

This is OK, but how about access to instance level (protected, private)? I was thinking of using underscores for that. Something like:

• Local/Argument: firstName - Camel case, no prefix. An argument is treated like a local declaration
• Instance Public: FirstName - Pascal case since it is publicly accessible, like a property
• Instance Protected: _firstName - underscored camel case. Developers will only access this when they inherit or extend existing services/classes, w/c would be rare.
• Instance Private: __firstName - double underscored camel case. Only Kodigo core maintenance developers will access this.
• Shared: sFirstName
• Global: gFirstName

I was also thinking of using the "_" and "__" for naming class functions as well to indicate access level(e.g. _myProtectedFuntion(), __myPrivateFunction())

For constants, I was also playing with different symbols after the preifx 'C', like, C$Return, C#Return w/c seems to be OK with PB's compiler.

Any ideas on the above? 

I just started coding something using my new naming convention idea and I don't really like not having the datatype as part of the name.

I am thinking this would be better:  lsFirstName, isFirstName, etc...

It is your project so your preference would be number one. As long as it is consistant and documented, other people should be able to understand it and use the same naming conventions if they want to create new services to make part of the framework.

I like the underscores for access level. having a symbol in the constant is good. I would lean toward #.

Historically I have just done constants as all caps (i.e. S_SOME_STRING, L_SOME_LONG) and use the same approach you do in Kodigo for reference to a constant object.  I like the cReturn.S_SOME_STRING approach personally.

 Something I learned in my military days:  Any standard is good as long as it is consistent.

Well said, thanks Grismare.

Roland, I also tried coding based on the proposed standards, and here are my thoughts: After so many years of Powerscript, it is difficult to unlearn the whole preifx/datatype way of writing, I only got over it when I imagined I was doing C#. But this framework will be used by PB developers so they will also face the same problem.

So based on the original proposal, here are the modifications:

variable string FirstName 

• Local: lsFirstName
• Shared: ssFirstName
• Global: gsFirstName
• Argument: asFirstName
• Instance Public: FirstName - if it is a public instance, it means other classes will be accessing this and treat it like a property of the class.
• Instance Protected: _isFirstName - underscored prefix followed by Pascal Case
  
• Instance Private: __isFirstName - double underscored prefix followed by Pascal Case. Only Kodigo core maintenance developers will access this.

function string GetName()

• Public: GetName() - Pascal Case. Although it will appear as lowercase, coding should be done this way.
• Protected: _getName() - underscored prefix followed by Camel Case
• Private __getName() - double underscored prefix followed by Camel Case

constants, example color

• Object Name: C#Color - "C" plus "#" (C-sharp?) + Pascal Case name.
• Public constants: constant long AliceBlue = 16775408 -  Pascal Case
• Usage:

llColor = C#Color.AliceBlue

return C#Return.Success 

I like it!

Could you explain why just referring to C#Color.AliceBlue works without having to manually create an instance of C#Color?

I'm not exactly sure how PB constants works, but they seem to behave like a readonly static. Your guess is as good as mine on why they work But I have been using the technique since PB 7, I can't recall from who or where I found out about it.

It must grab the value at compile time just like an instance variable constant.

Have you found any use for INDIRECT variables?

I remember reading about INDIRECT keyword here. But I have never tried it yet. This looks like a good approach for business objects. Now I am curious about INDIRECT for visual objects. I wonder if setting the property via properties pane at design time will fire the get/setters?

How are you handling setting colors from datawindow object expressions? The only way to access anything outside the datawindow itself is by calling a global function.

I keep the colors as data within a datawindow. That allows me to look at the colors within the dw painter so I can choose the one I want by looking at it. I create a global function object that makes a call to a function in my global 'app object'. In that function I use the datastore Find function.

I avoid doing global function calls from datawindows, any operation that requires a redraw (e.g. scrolling, sizing, etc.) fires evaluation of computes. The more rows with global function calls, the slower it gets. For colors, I just do a modify whenever the theme changes.

I once created a global log function and called it from a dw compute, added 10 rows and ran the window. I then checked the log to see how many hits it made. It was quite a lot. Maybe I'm too picky, but has this behavior changed? Last time I tried this was in PB7

According to the PB help, expressions are processed every 60 seconds unless you set the Timer Interval to a different value. I didn't realize that scrolling did it as well.

Sometimes you need to set the color based on an expression. In that case the most efficient way would be to add a computed column to the SQL and reference that in the expression. Something like this:

   SELECT id, fname, lname,
         8894686 as BurlyWood
    FROM customer
   WHERE state = 'MA'

It is still a good idea to maintain a datawindow with all the colors. It gives you something to look at when trying to decide the color to use.