DISQUS

jpobst · 1 year ago

I guess it's just personal style. I find the "private" makes things explicit and is therefore more readable. :)

Paul · 1 year ago

There's something to be said for those that take the time to explicitly declare things as public/private/etc... just because you CAN leave it out doesn't mean that you SHOULD.

I think it makes the code just as easy to read, or easier to read... but certainly not harder to read.

Takuan · 1 year ago

As many times as I've had arguments about this with coworkers and peers, and finally had to prove to them that the default was private, I guess I can't agree with you. On my dev team, we will deal with the 'noise' in favor of removing any ambiguity.

Anon · 1 year ago

This is pure laziness Miguel. And not the good kind of laziness that a lot of programmers adhere to. It's more symmetric and less ambiguous to declare these variables private, which makes the code easier to read.

Do you also restrict your development team to variable names with a maximum of 6 characters too? Come on, this isn't 1960.

Lluis. · 1 year ago

Programmers who don't care to find out what's the default accessibility for classes and members, and always rely on others to tell them, those are real lazy ones. If c# has a default accessibility that's for a reason.

The Fiddler · 1 year ago

Ah, absolutely agree. Default is private, writing it everywhere just adds noise. Less is more (but too little is bad).

marcel · 1 year ago

I must agree with jpobst. I find it more readable if the access modifier is explicitly stated.

Joe Shaw · 1 year ago

I disagree. I think the explicit nature makes things easier to read, especially for someone who is not an expert at C#. I use "private" everywhere.

I also use "this" even when unnecessary, because it makes it a lot easier to see what variables are local and which are at the instance level. For example, "this.some_variable = 5;" or "this.do_something();"

Anonymous · 1 year ago

"this.some_variable" makes sense for instance variables to differentiate them from local variables, but why "this.do_something()"? For static methods I use "ClassName.static_method()".

JuanCri · 1 year ago

I don't agree. I use the keywords "private" and "this", because it's not always evident.

Adron · 1 year ago

this and private should be evident though. If not, something is amiss...

migueldeicaza · 1 year ago

Hello,

Well, I believe in succinct code. I am not a fan of the baroque style of coding. Just because you can add decorations, does not mean you should.

Would you rather use type inference to call a method, or would you rather type all the types, even when the compiler can figure that out for you?

Would you use explicit casting, just because it would show the real value, even if the compiler does the casting implicitly?

MultiplyMatrix ((double) 1, 2.3);

Would you use:

var x = new List<string> ();

Or would you rather write:

List<string> x = new List<string>();

Implicit is good, leverage it.

Ed Ropple · 1 year ago

For the casting example, that's a little disingenuous because "1" is still a number; the cast follows, so to speak. I'd be more likely to use 1.0, though, than just "1".

For the "var x" example, I always write

List<string> x = new List<string>();

Well, no, that's not quite true--because I have a personal quirk of always using the System.* names for the various base types, so I'd use List<String>, myself.

What you call "baroque", I call "specific". Within reason, I am almost always for anything that enhances specificity. Yes, "private void Blah()" is an extra word. But the symmetry with "public void OtherBlah()" gives it semantic value to me and, I suspect, a lot of programmers.

Verbosity makes it easier to deal with your code later. "Succinct" code is one of the reasons I steer well clear of C and C++. Bringing those bad habits to C# feels kind of painful.

migueldeicaza · 1 year ago

You seem confused.

Succinct is what makes Ruby a joy to write web apps, the mandatory idiocy what makes using Java a pain and self inflicted pain what makes C# less than pleasant.

You guys are arguing as if they were paying you by the byte. "private" is the new pay-by-line of code.

Ed Ropple · 1 year ago

Sorry, sir, but I'm not confused. What you call "mandatory idiocy," I call more readable code. Structure is good, IMO, for the simple reason that a lot of programmers just aren't very good and it makes dealing with their work a lot easier.

I also don't like Ruby; I find it unpleasant, oddly terse, and uncomfortable to use. Different strokes for different folks.

commenter · 1 year ago

With knowledge of C#, we know that that cast isn't required. With knowledge of C#, we know that 'private' isn't required. Both make something explicit but are unnecessary for the compiler.

So, you do indeed appear to be confused.

Ted · 1 year ago

100% disagree with your initial blog.

The less context switches you have to make while reading code, the better. Especially when bouncing between languages which may not have the same default access. To me, it is a context switch if I have to stop and recall what the default access is and then continue reading.

var needs to be used in moderation. There are many times where it is extremely inappropriate to use, even though you can.

I am starting to take a shine to Ruby but sometimes I get creepy Perl vibes from some of the things you can abuse in the language. Monkey patching is the devil itself.

Marek Safar · 1 year ago

>> For the casting example, that's a little disingenuous because "1" is still a number; the cast follows, so to speak. I'd be more likely to use 1.0, though, than just "1".

What is 1.0 for you double, float, or decimal ? I think you rely on C# compiler to decide.

>>For the "var x" example, I always write

>>List<string> x = new List<string>();

>>Well, no, that's not quite true--because I have a personal quirk of always using the System.* names for the various base types, so I'd use List<String>, myself.

Wow, that's pretty bad. This makes your code very hard to read and you rely heavily on compiler to decide what is String because it's context dependent name.

Consider this

using System;
using System.Collections.Generic;

namespace N
{
class String {}

class Test
{
public static void Main ()
{
var s = new List<string> (); // System.String
var s2 = new List<String> (); // N.String
}
}
}

You decided for option `s2', and it takes me hard time to check your source code to be sure what String is.

Ed Ropple · 1 year ago

>> What is 1.0 for you double, float, or decimal ? I think you rely on C# compiler to decide.

You say that like that matters. A programmer won't particularly care if it's a double or a float or a decimal--just that it's not an integer.

>> You decided for option `s2', and it takes me hard time to check your source code to be sure what String is.

Nonsense. "int" is C#, "Integer" is VB, but Int32 is unambiguous across all .NET languages (and more descriptive, too).

migueldeicaza · 1 year ago

Incorrect. "Int32" depends on the context, as Marek just pointed out "String" in that case refers to a different data type than System.String.

Marek knows a thing or two about the C# language, considering that he implemented most of C# 3, and about 40% of our compiler.

AlbertoP · 1 year ago

Adding "private" is not baroque, I think. It just makes code well clear, no matter who reads it. And in an open source world, having readable code is extremely important.

Your example about MultiplyMatrix is something that someone coding numerical and scientific codes like me would consider a mistake. You rely on the compiler, and it is not good. It is common practice to _always_ add at least the "dot" when operations are done among double. So, if I agree with you about explicit casting, your syntax should be:

MultiplyMatrix (1.0, 2.3);

It doesn't really cost anything, and it adds information.

Implicit is _wrong_ by definition, and should _not_ be leveraged. All serious programming books say so, at least. :-)

Andrey Shchekin · 1 year ago

I like var, but I do not like omitting private.

I think it is because var is *about* the variable declaration I am performing, but private is a modifier which works in entirely different space than the declaration itself. Additional reason is that omitting access modifiers does different things in different contexts (think namespace-level classes), so I always have to consider context when reading code.

I also use 'this' for all references.

David W. · 1 year ago

“Understanding the language I'm paid to work in is hard, let's go shopping!”
— Programmer Barbie

More seriously, if you find it confusing to omit "private" from a declaration, then you do not understand the basic philosophy of C#, never mind the specifics of the language. I would not look favourably on a co-worker or underling complaining about this.

Ed Ropple · 1 year ago

I don't find it confusing, but why remove specificity? The declaration is already on its own line (well, according to the Microsoft code standards, which I use; I find Mono's pretty painful, with all C-isms), it's not like it's a "waste of space" or anything like that.

Wherever possible, I write my code to be as readable as possible to as large an audience as possible. Specificity and verbosity *are* good; one just has to look at the morass of nigh-unreadable, super-dense C code out there to see why.

Nicholas Blumhardt · 1 year ago

Yes!

Kamujin · 1 year ago

Sorry, using or omitting the word "private" from a function declaration has very little correlation with ones ability to write good code.

Its a matter of preference which is why it is optional. Learn to adapt.

djp · 1 year ago

tell that to intellisense

The Florest · 1 year ago

I strongly disagree!! ... It suggestion requires whomever is reading your code to know that C# defaults to private. Adding 'private' adds very little clutter, makes things clearer and helps folks new or unfamiliar with C#. It's these sorts of things that drive me crazy when trying to learn another language.

migueldeicaza · 1 year ago

And what tragedy will unravel if the user fails to know this when reading the code.

Lets assume that the user does not know it, so he sees that variable, and when he *tries* to access it, he will get a compiler error "The variable you are trying to access is private". Big deal.

AlbertoP · 1 year ago

Well, usually it is considered a good habit to make explicit to avoid ambiguity and eventually not to have to change the code if the compiler or the language change.
Implicit statements are considered "wrong" because they leave the choice to the compiler. It sounds "old school" maybe, but it is the safe way. :-)

commenter · 1 year ago

Do you realise how absurd it is to guard against the possibility that Anders Hjelsberg might decide to change the default access on members in C#? :-)

If anyone is 'programming defensively' at that level of paranoia (agh - even the compiler writer is against me!) , then their code is going to be incomprehensible.

Rick Brewster · 1 year ago

I definitely prefer to mark everything as public, protected, private, or internal. When I see things without the 'private,' it just seems to make the author look a little lazy -- I find it to be *more* readable when the access level is always there.

Zenwalker · 1 year ago

Its always good to specify a private access modifier to just increase the redability, since many peeps from other programming world often find difficult in reading a variable name or what ever without a modifier and they keep getting confused whether in this lang its private or some thing as default.

So i always specify it to make things clear and increase the ease of redabilty. I dont think that would add any over head for compilation/run time process?

If so, let me know.

Daniel Ferreira Monteiro Alves · 1 year ago

Well, this story will go far...

I think that a programmer must know about the language that he using, and I already had a discussion with a guy that works with me about it... I disagree with the idea that you must write four lines of code because someone could not read that code, because he is not so good as you are...

I already coded without the private, but in this case, I like to write the code on the same format, declare methods or variables on the same way, so I put it... but I think that is just an option, like others here...

rovsen · 1 year ago

"someone could not read that code, because he is not so good as we are" or "someone could not read that code, because he is much better than we are" ?
We are not living on Saturn. On Earth no one's knowledge/understanding is same/equal to anyone else's. Software parameters are not static. Everything is open to change. Software requirements, design, implementation and developers themselves too. Different developers may try to read the code. And non of them are equal in anyway. So there must be some mid-way to make things/changes/readability be easier. I believe this mid-point is in somewhere private is coded explicitly.
If 4 lines of code is not enough 10/20/30 must be written, just to make readability/change easier.

RichB · 1 year ago

Some analogies:
Do you use {} in an if block even when the block only contains a single statement?
Do you use operator precedence parenthesis even when your expressions do not need parenthesis?
In JavaScript, do you terminate lines with a semicolon;?

Programmers do all of these, because the risk of mistyping and getting it wrong produces hard-to-find bugs. So in the long-run, it is simpler to state the obvious. Adding private onto members and internal onto types, even though they're the default is just keeping the code homogenous.

commenter · 1 year ago

Homogenous?

commenter · 1 year ago

That wasn't a spelling flame btw :)
I just wondered what you meant. Omitting 'private' consistently would be homogeneous too... I suppose. I don't think the word is applicable in either case.

Anthony · 1 year ago

Totally disagree. While I wouldn't drop dead if working somewhere whose convention was to omit the private, your bringing Ruby into the discussion along with your numeric code example is a great example of how relying on implicit defaults can be dangerous (i.e., giving Ruby an integer when you meant it as a double runs a real risk of losing precision). If one is moving between languages on a regular basis, such as Ruby and C#, relying on default access modifiers and implicit casts is a recipe for trouble. If it's a feature unique to C#, then go ahead and rely on the defaults, but if it's a nearly universally available feature in related languages, and those languages have varying defaults, then being explicit trumps brevity.

tamberg · 1 year ago

A simple table explaining this and other (default) modifiers:
http://blogs.oberon.ch/tamberg/2007-10-30/under...

Regards,
tamberg

Steve · 1 year ago

LOL if you mean that as a joke you have my full respect.

I'll stick with Ruby.

commenter · 1 year ago

Yes. What Miguel said.

Adding 'private' is kind of like putting in an inline comment that states the obvious, since it has zero effect on what gets compiled.

NB: this assumes your code is being maintained by C# programmers (ie - people who know C#)

/*reference semantics*/ class Foo
{
string /*is return type*/ Bar(int a, int b, int c) /*method has 3 parameters*/
{ ... }
}

commenter · 1 year ago

Sorry. I forgot to put another comment against class Foo: /*this class is garbage collected*/

Some people might not know that.

Marek Safar · 1 year ago

When reading C# code which is peppered by private declarations, useless initializations, etc. it just means that the code was written by C# beginner (no offense) which itself has a value. However, it does not add any real value to the code readability or maintainability. Everything what is over specified just distract the reader and makes the code less readable, understandable (is private temporary hack or not).

Arguments like "Implicit statements are considered "wrong" because they leave the choice to the compiler", shows just misunderstanding the problem. Why specify just access modifiers? Do you explicitly state everything where compiler could fall back to C# standard behaviour? Do you declare all your namespace types public, or internal ? Do you avoid type inference? Do you specify best conversion? Do you fully classify types when they are referenced? The list could go on and on.

Also, there is maybe better example than Miguel showed.

Consider this code:

public partial class C
{
partial void Foo ();
}

public partial class C
{
partial void Foo ()
{
}
}

I like consistency and this sums the problem nicely, if you understand C# you know that the method is a private. If you try to explicitly override method accessibility you got a compiler error for C# specific reasons.

Foxfire · 1 year ago

Sorry if I differ, but If somebody omits private declarations then he is likely a software-engineering beginner. If saves virtually nothing (2 keypresses with an IDE) and creates less readable, less consistent and insymmetric code:

public int DoSomething ();
private int DoPublic ();
public void DoNothing ();

public int DoSomething ();
int DoPublic ();
public void DoNothing ();

Why specify just access modifiers?
Well because your HAVE to specify them in 70% of the cases anyways. It just makes no sense to be inconsistent, insymmetrical and less readable just to save a few characters in the rest 30%. Or do you write every program in one single file in one single line? Just because files and linebreaks have no meaning?
Why not just standardize on what everybody does:
Access-Modifier, Special-Modifiers, Return, Methodname

Marek Safar · 1 year ago

Hi,

To clarify, I didn't say software-engineering beginner, that's really something else.

Just think of partial methods (already showed in my previous post), explicit interface implementations, top level types.

My point was that stating obvious you decrease readability and it does not matter if your code is 20 lines symmetrical or not.

Foxfire · 1 year ago

All the points you mention are imho STRONGLY supporting the use of explicit private declaration.
explicit interface implementations 1)
If you do not declare private methods you cannot directly distinguish between a private method an an explicit interface implementations because in code they might look completely identical although they ARE semantically different. If you use explicit private declaration for private methods and none for explicit interface implementations you can easily spot the difference. Greatly enhances readability.
partial types 2)
Same thing as in 1) is also true for partial types.
top level types 3)
Well a top-level type without modifier is obviously NOT PRIVATE (see original post). So you cannot just assume that always when you do not use the modifier it means "private". Just writing what you means cleans up things (and in fact would result in a compiler error if you do something wrong, although that would obviously be a beginners problem. But nevertheless it doesn't harm anything).

>My point was that stating obvious you decrease readability and it does not matter if your code is 20 lines symmetrical or not.
Sorry, but imho it DECREASES readability GREATLY if you omit private modifiers. I have ABSOLUTELY no idea how it should (obviously???) enhance readibility when not writing them.
I write vocals in written english, too altough you could read everything if you omit them. But just making something shorter does not make something more readable.

migueldeicaza · 1 year ago

You do not understand the rules for Explicit Interface Implementations.

Private members can not just become an explicit private implementation, you *always* need to include the type they are implementing explicitly. If they are just private, they do not form part of the interface.

Foxfire · 1 year ago

I do understand them. But the point is valid: You need to look at the entire declaration to find that out while otherwise you will see the fact much faster.

Also another (more common) example (nearly) straight from Mono Code:

bool _viewState;
bool _viewStateMac;
string _errorPage;
bool is_validated;
bool _smartNavigation;
int _transactionMode;
internal int mode;
ValidatorCollection _validators;
bool renderingForm;
string _savedViewState;
ArrayList _requiresPostBack;
ArrayList _requiresPostBackCopy;
ArrayList requiresPostDataChanged;
IPostBackEventHandler requiresRaiseEvent;
IPostBackEventHandler formPostedRequiresRaiseEvent;
NameValueCollection secondPostData;
bool requiresPostBackScript;
bool postBackScriptRendered;

private bool _viewState;
private bool _viewStateMac;
private string _errorPage;
private bool is_validated;
private bool _smartNavigation;
private int _transactionMode;
internal int mode;
private ValidatorCollection _validators;
private bool renderingForm;
private string _savedViewState;
private ArrayList _requiresPostBack;
private ArrayList _requiresPostBackCopy;
private ArrayList requiresPostDataChanged;
private IPostBackEventHandler requiresRaiseEvent;
private IPostBackEventHandler formPostedRequiresRaiseEvent;
private NameValueCollection secondPostData;
private bool requiresPostBackScript;
private bool postBackScriptRendered;

In the second example you imho immediatelly see that one of the fields has a different modifier. In the first you only see that if you actually look line-by-line.

Russ C. · 1 year ago

You raise a fair point here, but I'd rather group my modifiers by Access type.
My personal preference is in order of accessibility, private, protected, internal, public.

Actually, I'd prefer to have a C++ like keyword where you could just write

private:
bool _viewState;
bool _viewStateMac;

internal:
int mode;


Maybe one day :)

Kannan Goundan · 1 year ago

Personally, I agree with Mr. Mono. Omitting "private" makes the code easier to read because it reduces the amount of noise. I don't have an airtight argument supporting my position, but I did see a bunch of bad arguments against it and would like to address those.

Some people presupposed that symmetry/explicitness are always good and omitting the modifier reduces symmetry/explicitness. I agree that leaving out the modifier is somewhat less symmetric/explicit (but hey, what about looking at it as "members are private, but you can optionally use a modifier like 'public' or 'protected' to promote it to a higher visibility"?) If you want to be really pro-symmetry/explicitness, then consider the asymmetry of the "static" modifier. Why not require the modifier "instance" in front of every non-static field?

The analogy to prefixing fields with "this" is weak. Looking at a variable reference "x", it isn't instantly identifiable whether the reference is to a local variable or a field -- you need to look for variables definitions that are in scope. That's why "this.x" helps. Field declarations are a completely local thing -- it's instantly clear what the visibility is. If it's lacking a modifier, it's definitely "private". IDE syntax coloring can help you sort through large blocks of definitions with different access modifiers.

You might say "but my IDE highlights member field accesses differently from local variable accesses." That's great. Now you can quickly see that "x" refers to, for example, a field. But let's say you come around later and add a local variable "x" to the method -- then the variable reference silently changes from referring to the field to referring to the local. Note that I'm not necessarily arguing in favor of using the "this" prefix, I'm just saying that the issue is more complex than the default access level issue.

Finally, I noticed people making a mistake that I see quite often in discussions about syntax. People, please get it into your heads that verbosity doesn't always make things easier to read. Miguel said he didn't like "private" because it "makes your code more difficult to read." Now, whether it is easier to read or not is up for debate. But saying something like "why make your code less readable just to save a few characters of typing" is completely missing the point.