C# coding style question
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this; -
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;I prefer option 1, but whichever option you pick, consistency is the key!
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this; -
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;I prefer to put visibility first, and for what it's worth, I don't think I would make a static field public.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this; -
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;I'm with Richard Deeming. Additionally, I always specify the access modifier, I never allow a default to apply -- I think the defaults should be removed from the language.
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;I agree with Richard Deeming's response focusing on "consistency." And, I emphatically agree with PIEBALDConsult's response, when he says/implies that one should always specify the scope with Public/Private, and that it would be a good thing for the .NET compiler to "enforce" this. I prefer to use: public/private static variabletype. It's interesting to me that if you write (C#, WinForms) inside the scope of a Form's class definition:
public static bool availableOutsideFormClassScope = true;
That ReSharper 8 will "suggest" that the use of 'public is redundant. But, if you write this:
static bool notAvailableOutsideFormClassScope = true;
, you have, in effect, declared this variable as private. I have never had occasion to use a Form scoped static variable, method, embedded class, etc; I only use static when I want something to be accessible outside a Form's class scope. But, perhaps if I were dealing with multiple instance of the same application, or multi-threading, there would be an "organic" need for this ? When I write applications where there are multiple independent Forms (in WinForms this can be done by modifying the Program.cs file so it calls an initializer method to "run" the application ... and that initializer creates and "shows" all Form instances ... rather than doing the usual: Application.Run(new SomeMainForm()); ... in that circumstance I usually use a ststic class defined as an an application top-level class (i.e., added via VS's Project/Add Class menu). I know there are people who feel an almost "religious zeal" about not using static anything/anywhere, perceiving the use of static whatever as a violation of the No-Globals-Strongly-Typed supreme being, and doomed to provoke the wrath of the Threading sub-deities :) I have yet to have a cause to feel such a conviction. Bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;i suggest frist one style.
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;I always like to use the access modifier first.
-
For
staticmembers, do you preferpublic static Type Member;
or
static public Type Member;
where
publiccan be any of the visibility keywords. I've found I use both :-O, and I'm trying to find out if there's a best practice out there that makes sense.Software Zen:
delete this;I'm with Richard Deeming here, I use the first method myself. As Richard said, consistency is the key!
-
I agree with Richard Deeming's response focusing on "consistency." And, I emphatically agree with PIEBALDConsult's response, when he says/implies that one should always specify the scope with Public/Private, and that it would be a good thing for the .NET compiler to "enforce" this. I prefer to use: public/private static variabletype. It's interesting to me that if you write (C#, WinForms) inside the scope of a Form's class definition:
public static bool availableOutsideFormClassScope = true;
That ReSharper 8 will "suggest" that the use of 'public is redundant. But, if you write this:
static bool notAvailableOutsideFormClassScope = true;
, you have, in effect, declared this variable as private. I have never had occasion to use a Form scoped static variable, method, embedded class, etc; I only use static when I want something to be accessible outside a Form's class scope. But, perhaps if I were dealing with multiple instance of the same application, or multi-threading, there would be an "organic" need for this ? When I write applications where there are multiple independent Forms (in WinForms this can be done by modifying the Program.cs file so it calls an initializer method to "run" the application ... and that initializer creates and "shows" all Form instances ... rather than doing the usual: Application.Run(new SomeMainForm()); ... in that circumstance I usually use a ststic class defined as an an application top-level class (i.e., added via VS's Project/Add Class menu). I know there are people who feel an almost "religious zeal" about not using static anything/anywhere, perceiving the use of static whatever as a violation of the No-Globals-Strongly-Typed supreme being, and doomed to provoke the wrath of the Threading sub-deities :) I have yet to have a cause to feel such a conviction. Bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
BillWoodruff wrote:
I know there are people who feel an almost "religious zeal" about not using static anything/anywhere, perceiving the use of static whatever as a violation of the No-Globals-Strongly-Typed supreme being
I have a feeling you and I are of a vintage, Bill :). We are grizzled combat veterans of the FORTRAN wars. We remember when men were men, women created compilers[^], and you knew how to handle globals safely.
Software Zen:
delete this; -
I prefer to put visibility first, and for what it's worth, I don't think I would make a static field public.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
Espen Harlinn wrote:
I don't think I would make a static field public
I normally don't, but for the purposes of the example...
Software Zen:
delete this; -
Espen Harlinn wrote:
I don't think I would make a static field public
I normally don't, but for the purposes of the example...
Software Zen:
delete this;:thumbsup: Fair enough ;) But then you never know who is following these discussions, and some will surely copy your code without a second thought ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
I prefer the following.
static public...
private static...I do it that way to make the basic nature of the items more visible to all.
Hmm. Some of my usage variation seems like that, like my intent was to call attention to the fact something was
static.Software Zen:
delete this; -
I'm with Richard Deeming. Additionally, I always specify the access modifier, I never allow a default to apply -- I think the defaults should be removed from the language.
I always specify the access modifier as well. I've always distrusted my memory when it comes to default behaviors with subtle consequences. I explicitly parenthesize as well :-O.
Software Zen:
delete this; -
:thumbsup: Fair enough ;) But then you never know who is following these discussions, and some will surely copy your code without a second thought ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
If they're copying the millifragment I posted, they're in more trouble than they know.
Software Zen:
delete this; -
If they're copying the millifragment I posted, they're in more trouble than they know.
Software Zen:
delete this;Agree, but then, on the other hand, they probably wouldn't notice ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
Hmm. Some of my usage variation seems like that, like my intent was to call attention to the fact something was
static.Software Zen:
delete this;Then you should have said so.
-
I agree with Richard Deeming's response focusing on "consistency." And, I emphatically agree with PIEBALDConsult's response, when he says/implies that one should always specify the scope with Public/Private, and that it would be a good thing for the .NET compiler to "enforce" this. I prefer to use: public/private static variabletype. It's interesting to me that if you write (C#, WinForms) inside the scope of a Form's class definition:
public static bool availableOutsideFormClassScope = true;
That ReSharper 8 will "suggest" that the use of 'public is redundant. But, if you write this:
static bool notAvailableOutsideFormClassScope = true;
, you have, in effect, declared this variable as private. I have never had occasion to use a Form scoped static variable, method, embedded class, etc; I only use static when I want something to be accessible outside a Form's class scope. But, perhaps if I were dealing with multiple instance of the same application, or multi-threading, there would be an "organic" need for this ? When I write applications where there are multiple independent Forms (in WinForms this can be done by modifying the Program.cs file so it calls an initializer method to "run" the application ... and that initializer creates and "shows" all Form instances ... rather than doing the usual: Application.Run(new SomeMainForm()); ... in that circumstance I usually use a ststic class defined as an an application top-level class (i.e., added via VS's Project/Add Class menu). I know there are people who feel an almost "religious zeal" about not using static anything/anywhere, perceiving the use of static whatever as a violation of the No-Globals-Strongly-Typed supreme being, and doomed to provoke the wrath of the Threading sub-deities :) I have yet to have a cause to feel such a conviction. Bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
Just to clarify:
static bool notAvailableOutsideFormClassScope = true;
is in fact NOT
private. Neither is itpublic. The default isinternal(scope=assembly). As a default this makes the most sense in my opinion (regardless if having a default makes sense at all) I still specify the visibility for every class (and member). Just because I don't like relying on defaults ;) Edit: See Access Modifiers (C# Programming Guide) (MSDN)[^] First paragraph of the section "Class and Struct Accessibility" Edit2: Regarding Resharper (At least in Version 6.1) you let Resharper suggest explicit access modifiers: :) -> Resharper -> Options... -> Code Editing -> Formatting Style -> Other -> Modifiers -> "Use explicit private modifier" / "Use explicit internal modifier" -
I agree with Richard Deeming's response focusing on "consistency." And, I emphatically agree with PIEBALDConsult's response, when he says/implies that one should always specify the scope with Public/Private, and that it would be a good thing for the .NET compiler to "enforce" this. I prefer to use: public/private static variabletype. It's interesting to me that if you write (C#, WinForms) inside the scope of a Form's class definition:
public static bool availableOutsideFormClassScope = true;
That ReSharper 8 will "suggest" that the use of 'public is redundant. But, if you write this:
static bool notAvailableOutsideFormClassScope = true;
, you have, in effect, declared this variable as private. I have never had occasion to use a Form scoped static variable, method, embedded class, etc; I only use static when I want something to be accessible outside a Form's class scope. But, perhaps if I were dealing with multiple instance of the same application, or multi-threading, there would be an "organic" need for this ? When I write applications where there are multiple independent Forms (in WinForms this can be done by modifying the Program.cs file so it calls an initializer method to "run" the application ... and that initializer creates and "shows" all Form instances ... rather than doing the usual: Application.Run(new SomeMainForm()); ... in that circumstance I usually use a ststic class defined as an an application top-level class (i.e., added via VS's Project/Add Class menu). I know there are people who feel an almost "religious zeal" about not using static anything/anywhere, perceiving the use of static whatever as a violation of the No-Globals-Strongly-Typed supreme being, and doomed to provoke the wrath of the Threading sub-deities :) I have yet to have a cause to feel such a conviction. Bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
Well if all you're writing is front-end stuff, then you wouldn't have many public members anyway. I write mostly back-end library stuff so a great many of my members are public static methods, but not many fields. A few examples:
public static readonly System.Type BaseType = typeof(T) ;
public static readonly Rational MaxValue = new Rational ( decimal.MaxValue , 1M ) ;
public static event ErrorDelegate OnError ;
public static ValueOf<T> operator + ( ValueOf<T> Op1 , ValueOf<T> Op2 ) ...
public static System.Reflection.PropertyInfo CommandTextAttributeProperty { get ; private set ; }Consistency allowed me to
findthese easily.