 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / November 2006Member Variables Naming Convention
I was just wondering what naming convention most of you use for class variables. Underscore, "m_" prefix, camel case, capitalized, etc? Has one style emerged as the most popular? Thanks for any comments.  SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com >I was just wondering what naming convention most of you use for class >variables. > > Underscore, "m_" prefix, camel case, capitalized, etc? > > Has one style emerged as the most popular? I think there are 2 main schools of thought on this. This first is to prefix it with _. The second is to just make it camel case. I prefer the first although the second appears to be the MS standard. Michael Hi, Just to be clear, I think Michael means lower camel case. Upper camel case (Pascal case to some) is not acceptable for variable names. Personally, I think "m_" and "_" are legacy notations and I find them to be annoying, without any value. I just use lower camel case everywhere. SignatureDave Sexton >>I was just wondering what naming convention most of you use for class >>variables. [quoted text clipped - 8 lines] > > Michael Yes, I think camel case always refers to the first letter not being capitalized. It appears Microsoft now recommends not using an m_ or _ prefix. The only thing I don't like about that is you run into problems with arguments having the same name as member variables (especially in constructors). I personally don't like using this.var everywhere just to avoid this conflict. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > Hi, > [quoted text clipped - 16 lines] >> >> Michael I think the "m_" form for naming fields comes from VB which is not case sensitive so naming the field something like "lastName" and the associated property "LastName" just doesn't work. That said, I agree that it doesn't really fit or add anything in C#. And underscores are beginning to be recognized as part of a whole new source of repetitive motion injuries in the workplace associated with little-finger typing so prefixing with underscores is not a good idea either - nor does it add any readability to the code. I like to name all my fields in camel case and my properties in Pascal case. Dale SignatureDale Preston MCAD C# MCSE, MCDBA > Hi, > [quoted text clipped - 16 lines] > > > > Michael Dale, >I think the "m_" form for naming fields comes from VB which is not case > sensitive so naming the field something like "lastName" and the associated > property "LastName" just doesn't work. The "m_" prefix was standardized in C++/MFC. Microsoft consistently used that throughout MFC and I've certainly used the same standard in VB code. (I used to write a regular column in Visual Basic Programmer's Journal.) And it should be noted that C++ is definitely case-sensitive. > And underscores are beginning to be recognized as part of a whole new > source [quoted text clipped - 3 lines] > it > add any readability to the code. As has been pointed out, you kind of need a "_" prefix or use this. before each member variable. I would argue that five characters is harder on the carpel tunnel than one is. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com Jonathan, I just find that underscore hard to read in some situation. While it is in my idea not on the most nice place on the keyboard for those who are using 10 fingers to type. Very good to create RSI. Cor > Dale, > [quoted text clipped - 19 lines] > each member variable. I would argue that five characters is harder on the > carpel tunnel than one is. "Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message > Personally, I think "m_" and "_" are legacy notations and I find them to > be annoying, without any value. I just use lower camel case everywhere. I can't argue with you on _ being annoying, that is a matter of taste but I think the statement that it is without any value isn't true. The value is of course that it shows what is a member variable and it allows properties to have the same name as the variable. It also avoids the problem of using only case to distinguish 2 different items, something which I prefer to avoid. It also makes it easy to find all member vars in intellisense (something that prefixing with m never did). I can understand disputing the usefulness of this "value" but I don't think you can argue that no value exists. Michael Hi Michael, > I can't argue with you on _ being annoying, that is a matter of taste but I think the statement > that it is without any value isn't true. The value is of course that it shows what is a member [quoted text clipped - 3 lines] > did). I can understand disputing the usefulness of this "value" but I don't think you can argue > that no value exists. I wasn't questioning its use, I was questioning its value. And I can argue that no value exists - I did in another post :) SignatureDave Sexton Hi Jonathan, here is a link to the Microsoft guidelines for naming conventions: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconnamingguidelines.asp I follow these. Mark. Signaturehttp://www.markdawson.org > I was just wondering what naming convention most of you use for class > variables. [quoted text clipped - 4 lines] > > Thanks for any comments. I conform *almost* completely to the Microsoft naming conventions, with one exception: I use an underscore with Pascal case for class member Fields and Methods that are private or internal, and Pascal case for class member Fields and Method that are public or protected. This seems to make it easier to identify the scope of the Field from the Field name, and lessens the chance that class member Fields which are private or protected will run into ambiguity issues with parameters. Example: private float _Cost; public float Cost { get { return _Cost; } set { _Cost = value; } } public void Add (float cost) { return cost + _Cost; } In the above example, the example names are representative of typically logical names for what they might represent. Occasionally, the situation occurs when similarly logical names may appear as both a Field and a parameter in a method. This way, it is easier to identify the difference inside the Method block. While I tend to stick closely to Microsoft guidelines for the purpose of team development ease, I do take a liberty or 2 (and stick to it consistently) when I think I may have a better idea (which is very seldom). SignatureHTH, Kevin Spencer Microsoft MVP Ministry of Software Development http://unclechutney.blogspot.com Any experience you can walk away from is a good one. > Hi Jonathan, > here is a link to the Microsoft guidelines for naming conventions: [quoted text clipped - 12 lines] >> >> Thanks for any comments. Hi Kevin, You believe that the little value "_" notion provides, if any, outweighs the value of using standardized naming conventions? Of course, if you work in an environment where "_" is the accepted standard then it might not be such a problem, but if you're program is ever touched by anyone else, it might be confusing to them. Therefore, I don't believe that anyone should take any liberties when there is already widely-accepted standardization in place. SignatureDave Sexton >I conform *almost* completely to the Microsoft naming conventions, with one exception: I use an >underscore with Pascal case for class member Fields and Methods that are private or internal, and [quoted text clipped - 36 lines] >>> >>> Thanks for any comments. Hello Dave, What's the most interesting that the widely-accepted standardization is tuned a little bit to suite company best practice. I've met the number of cases where "_" was used widely in the big companies and it gives more pros than cons DS> Hi Kevin, DS> DS> You believe that the little value "_" notion provides, if any, DS> outweighs the value of using standardized naming conventions? DS> DS> Of course, if you work in an environment where "_" is the accepted DS> standard then it might not be such a problem, but if you're program DS> is ever touched by anyone else, it might be confusing to them. DS> Therefore, I don't believe that anyone should take any liberties DS> when there is already widely-accepted standardization in place. DS> DS> "Kevin Spencer" <spam@uce.gov> wrote in message DS> news:OmjaLOxCHHA.468@TK2MSFTNGP06.phx.gbl... DS> >> I conform *almost* completely to the Microsoft naming conventions, >> with one exception: I use an underscore with Pascal case for class [quoted text clipped - 57 lines] >>>> SoftCircuits Programming >>>> http://www.softcircuits.com --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Hi Michael, > What's the most interesting that the widely-accepted standardization is tuned a little bit to > suite company best practice. I think tuning usually occurs because people are used to a certain way of doing things and don't like to adopt a new standard. The "_" notation is just half-way between "m_" and the standardized, non-prefix notation (is "_" considered hungarian notation?), so it seems that some people gave in a little, tuning for comfort but not standards. I, myself, found that adopting some of the standards for managed programming was annoying at first, but it was worth it. My code is easier to read now and I have to worry less about other programmers messing up my code when it flows from organization to organization, given that they too abide by the standards. In the past, it's always been annoying when my library code was modified and formatting of the { }, tabs, notation, naming conventions and document structure are completely messed up by someone doing what they felt was best. Mixing personal preference with standards results in a big mess. Of course, in an organization that has internally standardized the "_" notation it's less of a problem. But new hires must learn the techniques and deployed code may be seen by different organizations in the future, so its use is not completely isolated. > I've met the number of cases where "_" was used widely in the big companies and it gives more pros > than cons I acknowledge Kevin's concern with the ambiguity between parameters and fields using the standardized naming convention, however, I think that qualifying fields looks much better anyway: public ClassConstructor(int firstNumber, int secondNumber) { _FirstNumber = firstNumber; this.secondNumber = secondNumber; } What does "_" provide over the standard, excluding the above? SignatureDave Sexton Hello Dave, >> What's the most interesting that the widely-accepted standardization >> is tuned a little bit to suite company best practice. DS> I think tuning usually occurs because people are used to a certain DS> way of doing things and don't like to adopt a new standard. The "_" DS> notation is just half-way between "m_" and the standardized, DS> non-prefix notation (is "_" considered hungarian notation?), so it DS> seems that some people gave in a little, tuning for comfort but not DS> standards. I think tuning occurs to adobt the best code readability DS> I acknowledge Kevin's concern with the ambiguity between parameters DS> and fields using the standardized naming convention, however, I DS> think that qualifying fields looks much better anyway: DS> DS> public ClassConstructor(int firstNumber, int secondNumber) DS> { DS> _FirstNumber = firstNumber; DS> this.secondNumber = secondNumber; DS> } DS> What does "_" provide over the standard, excluding the above? that means that "_FirstNumber" is the private/protected property. It doesn't matter what do u use to differentiate between private/protected and public, I just take the position that we really need the way to show the difference. Either _ or m_ or whatever possible. MS codingstyle suggests nothing for this --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Hi Michael, > DS> I think tuning usually occurs because people are used to a certain > DS> way of doing things and don't like to adopt a new standard. The "_" [quoted text clipped - 4 lines] > > I think tuning occurs to adobt the best code readability Not always. A lot of programmers are just stubborn. They'll tune away from standardization to legacy practices so they feel more comfortable, and then try to validate their decision. > DS> I acknowledge Kevin's concern with the ambiguity between parameters > DS> and fields using the standardized naming convention, however, I [quoted text clipped - 12 lines] > possible. > MS codingstyle suggests nothing for this But other than the example above, does an "_" prefix provide any value? SignatureDave Sexton Hello Dave, >> DS> DS> public ClassConstructor(int firstNumber, int secondNumber) >> DS> { [quoted text clipped - 10 lines] >> possible. >> MS codingstyle suggests nothing for this DS> But other than the example above, does an "_" prefix provide any DS> value? Maybe not quite undestand u - it provides anything, just mark that we deal with private/property item. Any other ideas how to underpin this? --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsch Hi Michael, > Maybe not quite undestand u - it provides anything, just mark that we deal with private/property > item. > > Any other ideas how to underpin this? Well, "_" doesn't seem to provide any value that doesn't exist using the standard notation. If I see something like, "firstNumber" in a method body it's usually obvious to me whether its a field or a parameter just by quickly scanning the method, considering that the method was properly designed to be succinct, or even just by context and its chosen name. In larger methods a simple mouse-over does the trick. Intellisense tells us when a variable is a "local variable" (although I rarely even need that information from intellisense, if ever). Otherwise, when "(local variable)" isn't displayed, it's a field. And, if an object is confusing to the point where something such as "firstNumber" isn't obviously a field or a local variable, then the chosen name might not be descriptive enough. So the best argument for "_" so far is that it alleviates parameter ambiguity without requiring "this.", which I actually prefer over "_" anyway. Furthermore, "this." has been standardized while "_" is not recommended by Microsoft. SignatureDave Sexton > Hello Dave, > [quoted text clipped - 26 lines] > "At times one remains faithful to a cause only because its opponents do not cease to be insipid." > (c) Friedrich Nietzsche Hello Dave, DS> Hi Michael, DS> >> Maybe not quite undestand u - it provides anything, just mark that we >> deal with private/property item. >> >> Any other ideas how to underpin this? DS> Well, "_" doesn't seem to provide any value that doesn't exist using DS> the standard notation. If I see something like, "firstNumber" in a DS> method body it's usually obvious to me whether its a field or a DS> parameter just by quickly scanning the method, considering that the DS> method was properly designed to be succinct, or even just by context DS> and its chosen name. Right DS> In larger methods a simple mouse-over does the DS> trick. Intellisense tells us when a variable is a "local variable" DS> (although I rarely even need that information from intellisense, if DS> ever). Otherwise, when "(local variable)" isn't displayed, it's a DS> field. Ok, now u was asked to review the code. You got 2 version of source files from CVS, open them in diff editor and starting review changes. There is no intellisence. An catch that difference u described above is really hard DS> And, if an object is confusing to the point where something DS> such as "firstNumber" isn't obviously a field or a local variable, DS> then the chosen name might not be descriptive enough. What do u suggest for naming convention to distinguish locals/fields? We are not in the perfect world where is the each method is on the screen's lenght. it's a little bit simple if we use encapsulation, where no direct access to fieds, only properties - camel case for private and pascal for public fields. but we are again stumble over ambiguity between the local variable and the private property DS> So the best argument for "_" so far is that it alleviates parameter DS> ambiguity without requiring "this.", which I actually prefer over DS> "_" anyway. Furthermore, "this." has been standardized while "_" is DS> not recommended by Microsoft. I don't like "_" too, but it seems to be the simplest and neat solution DS> DS> "Michael Nemtsev" <nemtsev@msn.com> wrote in message DS> news:1799a79b3bf9938c8d98c9b6ffce5@msnews.microsoft.com... DS> >> Hello Dave, >> [quoted text clipped - 24 lines] >> "At times one remains faithful to a cause only because its opponents >> do not cease to be insipid." (c) Friedrich Nietzsche --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsch Hi Michael, <snip> > DS> In larger methods a simple mouse-over does the > DS> trick. Intellisense tells us when a variable is a "local variable" [quoted text clipped - 4 lines] > diff editor and starting review changes. There is no intellisence. An catch that difference u > described above is really hard Ok, you're definitely correct that intellisense and tooltips aren't always available :) But if the method's purpose is known and variable names are meaningful, I don't see how that could be a problem. It's never been a real problem for me, at least not enough to warrant the use of an "_" before all fields in my entire system and to go against a standard. > DS> And, if an object is confusing to the point where something > DS> such as "firstNumber" isn't obviously a field or a local variable, > DS> then the chosen name might not be descriptive enough. > > What do u suggest for naming convention to distinguish locals/fields? > We are not in the perfect world where is the each method is on the screen's lenght. In VS, context should be enough, or use descriptive names, or it shouldn't matter: class Color { byte r, g, b; public void ConvolutedRandomization(int factor) { // It doesn't matter whether "rnd" is a field or local variable, later in code. // The instance will be used regardless of its origin. Random rnd = new Random(); // It doesn't matter, later in code, whether randomR is a field or a local. // The only thing we'll care about when its required is its value. byte randomR = (byte) rnd.Next(0, Math.Min(256, factor)) byte randomG = (byte) rnd.Next(0, Math.Min(256, factor)) byte randomB = (byte) rnd.Next(0, Math.Min(256, factor)) // we know we're assigning to fields because that's the purpose // of this method. r = Math.Min(256, r * randomR); g = Math.Min(256, g * randomG); b = Math.Min(256, b * randomB); } } class Color { byte _r, _g, _b; public void ConvolutedRandomization(int factor) { Random rnd = new Random(); byte randomR = (byte) rnd.Next(0, Math.Min(256, factor)) byte randomG = (byte) rnd.Next(0, Math.Min(256, factor)) byte randomB = (byte) rnd.Next(0, Math.Min(256, factor)) _r = Math.Min(256, _r * randomR); _g = Math.Min(256, _g * randomG); _b = Math.Min(256, _b * randomB); } } You might feel that it's much clearer in the latter version whether "_r" is a local or a field, but does that provide any value? After all, if you understand the method then it should be obvious, and anyway there really is no ambiguity here. Why even assume that "r", in the first example, is a local variable? > it's a little bit simple if we use encapsulation, where no direct access to fieds, only > properties - camel case for private and pascal for public fields. but we are again stumble over > ambiguity between the local variable and the private property Outside of VS, as you pointed out, it may be a problem. Definitely not inside, however. <snip> SignatureDave Sexton Hello Dave, >> Ok, now u was asked to review the code. You got 2 version of source >> files from CVS, open them in >> diff editor and starting review changes. There is no intellisence. An >> catch that difference u >> described above is really hard DS> Ok, you're definitely correct that intellisense and tooltips aren't DS> always available :) DS> But if the method's purpose is known and variable names are DS> meaningful, I don't see how that could be a problem. It's never DS> been a real problem for me, at least not enough to warrant the use DS> of an "_" before all fields in my entire system and to go against a DS> standard. Completly agree, but.... DS> Outside of VS, as you pointed out, it may be a problem. Definitely DS> not inside, however. ... but we returned to my OP :) > What's the most interesting that the widely-accepted standardization is tuned a little bit to suite company best practice. So, if someone practice is the intensive codereview (for example PSP metholody in team) thus this evil "_" only helps u. In my practice, for some workplaces where I worked, we had spent at least 2-3 hours/per day for code-reviewing, and we found out that "_" really helps us Dave, we've got to the same conclusion with good understanding each other. Suggest to close this discussion :) --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Hi Michael, >>> Ok, now u was asked to review the code. You got 2 version of source >>> files from CVS, open them in [quoted text clipped - 16 lines] > > ... but we returned to my OP :) I spend most of my time in VS. The cons outweigh the pros, IMO. SignatureDave Sexton > Hello Dave, >> What's the most interesting that the widely-accepted standardization is > tuned a little bit to suite company best practice. [quoted text clipped - 13 lines] > "At times one remains faithful to a cause only because its opponents do not cease to be insipid." > (c) Friedrich Nietzsche Hi Michael, I'm sorry, but I didn't see the end of your post (I'm switching back and forth from newsgroups to work right now when I build :) >>> What's the most interesting that the widely-accepted standardization is >> tuned a little bit to suite company best practice. [quoted text clipped - 6 lines] >> Dave, we've got to the same conclusion with good understanding each other. Suggest to close this >> discussion :) That's fine with me. Our experiences obviously differ :) Thanks for the discussion. SignatureDave Sexton > Hello Dave, > [quoted text clipped - 36 lines] > "At times one remains faithful to a cause only because its opponents do not cease to be insipid." > (c) Friedrich Nietzsche "Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message news:%23QnoN2% > But if the method's purpose is known Notice 1 very important word in you sentence, "IF". If the methods purpose is know then maybe not but when these conventions are most important is when you don't know the code. > You might feel that it's much clearer in the latter version whether "_r" > is a local or a field, but does that provide any value? After all, if you > understand the method then it should be obvious, and anyway there really > is no ambiguity here. Why even assume that "r", in the first example, is > a local variable? What else could it be? It can't be a function because they're all capitals. It can't be a module level if they've got an underscore. The only other possibility is a parameter but they're very similar to local vars anyway and very easy to determine what they are. Michael Hi Michael, >> But if the method's purpose is known > > Notice 1 very important word in you sentence, "IF". If the methods purpose is know then maybe not > but when these conventions are most important is when you don't know the code. That's a good point, but before I review a class I automatically browse for a list of private fields first to keep as a reference. That's why I always code all private fields together. When I browse upon a class that I haven't seen in a while I can just pop open a Private / Protected region and there is no confusion at all. I do see the benefit of "_" in cases like that; however, I don't think it's necessary if you organize the structure of your document appropriately. >> You might feel that it's much clearer in the latter version whether "_r" is a local or a field, >> but does that provide any value? After all, if you understand the method then it should be [quoted text clipped - 4 lines] > level if they've got an underscore. The only other possibility is a parameter but they're very > similar to local vars anyway and very easy to determine what they are. I mean, in the context of a method that assigns randomized values to r, g, and b in a Color class, the assignments are obviously to fields. I find it to be rare that confusion exists whether a variable is a field or a local when descriptive naming conventions are used and in a meaningful context, even without the support of intellisense and tooltips. Designing methods to be succinct helps too. SignatureDave Sexton > But other than the example above, does an "_" prefix provide any value? I hated the idea when a coworker introduced it, but now I'm all for it. We're gradually converting our code over to using the "_" prefix for member variables. Here's why. Keep in mind that most of us are no longer writing code in text editors and peering at printouts. Most of us are using Visual Studio and Intellisense. I think that Hungarian Notation was a good idea for assembly language, but it should have a stake driven through its heart these days because if I want to know what type something is, I mouse over it and VS tells me. So, there are now TWO considerations: the written code itself, and the code within the Visual Studio environment. With this in mind, we had an annoying problem when we followed what appear to be MS's official guildelines. Given code like this: public class Blah { private int foo; public int Foo { get { return this.foo; } set { this.foo = value; } } } and remembering that Intellisense is case-INsensitive, one can immediately see why Intellisense has the annoying habit of choosing one of this.foo or this.Foo "at random" when I type "this.f" from inside the Blah class scope. This led to not a few bugs in our code, as touch typists like me who often type without watching the screen would end up with references to the property instead of to the member variable. I lost count of how many infinite loops I introduced that way. The "_" introduced two improvements. First, it's unambiguous when typed in VS: "this._f" always means you want a member variable starting with f, whereas "this.f" or "this.F" always indicates something public, probably a property or method. Second, all member variables appear at the top of the list in the debugger, so you don't have to go hunting for them. Does it make the code or less readable on printout? Doesn't much matter to me. It does, however, make VS easier to use, and since that's where I spend most of my coding and debugging time, that matters a lot. Hi Bruce, >> But other than the example above, does an "_" prefix provide any value? > [quoted text clipped - 28 lines] > with references to the property instead of to the member variable. I > lost count of how many infinite loops I introduced that way. But I've already stated that I never use "this." unless I must resolve an ambiguity issue for the compiler. It's pointless there, and you've also proven that it may be dangerous as well. > The "_" introduced two improvements. First, it's unambiguous when typed > in VS: "this._f" always means you want a member variable starting with > f, whereas "this.f" or "this.F" always indicates something public, > probably a property or method. That's a good point if you're using "this." everywhere, which I know a lot of programmers do. I don't because it's more typing and provides no real value, IMO. > Second, all member variables appear at the top of the list in the > debugger, so you don't have to go hunting for them. Good, descriptive names and code layout alleviate the need to search for members based on their member type in a large intellisense list. Normally, just typing "f Ctrl+Space" is enough to find "foo", otherwise it probably shouldn't be named "foo" in the first place. And even if it's unavoidable that "foo" will be difficult to find using intellisense due to an overwhelming number of fields in a class, or other complexities, you could also code like I do and group all private fields together. I've posted my layout snippets after my sig. > Does it make the code or less readable on printout? Doesn't much matter > to me. It does, however, make VS easier to use, and since that's where > I spend most of my coding and debugging time, that matters a lot. I agree that VS is more important than outside of VS since that's where the large majority of my time is spent as well. SignatureDave Sexton All of my structs and classes (components and non-components) use the following layout, so it's very easy to locate the names of fields. As a matter of fact, I often have the Private / Protected region expanded when I'm coding methods so I don't have to browse through a long list of fields in a complex object. I'm sure that helps me locate unknown field names much faster than browsing a list of members that all begin with "_". (Watch for tabbing issues if anyone tries to use the snippets since I pasted them here and the formatting was probably lost) { layout.snippet } <?xml version="1.0" encoding="utf-8" ?> <CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> <CodeSnippet Format="1.0.0"> <Header> <Title>layout</Title> <Shortcut>layout</Shortcut> <Description>Code snippet for region layout of code files</Description> <Author>Dave Sexton</Author> <SnippetTypes> <SnippetType>Expansion</SnippetType> </SnippetTypes> </Header> <Snippet> <Declarations> <Literal Editable="false"> <ID>class</ID> <Function>ClassName()</Function> </Literal> </Declarations> <Code Language="csharp"> <![CDATA[#region Public Properties #endregion #region Private / Protected #endregion #region Constructors /// <summary> /// Constructs a new instance of the <see cref="$class$" /> class. /// </summary> public $class$($end$) { } #endregion #region Methods #endregion #region Events #endregion #region Event Handlers #endregion #region Nested #endregion]]> </Code> </Snippet> </CodeSnippet> </CodeSnippets> { layoutc.snippet } <?xml version="1.0" encoding="utf-8" ?> <CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> <CodeSnippet Format="1.0.0"> <Header> <Title>layoutc</Title> <Shortcut>layoutc</Shortcut> <Description>Code snippet for region layout of code files that contain a class that can be edited in a designer (derived from Component)</Description> <Author>Dave Sexton</Author> <SnippetTypes> <SnippetType>Expansion</SnippetType> </SnippetTypes> </Header> <Snippet> <Declarations> <Literal Editable="false"> <ID>class</ID> <Function>ClassName()</Function> </Literal> </Declarations> <Code Language="csharp"> <![CDATA[#region Public Properties #endregion #region Private / Protected $end$ #endregion #region Constructors /// <summary> /// Constructs a new instance of the <see cref="$class$" /> class. /// </summary> public $class$() { InitializeComponent(); } #endregion #region Methods #endregion #region Events #endregion #region Event Handlers #endregion #region Nested #endregion]]> </Code> </Snippet> </CodeSnippet> </CodeSnippets> I want to repeat my post to another sub-thread of this thread about the underscore. It is becoming recognized as part of a whole set of characters that are the source of a new group of repetitive motion injuries in the work place associated with little-finger typing. For that reason alone, it is worth not using to me. Beyond that, I agree with Dave in that I think he's saying what I believe: we're moving forward in styles and knowledge and application of styles as a community and, in general, the new ways and standards are the result of experience and increased understanding. In otherwords, we know better today than we did before. The new standards are generally better than the old. Holding on to old habits just because "we have always done it that way" doesn't make sense. As a case in point, I often work with developers who have a long history in main frame development. As an example, a variable that I would call "serverName", they would argue strongly should be named "srvrnam". Go figure. Dale SignatureDale Preston MCAD C# MCSE, MCDBA > Hello Dave, > [quoted text clipped - 84 lines] > "At times one remains faithful to a cause only because its opponents do not > cease to be insipid." (c) Friedrich Nietzsche Hi Dale, > As an example, a variable that I would call > "serverName", they would argue strongly should be named "srvrnam". Go figure. Nice example. I think it should be named: m_strSVRNam1 ;) SignatureDave Sexton >I want to repeat my post to another sub-thread of this thread about the > underscore. It is becoming recognized as part of a whole set of characters [quoted text clipped - 105 lines] >> "At times one remains faithful to a cause only because its opponents do not >> cease to be insipid." (c) Friedrich Nietzsche >I want to repeat my post to another sub-thread of this thread about the >underscore. It is becoming recognized as part of a whole set of characters >that are the source of a new group of repetitive motion injuries in the work >place associated with little-finger typing. For that reason alone, it is >worth not using to me. That'sjustplainsilly.OnthatbasisaloneIamgoingtostopusingthespacebarbecauseit'sjusttoomuchtyping. SignaturePosted via a free Usenet account from http://www.teranews.com >Hi Kevin, > [quoted text clipped - 3 lines] >Of course, if you work in an environment where "_" is the accepted standard then it might not be >such a problem, but if you're program is ever touched by anyone else, it might be confusing to them. As long as the convention is used consistently, reasonable cognizant programmer shouldn't be confused for very long if at all. >Therefore, I don't believe that anyone should take any liberties when there is already >widely-accepted standardization in place. Agreed, if a convention is already in place it should be followed. Consistency of use should be the 'real' standard for any naming convention. regards A.G. Hi, <snip> >>Of course, if you work in an environment where "_" is the accepted standard then it might not be >>such a problem, but if you're program is ever touched by anyone else, it might be confusing to >>them. > > As long as the convention is used consistently, reasonable cognizant > programmer shouldn't be confused for very long if at all. Why should they have to be confused at all when there is a standard to prevent that in the first place? Of course, not all standards are perfect. But I tend to value a standardized approach over user-choice, because once some liberty is given you can usually expect that a lot more will be taken. <snip> SignatureDave Sexton >Hi, > [quoted text clipped - 9 lines] >Why should they have to be confused at all when there is a standard to prevent that in the first >place? What is _the_ industry-wide naming convention standard he asked rhetorically. >Of course, not all standards are perfect. But I tend to value a standardized approach over >user-choice, because once some liberty is given you can usually expect that a lot more will be >taken. Since there is no one standard naming convention, every standard is created by user choice. Naming convention decisions may be made at the corporate level, department level or even project level. Being able to understand and work with different naming conventions is an important part of the skills set. It goes hand-in-hand with being literate in multiple programming languages. regards A.G. Hi, No need to ask a rhetorical question because it has already been answered. I think this link posted by Mark Dawson (in this thread) says it all: "Naming Guidelines [.NET Framework]" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconnamingguidelines.asp SignatureDave Sexton >>Hi, >> [quoted text clipped - 26 lines] > regards > A.G. I personally have been through many naming conventions, starting using m_ then moved onto _ and now I prefer to use this. as a prefix. I think the most important thing is that all developers on a project use the same standard, you get some people saying "developers should be free to express themselves" my opinion is that developers can be free to come up with clever designs and solutions to problems but when they write up those solutions it should be in a uniform presentation style. There is nothing more frustrating that moving from one style to another trying to write code which I have found effects my efficiency when I move to another naming style. I also believe that using industry standards (i.e. the naming convention released by Microsoft) is a great way to go, why, because let Microsoft do all the work of writing the standard docs and publishing them and maintaining them, while your team can simply reference the docs, new members can easily refer to the docs and possibly are already using that naming convention since it is publicly available. Don't waste engineering time on things like this when you should be spending time developing products. Mark. Signaturehttp://www.markdawson.org > Hi, > [quoted text clipped - 35 lines] > > regards > > A.G. Hi Mark, Agreed. SignatureDave Sexton >I personally have been through many naming conventions, starting using m_ > then moved onto _ and now I prefer to use this. as a prefix. I think the [quoted text clipped - 58 lines] >> > regards >> > A.G. Dave, >"Naming Guidelines [.NET Framework]" >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconnamingguidelines.asp These guidelines are primarily for publicly accessible members. "The goal of the .NET Framework design guidelines is to encourage consistency and predictability in *public APIs* while enabling Web and cross-language integration." (Emphasis added) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconnetframeworkdesignguidelines.asp And more clearly "Casing and naming guidelines apply only to public and protected identifiers, and privately implemented interface members. Teams are free to choose their own guidelines for internal and private identifiers." http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx Mattias SignatureMattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. Hi Mattias, In a different post than the one to which you replied I added a different link that is contrary to your statement. Here it is again: "Field Usage Guidelines [.NET Framework]" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconfieldusageguidelines.asp?frame=true It's quite clear that they are referring to private fields. Scroll to the example at the bottom and read the nearby bullets. SignatureDave Sexton > Dave, > [quoted text clipped - 19 lines] > > Mattias dave, >It's quite clear that they are referring to private fields. Scroll to the example at the bottom and >read the nearby bullets. I don't think that's clear at all, since those bullets don't specifically say anything about private fields. They make perfect sense for public and protected fields (in the few cases you expose such). And the updated guidelines on MSDN2 that others have referred to spells this out more clearly. Mattias SignatureMattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. Hi Mattias, Yes, it's come to my attention that Microsoft's policies may have changed. But, those bullets appear immediately after an example that uses private fields without prefixes. I think it's clear. SignatureDave Sexton > dave, > [quoted text clipped - 9 lines] > > Mattias > Yes, it's come to my attention that Microsoft's policies may have > changed. > > But, those bullets appear immediately after an example that uses > private fields without prefixes. I think it's clear. I agree with Dave that it is clear in the documentation that was presented when you consider the example code. The problem is that it is older documentation and newer docs are available. Best Regards, Dustin Campbell Developer Express Inc Mattias, >>"Naming Guidelines [.NET Framework]" >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconnamingguidelines.asp > > These guidelines are primarily for publicly accessible members. While they cover private members, I think you raise a good point. I am now leaning towards an underscore prefix for member variables. If I go that way, this will have no effect on libraries, etc. I create to be consumed by others. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com >Since there is no one standard naming convention, every standard is >created by user choice. Naming convention decisions may be made at the >corporate level, department level or even project level. Being able to >understand and work with different naming conventions is an important >part of the skills set. It goes hand-in-hand with being literate in >multiple programming languages. Which makes it a bit odd that those of us used to "m_" prefixes and Hungarian notation as wellshould be expected to reduce to no conventions at all in this respect. SignaturePosted via a free Usenet account from http://www.teranews.com Thanks for that link. BTW, these guidelines call for using the same conventions on member variables as for method arguments. This results in naming conflicts, especially in constructors. How do you deal with this issue. (I personally dislike using this.var everywhere for member variables just to avoid this conflict.) SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > Hi Jonathan, > here is a link to the Microsoft guidelines for naming conventions: [quoted text clipped - 12 lines] >> >> Thanks for any comments. Using the same convention in constructors works just fine without using "this". For instance, the compiler understands this perfectly: public class MyClass { int myInt; public MyClass(int myInt) { myInt = myInt; } } The compiler understands it perfectly and assigns to the field myInt, the value of the parameter myInt. I don't find this confusing either. I know that if I am assigning like names then that one is going to be the parameter and one the field. FxCop, on the other hand, does object to this but what does FxCopy know? Dale SignatureDale Preston MCAD C# MCSE, MCDBA > Thanks for that link. > [quoted text clipped - 21 lines] > >> > >> Thanks for any comments. Ack! I don't like that at all. What about myInt = myInt + myInt? I mean, I've never *ever* seen anyone do this. I'll just have to take your word for it that it actual works (it doesn't seem like it could). But I would avoid this approach like the plague. Thanks. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > Using the same convention in constructors works just fine without using > "this". For instance, the compiler understands this perfectly: [quoted text clipped - 44 lines] >> >> >> >> Thanks for any comments. Actually, I was wrong. I guess I hadn't written a constructor since I slept last. All my constructors that have parameters named just like fields utilize "this." in the assignment. Dale SignatureDale Preston MCAD C# MCSE, MCDBA > Ack! I don't like that at all. What about myInt = myInt + myInt? I mean, > I've never *ever* seen anyone do this. I'll just have to take your word for [quoted text clipped - 51 lines] > >> >> > >> >> Thanks for any comments. Jonathan Wood <jwood@softcircuits.com> loquated like no one had ever loquated before with: > Ack! I don't like that at all. What about myInt = myInt + myInt? I > mean, I've never *ever* seen anyone do this. I'll just have to take > your word for it that it actual works (it doesn't seem like it > could). But I would avoid this approach like the plague. I would suggest that the problem above is not managing to specify to the compiler which myInt is which, but that you need to name your arguments differently. Getting it to compile correctly is one thing, but not the only thing. WTH Signature"One of the things I am in the habit of saying is that the only place success comes before work is in the dictionary." - Gérard Houllier > The compiler understands it perfectly and assigns to the field myInt, the > value of the parameter myInt. Not true, if you have: class Person { private string name; public Person(string name) { name = name; } } Then the compiler will simply assign the local variable name to itself, you will get a warning about this (hopefully an error since nobody would leave the "treat warning as error" option unchecked :-P), after the constructor has executed the class field "name" is still null. This is also very confusing, the "this." is required. Also in the case below: class Person { private string name; public Person(string name) { name = name; } public void DoSomething(string name) { string finalName = name + "xyz"; } } The compiler does not give any warning about the possible ambiguity of the variable named "name", did you mean to use the local variable or the class field but forgot the this. prefix, from what I can tell this is possibly a case against using the this. notation. Mark. Signaturehttp://www.markdawson.org > Using the same convention in constructors works just fine without using > "this". For instance, the compiler understands this perfectly: [quoted text clipped - 43 lines] > > >> > > >> Thanks for any comments. Mark, >> The compiler understands it perfectly and assigns to the field myInt, the >> value of the parameter myInt. [quoted text clipped - 17 lines] > has > executed the class field "name" is still null. You know, I would've sworn that was the case. But since I have no tested it directlyed, I was not comfortable saying Dale was wrong. I figured he tried it out. As far as I'm concerned, this should not work and should be avoided even if it did work. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com Hi Jonathan, I agree, I am not sure why self assignment is legal, maybe there is some perfectly good case for it, I can't think of any though. Mark. Signaturehttp://www.markdawson.org > Mark, > [quoted text clipped - 26 lines] > As far as I'm concerned, this should not work and should be avoided even if > it did work. > here is a link to the Microsoft guidelines for naming conventions: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgen > ref/html/cpconnamingguidelines.asp > I follow these. Hey Mark, That is an older guideline from the old MSDN library. The most current one is located here: http://msdn2.microsoft.com/en-us/library/ms229042.aspx. It clears up certain areas that are a bit vague. Best Regards, Dustin Campbell Developer Express Inc. > I was just wondering what naming convention most of you use for class > variables. [quoted text clipped - 9 lines] > SoftCircuits Programming > http://www.softcircuits.com Camel case. class TheClass { private int theInt; public int TheInt { blah, blah, blah } } -- Tom Shelton Hello Jonathan, Fully support Kevin's point about using "_" that helps to differ private/internal variables. It is very usefull in codereview, because very often u use simple text editors for this JW> I was just wondering what naming convention most of you use for JW> class variables. JW> JW> Underscore, "m_" prefix, camel case, capitalized, etc? JW> JW> Has one style emerged as the most popular? JW> JW> Thanks for any comments. JW> --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche I agree. I always use the underscore to designate private/internal variables for this reason. It's a quick visual, rather than having to examine the case. Robin S. > Hello Jonathan, > [quoted text clipped - 13 lines] > "At times one remains faithful to a cause only because its opponents do > not cease to be insipid." (c) Friedrich Nietzsche Yes, this seems to be the area that I'm now torn between. Microsoft's guidelines are very specifically against the use of m_ or _. But not only is it nice to be able to see at a glance if you're looking at a member variable or something else, it also prevents conflict between argument and member variables having the same name. In Microsoft Press's C# Step by Step this issue is dealt with by using this. before all member variables. I just don't like that or see any need for it. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > Hello Jonathan, > [quoted text clipped - 13 lines] > "At times one remains faithful to a cause only because its opponents do > not cease to be insipid." (c) Friedrich Nietzsche Hi Jonathan, <snip> >> Fully support Kevin's point about using "_" that helps to differ private/internal variables. It >> is very usefull in codereview, because very often u use simple text editors for this [quoted text clipped - 5 lines] > dealt with by using this. before all member variables. I just don't like that or see any need for > it. If I had to guess why "_" is not considered standard, for reasons other than those I've already posted in this thread, I'd say that the designers of these standards saw a need to get rid of symbols in names. I think the sporadic use of "this" is simply more legible than "_", which only has meaning when it's assigned by the author. "this", together with lower camel case, is less likely to be misunderstood. This is especially useful since .NET development has become an amalgamation of developers from many different platforms with many different skill-sets and practices. Many developers move to C# and have to learn a new, unique language with new standards as well. A non-symbolic and expressive naming convention was in order. I think they made the right choice excluding a random prefix (seemingly random to people coming from languages where it's not used) from variable names since it really doesn't provide value anyway. SignatureDave Sexton Dave, > If I had to guess why "_" is not considered standard, for reasons other > than those I've already posted in this thread, I'd say that the designers > of these standards saw a need to get rid of symbols in names. Absolutely. I mean, with C++, all strings should be wrapped in the _T() macro and every run-time library routine and API appears to have both an ASCII and Unicode version. Clearly, the .NET designers wanted to clean things up a little and, presumably, thought simple names were cleaner than all this Hungarian notation, etc. > I think the sporadic use of "this" is simply more legible than "_", which > only has meaning when it's assigned by the author. "this", together with > lower camel case, is less likely to be misunderstood. Yeah, I can't do it. One thing (of many things) that annoy me about .NET is the verboseness. Having suffered from carpel-tunnel issues from time to time, I'm not going to prefix every occurrance of a member variable with five additional characters. I guess that is as good as any argument for me to adopt the "_" prefix as my personal style. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com Hi Jonathon, >> If I had to guess why "_" is not considered standard, for reasons other than those I've already >> posted in this thread, I'd say that the designers of these standards saw a need to get rid of [quoted text clipped - 4 lines] > designers wanted to clean things up a little and, presumably, thought simple names were cleaner > than all this Hungarian notation, etc. Hungarian notation isn't completely outlawed, however :) I see no mention in the standards about the use of "txtFirstName", for example, and I try to use this notation when I need to distinguish between controls that would otherwise have identical names, such as, "lblFirstName". Standardized prefixes are desirable, but I can live without them. >> I think the sporadic use of "this" is simply more legible than "_", which only has meaning when >> it's assigned by the author. "this", together with lower camel case, is less likely to be [quoted text clipped - 4 lines] > occurrance of a member variable with five additional characters. I guess that is as good as any > argument for me to adopt the "_" prefix as my personal style. Not every occurrence of a member variable. I only use "this" as a prefix once during assignment, usually in a constructor and only if there is a conflicting parameter name. Other references are without any prefix at all. SignatureDave Sexton Dave, >> Absolutely. I mean, with C++, all strings should be wrapped in the _T() >> macro and every run-time library routine and API appears to have both an [quoted text clipped - 3 lines] > > Hungarian notation isn't completely outlawed, however :) Actually, in the Microsoft guidelines, it really is. > I see no mention in the standards about the use of "txtFirstName", for > example, and I try to use this notation when I need to distinguish between > controls that would otherwise have identical names, such as, > "lblFirstName". Standardized prefixes are desirable, but I can live > without them. Reference to controls is a bit different that straight variables. I haven't see what the guidelines say about that. >> Yeah, I can't do it. One thing (of many things) that annoy me about .NET >> is the verboseness. Having suffered from carpel-tunnel issues from time [quoted text clipped - 3 lines] > > Not every occurrence of a member variable. I think consistency is important. Using the this. prefix only some of the time could get you into trouble. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com Hi Jonathan, >> Hungarian notation isn't completely outlawed, however :) > > Actually, in the Microsoft guidelines, it really is. No, it's really not :) Care to show me where Microsoft says that controls shouldn't be named with prefixes such as "txt" or "lbl"? (They are stored as private fields, you know) SignatureDave Sexton > Dave, > [quoted text clipped - 24 lines] > I think consistency is important. Using the this. prefix only some of the time could get you into > trouble. Well I was going to look that up again but I see you gave me a trick question. I just stated in the post you were replying to that I considered references to controls a bit different than straight variables. Perhaps you didn't read my entire post, eh? We were talking about member variables. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > Hi Jonathan, > [quoted text clipped - 40 lines] >> I think consistency is important. Using the this. prefix only some of the >> time could get you into trouble. Hi Jonathan, > Well I was going to look that up again but I see you gave me a trick question. I just stated in > the post you were replying to that I considered references to controls a bit different than > straight variables. Perhaps you didn't read my entire post, eh? We were talking about member > variables. I read your entire post. No tricks here :) We are talking about fields (member variables, as you say), which txtFirstName and lblFirstName certainly are. How would you name these two Controls? SignatureDave Sexton Dave, >> Well I was going to look that up again but I see you gave me a trick >> question. I just stated in the post you were replying to that I [quoted text clipped - 8 lines] > > How would you name these two Controls? Well, as I indicated, I consider that a different issue. I haven't decided on this issue for sure, but I have a tendancy to stick with what I did in VB, which is to include those prefixes. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com Hi Jonathan, >>> Well I was going to look that up again but I see you gave me a trick question. I just stated in >>> the post you were replying to that I considered references to controls a bit different than [quoted text clipped - 10 lines] > Well, as I indicated, I consider that a different issue. I haven't decided on this issue for sure, > but I have a tendancy to stick with what I did in VB, which is to include those prefixes. I don't see it as a different issue at all. They are fields. (but the point is a moot one anyway since you were right...) BTW, I found two interesting bullets in a Microsoft document [link below] regarding the use of hungarian notation and the "_" prefix in field names: - Do not use Hungarian notation for field names. Good names describe semantics, not type. I must argue here that my examples of txtFirstName and lblFirstName indicate both type and semantics. However, I use the notation in other controls even when there is no ambiguity, but I'm going to try to break that habit for my next project. Do I really need to know that a field is a Control by looking at its name when I have intellisense and tooltips on hand at all times? - I don't think so, but I'll see how it goes ;) - Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect. "Field Usage Guidelines [.NET Framework]" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/c pconfieldusageguidelines.asp?frame=true SignatureDave Sexton Dave, > BTW, I found two interesting bullets in a Microsoft document [link below] > regarding the use of hungarian notation and the "_" prefix in field names: Yeah, those were the ones I was thinking about. Microsoft is being very one-sided about not using those prefixes. If you see where they talk about control names, please pass it along. > I must argue here that my examples of txtFirstName and lblFirstName > indicate both type and semantics. However, I use the notation in other > controls even when there is no ambiguity, but I'm going to try to break > that habit for my next project. Do I really need to know that a field is > a Control by looking at its name when I have intellisense and tooltips on > hand at all times? - I don't think so, but I'll see how it goes ;) I think it is still useful. Yes, Intellisense offers assistance here but I often print code and review it in more detail. Also, for more complex code, it may just be more efficient to know what a variable refers to just by looking. In the end, I have mixed feelings about this. I'm all for cleaning things up, but I've been programming a long, long time and readability is important. I'm not 100% sure I'm ready to abandon prefixes that tell me about a particular variable. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com >I think consistency is important. You're dead on target. Regardless of the naming convention used in a project, consistency is the crux of the biscuit. If the convention isn't followed it is of no value. The OP wrote of programmers being confused by different naming conventions. The responses indicate a great deal of personal preference but no tales of confusion have been told. regards A.G. >>I think consistency is important. > >You're dead on target. Regardless of the naming convention used in a >project, consistency is the crux of the biscuit. If the convention >isn't followed it is of no value. I got this wrong. It wasn't the OP but a followup that mentioned confusion. >The OP wrote of programmers being confused by different naming >conventions. The responses indicate a great deal of personal >preference but no tales of confusion have been told. > >regards >A.G. Hi, Isn't there value in constancy across an entire community as well? Have you not had to work with code where someone else took their own liberties in choosing what was appropriate as standards (even if consistent with their organization's standards when the code was written), leaving you weeping, pulling out hair and going for coffee every 20 minutes? ;) SignatureDave Sexton >>I think consistency is important. > [quoted text clipped - 8 lines] > regards > A.G. Dave, > Isn't there value in constancy across an entire community as well? Of course. That's why I started this thread--to try and determine what the community was doing. But I think that inconsistency within a single standard is even worse than inconsistency within the community. > Have you not had to work with code where someone else took their own > liberties in choosing what was appropriate as standards (even if > consistent with their organization's standards when the code was written), > leaving you weeping, pulling out hair and going for coffee every 20 > minutes? After 20 years of programming, you can bet that I have. SignatureJonathan Wood SoftCircuits Programming http://www.so |
Enable EMail Alerts
Start New Thread
Reply to this Message