PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197

PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197
Naming convention for form wide variables.-VBForums
Results 1 to 15 of 15

Thread: Naming convention for form wide variables.

  1. #1

    Thread Starter
    Lively Member
    Join Date
    Mar 2015
    Posts
    75

    Naming convention for form wide variables.

    Is there a standard way to name form wide variables so that you can recognize them as being "form wide"? I'm assuming the proper term for "form wide variables" is actually a private class property, right?

    I'm using "this.property" to help me recognize that it's a form variable but the problem is that you don't have to use "this".

    As in the following:

    public partial class Form1 : Form
    {

    private string file;


    private void foo()
    {
    this.file = "hello world";
    }

    }

    I used to name everything in hungarian notation and then form vars I would name fstrFile or fstrTemp. Does anyone know the common naming convention for this situation?

    Thanks!

  2. #2
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    102,744

    Re: Naming convention for form wide variables.

    The proper name is a "field" or a "member variable". A property is different to a field. If you want to use a convention to distinguish member variables from local variables then I would suggest prefixing an underscore to the name. This is often done anyway to clearly distinguish a property from its backing field, e.g.
    csharp Code:
    1. private string _text;
    2.  
    3. public string Text
    4. {
    5.     get { return _text; }
    6.     set { _text = value; }
    7. }
    We generally use auto-properties these days, so you don't usually have to explicitly declare a backing field. They are implicitly declared though, and I believe that underscores are used on those implicit field names. If you declare an auto-property, you should be able to see the backing field in the Intellisense listings.

    Note that this example also demonstrates the difference between a field and a property.

  3. #3
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    102,744

    Re: Naming convention for form wide variables.

    The convention of the underscore goes back quite a way, to when the common convention was actually to use "m_" as the prefix, where the "m" was for "member". A member is any field, property, method, event or nested type declared within a type; basically anything that you can use after a dot when using the type or a reference to an instance of that type.

    Note that using an underscore to distinguish a backing field from a property is not strictly required in C#, because the language is case-sensitive and a private field should begin with a lower-case letter and a public property with an upper-case letter. It is considered bad practice to rely on case alone to distinguish identifiers though, so an underscore is used. In VB, you must use an underscore because the language is not case-sensitive.

  4. #4

    Thread Starter
    Lively Member
    Join Date
    Mar 2015
    Posts
    75

    Re: Naming convention for form wide variables.

    Quote Originally Posted by jmcilhinney View Post
    The proper name is a "field" or a "member variable". A property is different to a field. If you want to use a convention to distinguish member variables from local variables then I would suggest prefixing an underscore to the name. This is often done anyway to clearly distinguish a property from its backing field, e.g.
    csharp Code:
    1. private string _text;
    2.  
    3. public string Text
    4. {
    5.     get { return _text; }
    6.     set { _text = value; }
    7. }
    We generally use auto-properties these days, so you don't usually have to explicitly declare a backing field. They are implicitly declared though, and I believe that underscores are used on those implicit field names. If you declare an auto-property, you should be able to see the backing field in the Intellisense listings.

    Note that this example also demonstrates the difference between a field and a property.
    Thanks!

  5. #5
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,985

    Re: Naming convention for form wide variables.

    While I agree that what John said is the most common, I personally dislike the underscore for any purpose. The simple problem with it is that it's a finger-breaker to type for a good touch typist (as I kind of am). I prefer to use mName, which is the m_Name minus the underscore, but I am keeping the m wart convention. This barely matters, of course. You noted yourself that this is useful, which also implies that it is not essential, so you likely wouldn't be too surprised to hear that conventions on this subject have come and gone over the years. For a time, MS recommended what was called "Hungarian Notation", though it was not REALLY Hungarian Notation, because it deviated from the true purpose. Still, what they were doing was warting each variable with one to three characters to indicate the type. This convention launched a thousand papers, mostly papers pointing out that not only was the convention MS used not internally consistent, but that it couldn't be. You still see it around a bit in hwnd and lp prefixed names.

    There was also a time when the double underscore had a particular significance within VS, though possibly only C++. I don't remember the significance, but you could make your life miserable with this, deliberately or by accident. After all, the difference between a single underscore and a double underscore is a bit hard to see for most people. The double underscore meant that the member had some kind of special meaning, so it wasn't just a naming convention, as the compiler would try to interpret the double underscore in some particular way. That was a long time back, though, and I don't remember it very clearly.
    My usual boring signature: Nothing

  6. #6
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    102,744

    Re: Naming convention for form wide variables.

    Quote Originally Posted by Shaggy Hiker View Post
    That was a long time back, though, and I don't remember it very clearly.
    I can see the picture fading and chimes tinkling as a flashback is played of you with an afro and a really wide tie. Blurgh!

  7. #7
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,985

    Re: Naming convention for form wide variables.

    HA! Yeah, it would be a good place for a flashback, but I think wide ties and afro (which I could never do, as my hair is totally straight) would be to the 70s, not the 90s. Think more "grunge rock".
    My usual boring signature: Nothing

  8. #8
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    102,744

    Re: Naming convention for form wide variables.

    I guess I'm crediting you with more years than are warranted.

  9. #9

    Thread Starter
    Lively Member
    Join Date
    Mar 2015
    Posts
    75

    Re: Naming convention for form wide variables.

    Quote Originally Posted by Shaggy Hiker View Post
    While I agree that what John said is the most common, I personally dislike the underscore for any purpose. The simple problem with it is that it's a finger-breaker to type for a good touch typist (as I kind of am). I prefer to use mName, which is the m_Name minus the underscore, but I am keeping the m wart convention. This barely matters, of course. You noted yourself that this is useful, which also implies that it is not essential, so you likely wouldn't be too surprised to hear that conventions on this subject have come and gone over the years. For a time, MS recommended what was called "Hungarian Notation", though it was not REALLY Hungarian Notation, because it deviated from the true purpose. Still, what they were doing was warting each variable with one to three characters to indicate the type. This convention launched a thousand papers, mostly papers pointing out that not only was the convention MS used not internally consistent, but that it couldn't be. You still see it around a bit in hwnd and lp prefixed names.

    There was also a time when the double underscore had a particular significance within VS, though possibly only C++. I don't remember the significance, but you could make your life miserable with this, deliberately or by accident. After all, the difference between a single underscore and a double underscore is a bit hard to see for most people. The double underscore meant that the member had some kind of special meaning, so it wasn't just a naming convention, as the compiler would try to interpret the double underscore in some particular way. That was a long time back, though, and I don't remember it very clearly.

    I've used hungarian notation for the last 20 years but my new job wants me to switch. I still think hungarian is easier. If I had a textbox that held a folder I would call it "txtFolder" and I would instantly know it was a textbox that held a folder. Now I have to call it "folder" and I don't know what it is, or where it's declared without either hovering over it or searching around for it. If I had a form variable that held a folder I'd call it fstrFolder and I instantly know it was a form variable of type string that held a folder. gstrFolder is a global that held a folder.

  10. #10
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    102,744

    Re: Naming convention for form wide variables.

    Quote Originally Posted by madison320 View Post
    I've used hungarian notation for the last 20 years but my new job wants me to switch. I still think hungarian is easier. If I had a textbox that held a folder I would call it "txtFolder" and I would instantly know it was a textbox that held a folder. Now I have to call it "folder" and I don't know what it is, or where it's declared without either hovering over it or searching around for it. If I had a form variable that held a folder I'd call it fstrFolder and I instantly know it was a form variable of type string that held a folder. gstrFolder is a global that held a folder.
    I hate Hungarian Notation but naming a TextBox 'folder' is bad in my opinion. Things should be named what they are. The only thing that I would name 'folder' would be a DirectoryInfo object, because it represents an actual folder. A String that stored the path of a folder would be named 'folderPath'. A TextBox that stored that path of a folder would be 'folderPathTextBox'. It's kinda obvious that that is a TextBox that stores a folder path.

    Some people will say that using 'folderPathTextBox' is essentially the same as 'txtFolderPath' but longer, but that's not the case, as my 'folderPath' example demonstrates. A variable named 'folderPathTextBox' represents a TextBox, not a folder path, so the name reflects that. Likewise, a variable that actually does represent a folder path reflects that. Variable names should reflect what they actually refer to or store and the role they play in the app. TextBox that contains a folder path doesn't play the role of a folder path; it plays the role of a TextBox, with the fact that it contains a folder path being a secondary role.

    One thing that I will say, and this relates to the use of Hungarian Notation somewhat, is that people still seem unnecessarily obsessed with using as short names as possible for variables, methods, etc. They should get over that. In an IDE like VS, you almost never have to type out an identifier in full except when you declare it, so making your identifiers clear should be considered far more important than making them short. The stupid abbreviations I see people use some times make me cringe. Just type the words! Not saying that this necessarily applies in this specific case but it's a general thing that peeves me.

    Also, while we're on the subject, the main issue I have with Hungarian Notation is that it just isn't effective these days because there are two many types. You end up with ambiguous or obscure prefixes or, like many people, you end up with "obj" prefixing 80% of your variables. It's just stupid to use "obj" for just about everything as it does nothing to clarify the situation. My other issue is that Hungarian Notation really serves no useful purpose because meaningful names coupled with Intellisense means that you never have to wonder what type something without using it.

  11. #11
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,985

    Re: Naming convention for form wide variables.

    That was one of the objections to Hungarian back when it was hotly debated (now it's mostly abandoned). There is one slight advantage to warting variable names, which is that they will tend to group together in Intellisense. If you do much with that, you realize that it's a VERY slight advantage simply because there are so many different things showing up in Intellisense that the grouping is not all that useful.
    My usual boring signature: Nothing

  12. #12
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,409

    Re: Naming convention for form wide variables.

    I hated that... because then it required me to remember the types of a variable that I needed.... Umm... let's see... that counter I needed... was it an Int, or a Long? Gah! I can't remember... It was much easier to remember that it was the LemonadeStandCounter rather than the lngLemonStndCntr ... because at the end of the day, I don't really care about what the type is, I just need to know the name of it. IDEs these days are smart enough to warn me when if I accidentally use an integer variable when I meant to use a string one, or vice versa. I don't need to use the variable name any more to keep things on the straight and narrow.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  13. #13
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,080

    Re: Naming convention for form wide variables.

    Quote Originally Posted by techgnome View Post
    I hated that... because then it required me to remember the types of a variable that I needed.... Umm... let's see... that counter I needed... was it an Int, or a Long? Gah! I can't remember... It was much easier to remember that it was the LemonadeStandCounter rather than the lngLemonStndCntr ... because at the end of the day, I don't really care about what the type is, I just need to know the name of it. IDEs these days are smart enough to warn me when if I accidentally use an integer variable when I meant to use a string one, or vice versa. I don't need to use the variable name any more to keep things on the straight and narrow.

    -tg
    Also don't forget the joy of a lazy update to the code, a variable with a name like iCount which was probably an Integer at one time but later on somebody realised Integer was only 16bits and changed the definition to be Long, nothing quite like the fun of a name that lied to you

  14. #14
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,409

    Re: Naming convention for form wide variables.

    Quote Originally Posted by PlausiblyDamp View Post
    Also don't forget the joy of a lazy update to the code, a variable with a name like iCount which was probably an Integer at one time but later on somebody realised Integer was only 16bits and changed the definition to be Long, nothing quite like the fun of a name that lied to you
    The worst were actually controls... I worked for a company where it wasn't enough to just prepend txt for a text box... no... that would be too easy... no first it had to have ui prepended to show that it was a UI element (it's a ^#% text box, of COURSE it's a UI element!) ... and then we used the Infragistics Controls, the next two characters were "ic" ... followed by what it is txt, lbl, cmd, grd, pnl, etc... followed by what it finally is... FirstName. ..... and since many of our forms had tabs with hundred of controls on them... navigating the intellisense was a nightmare at times. More often than not, it was eaiser to go to the designer, ffind the control, copy the name from the properties panel, and paste it into the code rather than try to navigate it in intellisense.


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  15. #15
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    33,985

    Re: Naming convention for form wide variables.

    I should have made up a FormUnit class. That would be good to prepend onto a variable.

    I have a program that is mostly generated. Generated names are long, yet still not all that useful. You pretty much know what it is long before you get to the end of the name. Once that gets a bit of custom warting tossed in, along with some underscores, it's kind of the worst of all worlds.

    People say bad things about Infragistics, but I should have swiped a few more t-shirts. They make excellent workout attire.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width