naming and scope

[cjard]

ImDaFreaK:

few coding tips for you:

[SIZE=2][COLOR=#0000ff]Private[/COLOR][/SIZE][SIZE=2] m_Cancel_Context_Menu [/SIZE][SIZE=2][COLOR=#0000ff]As[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Boolean[/COLOR][/SIZE][SIZE=2] = [/SIZE][SIZE=2][COLOR=#0000ff]True[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]
[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Private[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Property[/COLOR][/SIZE][SIZE=2] Cancel_Context_Menu() [/SIZE][SIZE=2][COLOR=#0000ff]As[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Boolean
[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]    Get
[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]         Return[/COLOR][/SIZE][SIZE=2] m_Cancel_Context_Menu
[/SIZE][SIZE=2][COLOR=#0000ff]    End[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Get
[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]    Set[/COLOR][/SIZE][SIZE=2]([/SIZE][SIZE=2][COLOR=#0000ff]ByVal[/COLOR][/SIZE][SIZE=2] value [/SIZE][SIZE=2][COLOR=#0000ff]As[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Boolean[/COLOR][/SIZE][SIZE=2])
          m_Cancel_Context_Menu = value
[/SIZE][SIZE=2][COLOR=#0000ff]    End[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Set
[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]End[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]Property
[/COLOR][/SIZE]

if you make a private variable, it can never be accessed outside this class. you dont need to make a property for it too. just use the variable name. properties are used mainly when we want to present an internal variable to other classes as a different type, name or to add some validation to getting/setting - its not really needed in this case and is an extra hoop for the cpu


all the code ive ever seen uses either underscores or initcaps to delimit words - i rarely see both. VB's excuse in the case of Control_EventThing is that the control is called Control, the event thing is called EventThing and you would normally say Control.EventThing if addressing it as a property - VB will convert the . to _ to maintain some familiarity and give a good unique name ofr an event on a control etc..
it's mainly a time/extra keypresses for you, and that as a developer that uses the styles interchangeably but never combined, i find it looks weird, and doesnt help me determine whether what i'm looking at is a variable, class, event, sub name etc..

you rarely need to say Me. to refer to a local variable - the designer does for safety as it doesnt look to see if youve called a variable with the same name, publicly globally accessible elsewhere in your code. i typically find it adds to the visual clutter and i remove it wherever its not specifically needed..

i didnt find your variable names very easy to understand. Cancel_Context_Menu sounds like an action - a method/sub that will cause a context menu to be canceled. Microsoft typically recommend that boolean variables have a name that implies a yes/no logical outcome and also that the tone of the variable name is positive.. this is why i chose ctxMenuClosingEvtMustCancel
Perhaps ctxMnuCloseEventMustBeCanceled would have been even better. i did call it dontCloseContextMenu to start with, then remembered my own advice of giving a positive tone.. i.e. i would be setting a true when i wanted something not to happen and a false when i wanted somethign to happen. hence i would maybe have had to write:
If Not dontCancel Then e.Cancel = true...
whereas arranging a boolean variable name with a positive tone allows us to write:
If somethingShouldHappen Then doThatSomething()
vs
If Not somethingShoudntHappen Then doThatSomething...


so, key points on code readability really are: reduce clutter, make variable names nicely self documenting and think carefully about the tone of variable names etc


at the end of the day, coding is very much personal opinion - i've seen quite a bit over the time that ive been coding and have usually nicked the neat looking ideas to develop my own personal style. i'm passing this on not so much as a "hey, do what i do" but as a hey "here's what most people would do, in my opinion", and of course, youre free to ignore it

 

[ImDaFrEaK]

Thanks for the tips, i'll try to stay compatable with the current standard by adjusting my coding a little. I don't know the full suggested standard yet b/c I am self taught. However; I use the lower case underscore "m_" to represent all private variables in my code. So for me if I see "m_" I know it's a private variable already. I could have written the property to say CancelContextMenu and that would be cleaner so I will probably take the underscores out but changing it's tense I won't. I want it to be Compared equally to the Cancel property within the context menu's closing event. So basically it reads "e.Cancel = CancelContextMenu". I always use "me" when I am withing the same class whether it's needed or not for two reasons. Intellisense (my main reason) and b/c I float between many classes and libraries that I have written and this also helps me visualize my project. But this is also cluttersome I know. Further, I almost always use properties as opposed to plain variables b/c you never know when you want to add extra coding to the process. For this simple demo I could have used a variable but according to "Francesco Baleno" a great author which basically taught me all I know about VB.NET, you should almost always use properties just as piece of mind for later. Makes things easier to fix or modify. I know it's an extra hoop but it keeps you safe in the long run. I may later want to add an event to the CancelContextMenu Property (Event ContextMenuCanceled, but prob not; lol). Plus, I do see this property outside the class so for me I like it better than a public variable. Of course, for many purposes I do use private variables alone. I have developed a way of programming for myself that allows me to flip through my code really quick. This may be aggravating if I was working with a team of programmers so your right I need to clean it up some. Basically I will take the underscores out of the Property b/c they are ugly, but I will keep the rest intact. I really do appreciate the help and heads up though. I want to keep my code as appropriate as possible for other programmers but we all prob have a few unique characteristics of our own for programming. And I really do appreciate the help, please don't think I've ignored it. I want a more professional look to my code and you've been a great help.

 

[cjard]

I want it to be Compared equally to the Cancel property within the context menu's closing event.

understanding a little more where you were going, i might have called it something like "ContextMenuStaysOpen" or "PreventContextMenuClose" - it sounds less like an action that will be invoked and its easier to understand what will happen if the property is set to true - if i knew that CancelContextMenu was a property then I would assume that if set to true, that the menu would be cancelled without ever being shown.. Youre not cancelling the menu, per se, youre cancelling the menu's close event..

Its always handy to know others perspective, i find, because after we devise a solution we become so used to the knowledge we have of our own solution that we forget that others might not see what we intended. Often i'll ask a fellow programmer who hasnt been looking at my code "If i had a variable to do suchandsuch, what would you call it?" or "If my method was called blahblah, what would you assume it did?"

and sometimes, it takes aaaages to agree like today.. what to call a database table that held opening and closing values of points balances for a loyaly scheme. someone wanted it called cycle_point_balance - i noted that the word point had too many menaings within the system and within programming to be instantly associated with a loyaly scheme. it was called cas_loyalty_balance in the end (cas is a naming convention and must stay)

Plus, I do see this property outside the class so for me I like it better than a public variable.

Of course.. public variables are discouraged because another class can potentially bang in some very bad data that will upset your program.

In this case i also wanted to note that you might see your Property outside the class (in intellisense), but it is inaccessible because you've declared the Property private. I do wholly agree with you that variables should never be made public, always kept private or protected, and properties made public to allow them to be set.. ibut for this one example, i couldnt understand the use of making a Property that does no validation/extras and is Private.. so i just wanted to point that out.. a private property is moot and can be added later. You can additionally use VB's built in refactoring in the following way:

suppose you had a private variable:
_PersonAge

and its used everywhere, and you want to turn it into a property.. first, rename it to whatever you want the property to be:

PersonAgeProperty

but dont leave the word. i.e. dont cursor out of it. Note that a little underscore appears at the end of the word. pointing to this for a while pops a menu saying "Rename _personAge to PersonAgeProperty" - do it

then rename it back, but dont choose the option to rename all occurrences through the code..
a rash of errors appear... now write your property:

Public Property PersonAgeProperty as Integer...

and all the errors go again.. your code is now using the property that wasnt before needed but now is

 

[ImDaFrEaK]

I see what you mean and you area correct. I have the property Private which does not allow me to use it with other classes. I didn't even realize that until you said it and now after looking at my project I am not using it with other forms (Classes). I originally was thinking that I was but I didn't even notice I wrote the property private, so in fact it will not be seen outside of the current form or class. I lied but not intentionally. So here's the cleaner scoop.... I have the whole context menu, property and all in it's own region to keep up with it. Basically just take the property out and use the private boolean named "_CancelingContextMenu". Thanks