Convention question

  • Thread starter Thread starter GC
  • Start date Start date
ROTFL


Drebin said:
Why the HECK did Microsoft generate that code and put "private" in there?
Don't they know that we all assume that it's private??

:o) COME ON!! I couldn't resist!!
 
Daniel O'Connell said:
winform design is one area that this is a problem.

Only if you use the designer :)
Jon, to answer your question, the designer has a field in the property grid
called modifiers that lets you change the protection level of controls, its
a very ugly solution, but due to the large number of possible variables
involved, manually generating properties would be a task (i hope VS provides
a better method of this in the future, autogenerating properties perhaps
instead of simply changing access modifiers)

That would indeed be nice.

Personally I don't like using GUI designers for final code - they're
fine to play with, to test a look and feel roughly. I prefer to write
the final code myself though, ending up with what I believe to be more
maintainable, better documented code. That's an argument for another
day though :)
 
Ooo!! I like this one!!!

Jon Skeet said:
private int foo;
private int bar;
private string baz;
public object grumble;
private long somethingElse;

It's so unbelievably clear and concise.. there is just no room for error,
confusion, or looking up the current reference... nice code Jon!! :o)
 
Drebin said:
Why the HECK did Microsoft generate that code and put "private" in there?
Don't they know that we all assume that it's private??

:o) COME ON!! I couldn't resist!!

I thought you might not be able to.

But then again, the designer spells out every single class name
explicitly, too...

The code the designer generates is far from the most readable code in
the world, IMO - just another reason to hand-code GUIs.
 
GC said:
But don't you leave out the private modifier for function
variables?

What exactly do you mean by "function variables"? Do you mean local
variables? If so, bear in mind that local variables *can't* have any
modifiers - they couldn't be accessed outside the method even if they
were "theoretically" public.
 
Probably a very sensible way to do things, the designers do other very
annoying things (adding event handlers instead of overriding methods, screw
up sometimes, doesn't remove declarations of removed controls, the
InitializeComponent() method is really horrid),

Finding time to hand write an entire UI can be troublesome, however, proper
design and you don't even have to manually write most of your IDE, just your
individual controls.
 
Why not use a private variable and a protected property then?

Becasue then the designers of the child class cannot manipulate
the view becasue the designer will not have access to the private
member. The solution is that the designer is broken. MS Should
add a property where you can specify the public.protected getter
then the gen'd code would use the getter instead.

JIM

 
Drebin said:
You're ASSUMING that the people that are going to support your code are as
competent and skilled as you are.

Nope - just skilled enough to understand design principles such as not
using non-private variables, and competent enough to either read the
spec or ask someone else who knows if they're confused by something.

Bear in mind that I'm the youngest and least experienced member of my
company...
And although this is silly, you will get a
bad reputation from other developers because they had a tough time with your
code.

Can't say I've ever had that complaint.
This is probably still personal preference, because I'd look at your
code and think "this thing has bugs just waiting to happen"

And yet you still haven't actually given an example of how it could
lead to a bug...
.. and you'd look
at my code and think "is this guy a rookie? Why is he over-defining
everything, everywhere..".. And we'd both think "what an idiot!". :o)

I wouldn't go that far at all. I'd think "This guy doesn't probably
doesn't know C# very thoroughly" and chat with them about it.
Again, you're taking a very academic approach to all this - have you ever
needed to come in and support another developers app?

Absolutely - and I've had other developers support mine.
I was going to mention that too, are you the kind of person that doesn't set
an initial value to variables??

Not if they're not required. I like my code to mean something.
So if you did this:
string strName;

What does strName equal? Is it null? Is it ""? Or is it not even a real
object, because it hasn't been instantiated???

It's never an object - it's only ever a reference.
Well, this is fine with C# -
because it's stern enough to not let you get with using this variable until
it's initialized, but there are lots of languages that let you do that...

Actually, it's null for a member/static variable. Only local variables
are unusable without explicit initialization.

Mind you, there *is* a difference for static variables between

static string name = null;
and
static string name;

in terms of timing. (And yes, I've written code which depends on the
difference; I'd always comment that explicitly though, as it's beyond
the level of thoroughness with which I'd expect someone to know
C#/.NET.)
Absolutely.. and if you've ever done anything critical in C++, you must've
run across the situation where you need to zero out memory, because you
don't know what's in there and it actually makes your app blow up if you
don't!! These practices are in place, because of situations that have
existed for many years.. just because C# takes care of the core problems,
doesn't mean they are now bad ideas..

Yes it does - taking idioms from one language to another is a *really*
bad idea. You end up with code which is neither one thing nor the
other. I made a *very* conscious effort when I started learning C# that
I would try to ignore the Java idioms I'd learned as far as possible,
and learn the preferred C# way of doing things.

Some of the worst Java code I've seen has come from C++ developers
trying to speak Java with a C++ accent.
No, if they change the spec - I will know IMMEDIATELY what doesn't work - at
next compile-time or run-time.. because I was explicit, any variance between
the spec and my code will come to a head immediately..

You can't be explicit about everything though. At least I'm aware of
the assumptions I've been making.
You're just being ridiculous now. :o)

Just giving an example of an assumption you've made... it's an extreme
example, but I'm just showing that you fundamentally *can't* live
without assuming that the spec is accurate.
This is the sentence that pushes me into the "agree to disagree" position.
This isn't even rational to me. How can someone who isn't even logical -
become a developer!!!

I've given a clear example of why I believe it adds to readability - it
highlights "strange" code where you specifically *are* adding a
modifier, which is a very rare event.

Why do you think that highlighting is a bad thing?

Or are you in the camp which considers protected and maybe even public
writable variables to be fine?
lol - the whole POINT of this, is I constantly find some code and it wil
have something like this:

X509Certificate objCert = new X509Certificate();

and the source didn't include thier "using ...;" statements.. and I have to
go look it up, like a jackass..

Why does learning something make you a jackass? Does it take a
significant amount of time to hover over a variable name?

Mind you, the first thing I'd worry about in the code above is the
Hungarian notation, which gets in the way without being useful in the
slightest. Same with "strName" earlier.
especially while I'm in a learning phase
with C#, this is the most annoying thing I've come up with.. If I declare
the first instance, then you can get what the correct namespace and
immediately know what you need to add for a "using ...;" statement..

I believe it's quicker to hover over a type name which happens to be in
the code you're looking at than it is to scroll to the top of the class
and then find the first instance.
John, I don't know how to break this to you - but I feel we will never see
eye-to-eye on this.. I only hope we never have to work on a project
together.... (sigh)... :o) and I'll let you have the last word...

I agree - we'll have to disagree on this.
 
I agree here.. although I have my thoughts on how it should be done..
consistency is more important than personal preference...

james said:
Rock climbing ! :)

No, I guess I wouldn't care as long as the code functioned as it should.
I would continue to do it my way though

JIM


code
?
 
Drebin said:
Ooo!! I like this one!!!

I take it you've missed or ignored the point then?
It's so unbelievably clear and concise.. there is just no room for error,
confusion, or looking up the current reference... nice code Jon!! :o)

Um, note that that's the version with private in.

Obviously in real life everything would be documented - although
possibly not initialised.

The point about the "public" not standing out in the above compared
with the version without the private seems to have gone uncommented on
though - do you actually disagree with it?
 
I REALLY do.. another aspect of this, is that with every line of my code, if
I see:

private string strCrap = "";

With only seeing that SINGLE line, I know it's a string, it's private to the
class (I'm not in a function) and it's initialized to "". And for me, if I
see:

string strCrap;

I need to take a look around to see my context (am I in a function? Is this
a class member?).. and where does this thing get initialized - oh probably
in main().. or maybe in window_load?? If you wrote that code - you'd ASSUME
I would know these things, versus my way - where I KNOW you know them..
PLUS - it tells me my context right away. If I don't see an indentifier, I
KNOW it's a local variable... Why do you want to FORCE me to make these
assumptions!! You wrote the code - you TELL me what you meant!!! I've got
better things to do than sitting around twirling my hair staring at the sky
wondering "Hmmmm... I wonder what he was thinking when he wrote this? Oh! I
wonder if I'll EVER figure out where this variable is initialized..."


So yes, there is no clearer way to say it - I would MUCH prefer bulkier code
that is explicit - over code that is lighter, but makes assumptions and
makes the developer make assumptions..
 
I like it!! I'm going to ask to be switched to work with Chad on new
projects!! :o)


Chad Myers said:
I guess I'm all about making the code as
self-documented as possible.

#region Private Members
private int foo;
private int bar;
private int baz;
#endregion

#region Properties
public int Foo
{
get...
set...
}

public int Bar...
#endregion

#region Protected Methods
protected virtual void DoSomething()
{
...
}
#endregion

#region Public Methods
public void DoThisOrThat()
{
...
}
#endregion

Just add code and comments

-c
 
Drebin said:
I like it!! I'm going to ask to be switched to work with Chad on new
projects!! :o)

Certainly using regions like this is a good idea - I'm more than happy
with that. I still don't see any reason to use the private modifier
though.
 
Drebin said:
(throwing papers in the air) You're out of control! Are you REALLY like this
all the time?

Feel free to read my previous posts and make up your own mind.

See
http://groups.google.com/groups?
as_ugroup=microsoft.public.dotnet.languages.csharp&as_uauthors=skeet%
40pobox.com

(http://tinyurl.com/lekp for short)
First, I can't give an example of a bug because most bugs are oversights.
And if I type them out, you just predictably respond with "Oh! just do this
and that" - obviously.

Not at all - I've given an example of how you can have a bug hiding in
your way of doing things, for instance, which would be more obvious in
my way of doing things. Why can't you at least do that?
I'm not saying your techniques are going to cause a problem that you know
about - I'm *gauranteeing*, that they will cause a problem that you are not
thinking of, and it will probably not come up until some takes over your
code and makes an assumption.

You're *guaranteeing* it? But without being able to give an example of
how it might actually happen?
I write ROCK-SOLID code, because you CAN'T make an assumption - even if you
wanted to.

And yet I've already given you an example of an assumption you make -
namely about keywords. Yes, that example would show up as a compiler
error if it broke, but are you seriously suggesting that *every*
assumption you make (knowingly or unknowingly) acts like that?

Let me give you an example. Earlier in a different thread you posted:

<quote>
And to answer your question, I believe a refernce is -slightly- faster,
because it doesn't have to make a copy of the object...
</quote>

That strongly suggests that you don't understand reference types - or
that you're poor at communicating, as only value types are copied when
passed by value, and "object" usually refers to instances of reference
types. (Reference type objects are never passed at all, only the
reference is copied, not the object.)

If it's the former, then all kinds of bits of your code aren't working
as you think they are. If it's the latter, then that hardly bodes well
for the documentation of your code.
So the code, good or bad, works *exactly* as I intended it -
every line.

My word, that's an arrogant statement. No bugs whatsoever? I can't
remember *ever* hearing a programmer claim that before.
If one of my hard-coded extra tidbits breaks because of a new
compiler, etc - then I know right away. There is no alternative. This is how
it HAS to be.

So much for "we'll agree to disagree" then...
In all seriousness Jon, you really are shooting yourself in the foot. You're
trying to be all "hardcore" with as few lines as possible and "if no one
gets my art, then f*&$ 'em! I'm expressing myself!!"

I'm not suggesting writing as few lines as possible. I'm suggesting
making everything *mean* something. I'm a big fan of documentation, and
readable code - I just happen to disagree on what makes code readable.
- and that's all well
and good, but for you to make any sort of living in the real world, you
can't think like that.

That's funny - I've been making a living doing it for my whole
professional career, and no-one's ever complained about my code being
unreadable or hard to understand.
It's amazing, even in a huge town like Los Angeles
(where I lived for quite a while) - you'd be AMAZED at how word spreads
about people.

I'm sure if you write completely "ROCK-SOLID" code as well as you're
claiming, with not a single line working in a way in which you didn't
intend, word does indeed spread very quickly, given that it makes you
unique amongst programmers.
The IT market is a REALLY small one, even in a big town.. and
I'm telling you now, that what you're describing - is asinine. That's not
opinion, it's just the way it is

Good grief - this just gets worse and worse...
- and you don't have to believe me - but
just think about it. Think about if you walked into a new job and were
sitting down with a 10,000 line app - would you rather go through bulky code
that's a pain.. or 3000 lines, which is easier on the eyes - but you have to
spend 5x as much time tracking things down.

Funny how you've extrapolated my position hugely - making vast
assumptions in a thread where you're explicitly saying how bad
assumptions are.

Could I ask how much of my actual code you've read? When you've read
even 1000 lines of my production code, you'll be in a position to
comment. Until then, you're really not.
I'm telling you - it's just the
way of the world, it's a shame you're so stubborn and proud

You claim that *I'm* proud in the same post that you claim that every
line of code you write works exactly as you intended it? How amusing.
- over a not-so-good idea... you only have one professional reputation
and once it's bad, there is no recovering from that...

I really don't think I'm getting a bad reputation...
And I'm not even going to read any more posts in this thread - this has
turned out to be quite frustrating.....

You certainly seem to be quite tense.
 
I use the private keyword because the default access is subject to a set of
rules (Types default to internal unless they're a class/struct member when
they default to private, method is of course public in interface, defaults
to private as a class member, etc), also so when I use Java I don't start
creating lots of default-access fields.
But I don't see the problem with Jon's preference - anyone who is under the
misconception a class member defaults to other than private access isn't
going to be able to do much with that misconception. I think (could be
wrong) that the default access rules amount to use the most restrictive
access possible, and where only one access modifier is possible, don't allow
one to be specified - which is very simple to understand, if true. This
latter means you have to understand the defaults anyway. Is the private
keyword actually required anywhere in this or future versions of C#?
 
Hi Chad,

Regions. Yes, I like them for that purpose too. I also use a lot
of horizontal separators (=====).

Regards,
Fergus
 
Hi Jon,

|| Feel free to read my yada, yada
|| Blah, blah
|| Argue, argue
|| Yada, yada
|| Justify, justify
|| Blah, blah
|| You certainly seem to be quite tense.
|| Jon Skeet

This one's an example of what could be labelled blinkered
stubborness, I'm afraid. (Haven't I seen that in you in another thread
somewhere?).

Drebin essentially only said one thing in that last post - "My
brain hurts - Time-out".

There was a clue in the opening remark - (throwing papers in the
air) ...

That should have told you that what was to follow was going to be
emotion, not reason. But you didn't notice until the end. And, even
then, I imagine that your last remark was a satisfied dig.

No, you had to hammer away. Felt compelled, even. Answering points
which, due to the aforementioned emotion, were a waste of time
answering. Because given a decent night's sleep, Drebin would have
come back and expressed that post in an entirely more succinct way.

Ask yourself this. Did you focus on the joy of proving yourself
right? Did you recognise the futility of answering back? Because
anyone in an argument against emotion is going to win every time if
they use logic.

Emotional arguments are a totally different ball-game. They
require a totally different response. Preferable short.

Acknowledge the emotion:
"Wow, Drebin, you're pretty steamed up there, :-(. "
Show understanding that directs away from being personal:
"This is a hot debate isn't it."
Show compassion:
"Let's call it a day and pick up the thread tomorrow."
You could even show a bit of human weakness:
"I feel pretty bushed too".

I'm going to end by saying that in the short time I've been a
newsgroupie I've come to respect you a lot. You know your stuff. I
look out for your posts because there's a good chance that I'll learn
something - sometimes a new slant on something, sometimes a whole
nugget. You're worth following.

But I didn't read your last post because that was simply hitting a
man while he was walking out of the ring. You missed the opportunity
to put your arms round his shoulders and walk out with him,.saying
"well, wasn't <that> something!"

You may well feel that I'm getting at you. I'd be surprised if
your face hasn't flushed a fair bit while reading this. But that
discomfort will go away. Hopefully to be replaced by some
understanding of how you push your fellows away with your unremitting
<insert suitable word - your choice>.

These are your lesson notes. Use or throw them away.

However you see me at this moment, I do wish you the best.
Fergus
 
Fergus,

Actually I used to write code like that for many years
but since I started C# I have gone over to the typical
single spaced way. This one is deffinately personal pref
and I would say as long as your project is consistant
no problem. It would suck though if you have classes
written by someone else who used a different format.

JIM
 
Drebin essentially only said one thing in that last post - "My
brain hurts - Time-out".

No, he didn't. He made completely unjustified personal attacks, and I'm
afraid I wasn't going to let that go without defending myself to some
extent. To be honest, my own post was made in a reasonably high state
of emotion too. He'd called my coding style asinine, for goodness' sake
- how would *you* have felt? (Seriously, read his post again and
imagine it being applied to you, fairly late at night - would you
definitely have resisted temptation?)

So yes, there was definitely stubbornness and pride displayed in my
post - because I *am* generally proud of my code. Not proud enough to
claim that my code is always "rock-solid", but proud enough to defend
myself at half past ten at night when someone claims it's asinine.
There was a clue in the opening remark - (throwing papers in the
air) ...

He made similar remarks earlier in the thread though - are you
suggesting that whenever someone displays some emotion rather than
logic, they should never be contradicted even if they're spouting
nonsense?

Maybe it would have been better not to have made my last post - but I
feel it would also have been better if he hadn't made the post it was
in response to, either. I'm far from perfect - sometimes I can ride
taunts, other times I'll hit back. Claiming that I'm ruining my
professional reputation by my coding style, and that it's asinine is a
good way of riling me up though - and I hope that's fairly
understandable.
However you see me at this moment, I do wish you the best.

Likewise. I hope I don't disappoint you too much in the future, but
there definitely *will* be more posts like this, I'm afraid. There'll
also be threads where I doggedly (stubbornly) stick to a line such as
ASCII *not* being 8-bit, and objects *not* being passed by reference
etc where I think it's important to make the distinction. That's a
somewhat different kind of stubbornness though. Just to warn you in
advance :)
 
Fergus,

Great posts, well said! First, I don't have nearly as much respect for Jon
as you, and I've been watching here a LONG time and have been participating
again for the past few weeks. I think he generally knows his stuff, but he
has the personality where I get the feeling he will bullsh** someone if he
doesn't know the answer, because he's too proud to admit he doesn't know.
So - I take everything he says, with a grain of salt.

My original point was a simple one, from my experience (from several jobs,
hundreds of projects, dozens of developers and a handful of languages) - his
entire approach and especially attitude, is to his own undoing. A developer
has exactly TWO worths: his/her technical ability and thier ability to
communicate. Lacking in either one will determine the quality of your job,
your pay and how others see you. And I'm also saying, the kinds of
assumptions and shortcuts he takes, speaks novels to his competence. If I
were going over his code, I would be tearing it apart. Because things he's
calling 'relying on the spec' - are shortcuts that add confusion and
ambiguity, and cut down on the clarity. And when I'm trying to fix code, the
LAST thing I want - is ambiguity or guessing. So even if people don't agree
with me, I hope at the very least - THAT concept gets through.

"Write every line of code, like someone else will have to support it. AND it
has your name on it."

What would *I* do if someone challenged my viewpoints? Well - it happens ALL
the time, I explain why I've come to the conclusion I have - and ask the
other person why they believe what they do. Afterwards, I weigh what the
other person said and decide if I will adopt or incorporate thier idea into
my practice. I don't think it's life and death, nor do I really care. Jon
has equally "attacked" my style - and I don't really care, my whole intent
is to tell him why his method is not really the way to go.

Lastly, I had to chuckle - when I read your post chastizing Jon, I was
thinking "Oh man, Jon is going to go after HIM now".. and sure enough, he
did.. Jon is like the barking dog next dog who has to bark at anyone that
walks by the fence. In the long run, it's a waste of time to try to get him
to shut up - because he can bark all day... I haven't had to deal with
someone so angry in a long time, I think I forgot how! So I do regret
getting caught up in this thread.

Bottom line, this thread did get out of control... perhaps we can all get to
more productive and problem-solving posts.. :o) I offer Jon a truce, for
immediately after he predictably responds to this post (well, he has to
defend himself - doesn't he?). :o)

-Drebin
 
Back
Top