Miguel de Icaza's blog - Latest Comments in Public Service Announcement - Miguel de Icaza

Re: Public Service Announcement - Miguel de Icaza

Russ C. — Tue, 07 Oct 2008 06:09:22 -0000

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 :)

Re: Public Service Announcement - Miguel de Icaza

Kannan Goundan — Tue, 30 Sep 2008 18:25:18 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Foxfire — Tue, 30 Sep 2008 02:59:23 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Steve — Mon, 29 Sep 2008 23:42:38 -0000

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

I'll stick with Ruby.

Re: Public Service Announcement - Miguel de Icaza

migueldeicaza — Mon, 29 Sep 2008 16:59:08 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Foxfire — Mon, 29 Sep 2008 16:38:13 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Marek Safar — Mon, 29 Sep 2008 13:28:19 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Foxfire — Mon, 29 Sep 2008 11:59:35 -0000

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

Re: Public Service Announcement - Miguel de Icaza

migueldeicaza — Mon, 29 Sep 2008 10:54:40 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Ed Ropple — Mon, 29 Sep 2008 10:37:07 -0000

>> 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).

Re: Public Service Announcement - Miguel de Icaza

Andrey Shchekin — Mon, 29 Sep 2008 10:08:52 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Anonymous — Mon, 29 Sep 2008 08:09:41 -0000

"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()".

Re: Public Service Announcement - Miguel de Icaza

Ted — Mon, 29 Sep 2008 07:57:12 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

Marek Safar — Mon, 29 Sep 2008 06:50:11 -0000

>> 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.

Re: Public Service Announcement - Miguel de Icaza

Marek Safar — Mon, 29 Sep 2008 05:53:06 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

commenter — Mon, 29 Sep 2008 05:48:59 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

commenter — Mon, 29 Sep 2008 05:44:50 -0000

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

Some people might not know that.

Re: Public Service Announcement - Miguel de Icaza

commenter — Mon, 29 Sep 2008 05:43:26 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

commenter — Mon, 29 Sep 2008 05:38:44 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

commenter — Mon, 29 Sep 2008 05:33:46 -0000

Homogenous?

Re: Public Service Announcement - Miguel de Icaza

commenter — Mon, 29 Sep 2008 05:31:35 -0000

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*/
{ ... }
}

Re: Public Service Announcement - Miguel de Icaza

tamberg — Mon, 29 Sep 2008 04:27:38 -0000

A simple table explaining this and other (default) modifiers:
http://blogs.oberon.ch/tamb...

Regards,
tamberg

Re: Public Service Announcement - Miguel de Icaza

rovsen — Mon, 29 Sep 2008 04:08:54 -0000

"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.

Re: Public Service Announcement - Miguel de Icaza

Anthony — Mon, 29 Sep 2008 03:23:38 -0000

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.

Re: Public Service Announcement - Miguel de Icaza

RichB — Mon, 29 Sep 2008 02:02:40 -0000

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.