| Groups | Blog | Home |
c# : Proposal: Renaming of the "private" Keyword
to be changed. There is nothing that says you cannot organize your code by grouping like members. [quoted text, click to view] "C# Learner" <csharp@learner.here> wrote in message news:uL$2ciuCEHA.3256@TK2MSFTNGP09.phx.gbl... > A recent discussion in here has got me reflecting on the "private" > keyword. As I mentioned in the discussion, I find the keyword > problematic, in that it looks too similar to "public" and therefore > makes quickly scanning for public members among private ones, hard. > > This kind of thing wasn't so important in a language like C++ or Delphi, > where class member declarations were separate. However, since C# > members aren't declared ahead - but defined in place - I feel this is an > issue in this language. > > Consider the following code: > > class Test > { > public void Foo() > { > Blah(); > } > > private int Blah() > { > Bleh(); > return 0; > } > > private SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > private void Fewbar() > { > F00Bar(); > } > > private bool F00Bar() > { > Bl4h(); > return true; > } > } > > In the above, can you, while quickly scanning, indicate which methods > are public? > > I know I can't. I'd imagine others would agree. > > "private" is too similar to "public". > > It could be renamed to, for example, "concealed". > > Here's the above code edited to use "concealed" instead of "private". > > class Test > { > public void Foo() > { > Blah(); > } > > concealed int Blah() > { > Bleh(); > return 0; > } > > concealed SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > concealed void Fewbar() > { > F00Bar(); > } > > concealed bool F00Bar() > { > Bl4h(); > return true; > } > } > > In my opinion, it is an order of magnitude easier to tell which are the > public methods in the above. > > Whadda ya think?
[quoted text, click to view]
C# Learner wrote: > A recent discussion in here has got me reflecting on the "private" > keyword. As I mentioned in the discussion, I find the keyword > problematic, in that it looks too similar to "public" and therefore > makes quickly scanning for public members among private ones, hard. > > This kind of thing wasn't so important in a language like C++ or Delphi, > where class member declarations were separate. However, since C# > members aren't declared ahead - but defined in place - I feel this is an > issue in this language. > > Consider the following code: > ...snip... [quoted text, click to view] > > In my opinion, it is an order of magnitude easier to tell which are the > public methods in the above. > > Whadda ya think? I think that regardless of whether or not its a good idea, it's not enough of a benefit to get into the language. There are 2 major roadblocks: 1) adding a new keyword to the language is something the designers are very reluctant to do. by definition, it's a breaking change since any new keyword you come up with could be used as an identifier by existing code. 2) to keep compatibility with existing code, the language would still have to support the 'private' keyword. So everyone used to using private would almost certainly continue using it. To overcome these problems, the benefit would have to be clear. --
C# Learner,
The difference between the two words is quite clear to me, but then, I also write fiction for fun as a sideline, so maybe my ability to discern differences in words has been sharpened over the years. Chris A.R. [quoted text, click to view] "C# Learner" <csharp@learner.here> wrote in message news:uL$2ciuCEHA.3256@TK2MSFTNGP09.phx.gbl... > A recent discussion in here has got me reflecting on the "private" > keyword. As I mentioned in the discussion, I find the keyword > problematic, in that it looks too similar to "public" and therefore > makes quickly scanning for public members among private ones, hard. > > This kind of thing wasn't so important in a language like C++ or Delphi, > where class member declarations were separate. However, since C# > members aren't declared ahead - but defined in place - I feel this is an > issue in this language. > > Consider the following code: > > class Test > { > public void Foo() > { > Blah(); > } > > private int Blah() > { > Bleh(); > return 0; > } > > private SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > private void Fewbar() > { > F00Bar(); > } > > private bool F00Bar() > { > Bl4h(); > return true; > } > } > > In the above, can you, while quickly scanning, indicate which methods > are public? > > I know I can't. I'd imagine others would agree. > > "private" is too similar to "public". > > It could be renamed to, for example, "concealed". > > Here's the above code edited to use "concealed" instead of "private". > > class Test > { > public void Foo() > { > Blah(); > } > > concealed int Blah() > { > Bleh(); > return 0; > } > > concealed SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > concealed void Fewbar() > { > F00Bar(); > } > > concealed bool F00Bar() > { > Bl4h(); > return true; > } > } > > In my opinion, it is an order of magnitude easier to tell which are the > public methods in the above. > > Whadda ya think?
I do hope that the standards people don't change the language every time
someone comes up with a 'neat' little twist. This is a programming language - learn it, master it, and move on. It ain't yours to change! If you were allowed to inject your changes, then you must allow others, and so on. Then the problem you have with 'not liking the name of private' becomes trivial in comparison. roy fine [quoted text, click to view] "C# Learner" <csharp@learner.here> wrote in message news:uL$2ciuCEHA.3256@TK2MSFTNGP09.phx.gbl... > A recent discussion in here has got me reflecting on the "private" > keyword. As I mentioned in the discussion, I find the keyword > problematic, in that it looks too similar to "public" and therefore > makes quickly scanning for public members among private ones, hard. > > This kind of thing wasn't so important in a language like C++ or Delphi, > where class member declarations were separate. However, since C# > members aren't declared ahead - but defined in place - I feel this is an > issue in this language. > > Consider the following code: > > class Test > { > public void Foo() > { > Blah(); > } > > private int Blah() > { > Bleh(); > return 0; > } > > private SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > private void Fewbar() > { > F00Bar(); > } > > private bool F00Bar() > { > Bl4h(); > return true; > } > } > > In the above, can you, while quickly scanning, indicate which methods > are public? > > I know I can't. I'd imagine others would agree. > > "private" is too similar to "public". > > It could be renamed to, for example, "concealed". > > Here's the above code edited to use "concealed" instead of "private". > > class Test > { > public void Foo() > { > Blah(); > } > > concealed int Blah() > { > Bleh(); > return 0; > } > > concealed SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > concealed void Fewbar() > { > F00Bar(); > } > > concealed bool F00Bar() > { > Bl4h(); > return true; > } > } > > In my opinion, it is an order of magnitude easier to tell which are the > public methods in the above. > > Whadda ya think?
A recent discussion in here has got me reflecting on the "private"
keyword. As I mentioned in the discussion, I find the keyword problematic, in that it looks too similar to "public" and therefore makes quickly scanning for public members among private ones, hard. This kind of thing wasn't so important in a language like C++ or Delphi, where class member declarations were separate. However, since C# members aren't declared ahead - but defined in place - I feel this is an issue in this language. Consider the following code: class Test { public void Foo() { Blah(); } private int Blah() { Bleh(); return 0; } private SomeType Bleh() { Foobar(); return new SomeType(); } public string Blow() { Fewbar(); return String.Empty; } private void Fewbar() { F00Bar(); } private bool F00Bar() { Bl4h(); return true; } } In the above, can you, while quickly scanning, indicate which methods are public? I know I can't. I'd imagine others would agree. "private" is too similar to "public". It could be renamed to, for example, "concealed". Here's the above code edited to use "concealed" instead of "private". class Test { public void Foo() { Blah(); } concealed int Blah() { Bleh(); return 0; } concealed SomeType Bleh() { Foobar(); return new SomeType(); } public string Blow() { Fewbar(); return String.Empty; } concealed void Fewbar() { F00Bar(); } concealed bool F00Bar() { Bl4h(); return true; } } In my opinion, it is an order of magnitude easier to tell which are the public methods in the above.
[quoted text, click to view]
Peter Rilling wrote: Hi Peter, Thanks for the reply. [quoted text, click to view] > "private" is probably too engrained in the developers' mind and our legacy > to be changed. I understand that. I feel it's also engrained in my mind, but, still, I'm open for change. I'd accept this change to "private" for the benefit it'd give, as detailed in the original post. [quoted text, click to view] > There is nothing that says you cannot organize your code by grouping like > members. This makes C# code harder to read, in my opinion. I prefer to see private methods that are called by public methods directly under the public methods, and private methods called by those private methods directly under *them*, and so on. I've seen other C# code that uses this structure, too, so it isn't just me :-) I'd be interested in others' feedback too.
If you have a hard time seeing the difference between private and public,
then get a better IDE. If VS.NET doesn't cut it, check out CodeRush from www.devexpress.com, since it adds little icons to represent each member. -mike MVP [quoted text, click to view] "C# Learner" <csharp@learner.here> wrote in message
news:uL$2ciuCEHA.3256@TK2MSFTNGP09.phx.gbl... > A recent discussion in here has got me reflecting on the "private" > keyword. As I mentioned in the discussion, I find the keyword > problematic, in that it looks too similar to "public" and therefore > makes quickly scanning for public members among private ones, hard. > > This kind of thing wasn't so important in a language like C++ or Delphi, > where class member declarations were separate. However, since C# > members aren't declared ahead - but defined in place - I feel this is an > issue in this language. > > Consider the following code: > > class Test > { > public void Foo() > { > Blah(); > } > > private int Blah() > { > Bleh(); > return 0; > } > > private SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > private void Fewbar() > { > F00Bar(); > } > > private bool F00Bar() > { > Bl4h(); > return true; > } > } > > In the above, can you, while quickly scanning, indicate which methods > are public? > > I know I can't. I'd imagine others would agree. > > "private" is too similar to "public". > > It could be renamed to, for example, "concealed". > > Here's the above code edited to use "concealed" instead of "private". > > class Test > { > public void Foo() > { > Blah(); > } > > concealed int Blah() > { > Bleh(); > return 0; > } > > concealed SomeType Bleh() > { > Foobar(); > return new SomeType(); > } > > public string Blow() > { > Fewbar(); > return String.Empty; > } > > concealed void Fewbar() > { > F00Bar(); > } > > concealed bool F00Bar() > { > Bl4h(); > return true; > } > } > > In my opinion, it is an order of magnitude easier to tell which are the > public methods in the above. > > Whadda ya think?
1. You can group member objects according to your preference. For
instance, you can set all the private members at the end of the class and the public ones at the top. with regards, J.V.Ravichandran - http://www.geocities.com/ jvravichandran - http://www.411asp.net/func/search? qry=Ravichandran+J.V.&cob=aspnetpro - http://www.southasianoutlook.com - http://www.MSDNAA.Net - http://www.csharphelp.com - http://www.poetry.com/Publications/ display.asp?ID=P3966388&BN=999&PN=2 - Or, just search on "J.V.Ravichandran" at http://www.Google.com *** Sent via Developersdex http://www.developersdex.com ***
Since private is always the default, perhaps you could leave out the private keyword completely if you think that would that make your code easier to read. Mattias -- Mattias Sjögren [MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
[quoted text, click to view]
C# Learner <csharp@learner.here> wrote: > A recent discussion in here has got me reflecting on the "private" > keyword. As I mentioned in the discussion, I find the keyword > problematic, in that it looks too similar to "public" and therefore > makes quickly scanning for public members among private ones, hard. <snip> I certainly wouldn't advocate a change of the language at this stage, and the names "public" and "private" are so common in computer science that I think the boat has sailed on that one. However, an IDE could syntax highlight them in different colours to make it clearer. Alternatively, you could miss out the private modifier like I do :) -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet
As well as what Mike says IMO the direct text structure of code is pretty
much irrelevant with todays sophicated IDE's. I mostly navigate around a class using the various navigation tools rather than looking directly at the code. The access status is as clear as a bell in the class explorer and you can choose to display by access if you wish. Cheers Doug Forster [quoted text, click to view] "mikeb" <mailbox.google@mailnull.com> wrote in message news:Oo0fi9uCEHA.2600@TK2MSFTNGP12.phx.gbl... > C# Learner wrote: > > > A recent discussion in here has got me reflecting on the "private" > > keyword. As I mentioned in the discussion, I find the keyword > > problematic, in that it looks too similar to "public" and therefore > > makes quickly scanning for public members among private ones, hard. > > > > This kind of thing wasn't so important in a language like C++ or Delphi, > > where class member declarations were separate. However, since C# > > members aren't declared ahead - but defined in place - I feel this is an > > issue in this language. > > > > Consider the following code: > > > > ..snip... > > > > > In my opinion, it is an order of magnitude easier to tell which are the > > public methods in the above. > > > > Whadda ya think? > > I think that regardless of whether or not its a good idea, it's not > enough of a benefit to get into the language. > > There are 2 major roadblocks: > > 1) adding a new keyword to the language is something the designers > are very reluctant to do. by definition, it's a breaking change since > any new keyword you come up with could be used as an identifier by > existing code. > > 2) to keep compatibility with existing code, the language would still > have to support the 'private' keyword. So everyone used to using > private would almost certainly continue using it. > > To overcome these problems, the benefit would have to be clear. > > -- > mikeb
[quoted text, click to view]
C# Learner wrote: <snip> Thank for the replies everyone. I'd be extremely surprised if this change made its way into the language, but it doesn't hurt to post my thoughts and for others to consider them :-) I think mikeb made some good points about why this mightn't be very practical. Roy Fine, I understand this isn't my language to change. I just see this as an unfortunate design mistake, and feel it would benefit users of the language for this to be changed. I think I'll stick to not using the keyword for private members (which I currently do). I have no problem with doing this, and think it makes code clearer than using the keyword, but I still feel that it'd be nice
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |