IDesign C# coding std 1.81, topic 3.21

  • Thread starter Thread starter Guest
  • Start date Start date
TT (Tom Tempelaere) <"=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?=" <_N_
0SPA|/\|[email protected]|/\|APS0_N_> said:
Topic 3.21 in
<http://www.idesign.net/idesign/download/IDesign CSharp Coding%2
0Standard.zip> claims the following:

"Release build should contain debug symbols"

I wonder why. Doesn't this make the executable larger, and slower?

It's a shame it doesn't explain things, really.

Mind you, I have to wonder about the usefulness of it when I read:

<quote>
17. Maintain strict indentation
a) Use 3 spaces for indentation
b) Do not use tabs or non-standard indentation like 1, 2 or 4 spaces
</quote>

In what world is 4 spaces *less* standard than 3?

Similarly, separating all member variables from all properties isn't a
good idea, IMO (number 20). If a property is backed by a member in a
simple fashion, it makes sense to declare the two together.

(Still reading the rest...)
 
TT (Tom Tempelaere) <"=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?=" <_N_
0SPA|/\|[email protected]|/\|APS0_N_> said:
Indeed he doesn't explain things enough. A rationale per topic would
come in handy.

Yup - it would also make it easier to argue against specific points.
Personally, I use tabs, and each tab is 2 spaces. I haven't seen
anyone use 3 spaces. I have seen people using tabs with a tab being a
single space charachter. Plain ugly when you decide tab to be 2
spaces later on, because you can't see spaces from tabs when 1 tab ==
1 space.

I think I've seen *one* person use 3 spaces before, but it's hardly
standard. A lot of people use 4 spaces, however.
Perhaps he wishes to avoid code layout changes for people who decide
they do not wish a tab to be 2 spaces, but 3 or 4 spaces instead. I
don't know.

The argument of "tabs vs spaces" is a separate one from how much
indentation to use, of course. Personally I use spaces instead of tabs,
so that everyone will see the code in the same way. However, that's an
argument with lots of good reasons on both sides, and not one I
particularly want to get into here.

I don't even really want to comment on whether 3 is a good number of
spaces to use or not. It was the bizarre way that it implied that 3 was
a standard which stunned me.
 
2.1.4
Every 5th Line should contain an Debug.Assert();

Oh my god!
2.3.5
Mark every Public and Protected method as virtual
Stupid.

2.5.55
Always provide a static constructor when providing static member variables

Why? Providing a static ctor means you will have no beforefieldinit set in
the class which means that on first
access of any field, *all* static fields are initialized. But what if I
require lazy initialisation?
2.5.60
Do not use "this"-reference unless you are invoking a ctor from another
ctor

He must be gone crazy. Some other people say you _always_ have to use this.

After reading this sosaid coding standard I created one rules for writers of
coding standards:

1.1.1
Never declare your personal preferences as official standard if over 50% of
other experts have another opinion.
 
Hi,

I'm 4-indent-space-maniac.
I think that 3 spaces of indent are used to kill using a tab character
that are usually visualised as 8 spaces.
There's no other common number other than 24 factor. So how many of Your
code has more than 7 indents?
Maybe it looks sily... but i don't see any other reason :)

Marcin
 
codymanix said:

Indeed, although I've been arguing about this with someone else in
another place. Seems very odd to me.
Why? Providing a static ctor means you will have no beforefieldinit set in
the class which means that on first
access of any field, *all* static fields are initialized. But what if I
require lazy initialisation?

In fact, having a static constructor will probably end up giving you
lazier access - from what I've seen, the current CLR is likely to call
the type initializer when it first enters a method which uses any part
of the class.

Note that the idea of different static fields being initialized at
different times just isn't going to happen - there's only one type
initializer per type. (You could manually do it, of course, but that's
a different level from the type initialization one.)
ctor

He must be gone crazy. Some other people say you _always_ have to use this.

Indeed. I'm lazier - I say "Use this when you have to" and I use
variable names which mean that on constructors I usually have to.
Elsewhere I rarely end up using "this" - although there are times when
you want to use it for entirely different reasons, of course.
After reading this sosaid coding standard I created one rules for writers of
coding standards:

1.1.1
Never declare your personal preferences as official standard if over 50% of
other experts have another opinion.

:) Of course, it's very difficult to gauge that "50% of other experts".
Writing a "personal standard" seems to be a better bet, really. Maybe I
should have a go at doing that some time...
 
17. Maintain strict indentation
a) Use 3 spaces for indentation
b) Do not use tabs or non-standard indentation like 1, 2 or 4 spaces
</quote>

In what world is 4 spaces *less* standard than 3?

Probably in IDesign's world. I've always approached a coding standards
document as simply a way to make all the code in a particular shop or
project internally consistent. Many decisions have multiple correct choices
and the standards document simply states which correct choice will be used.
It would have been nice if the author had included a preamble to explain the
philosophy and purpose of the document.

Personally the number of spaces people choose for their tabs (as long as it
isn't 1) doesn't drive me nuts nearly as much as old-style ASP programmers
who write code like this:

if b = 1 THEN
' do something
end IF

Unfortunately, that isn't some contrived example. I've actually worked with
code like that (including the variable name 'b' which just happened to be a
global variable).

Colin
 
Hi CodyManix

----- codymanix wrote: ----
2.1.
Every 5th Line should contain an Debug.Assert()

Oh my god

He writes, "On average, ...". His intent is probably to encourage people to use Debug.Assert to check invariants. He should rephrase that suggestion
2.3.
Mark every Public and Protected method as virtua

Stupid

Indeed, I completely agree. IMHO it is a serious flaw in Java that every method is virtual by default. C# designers made the right decision not to make methods virtual by default
2.5.6
Do not use "this"-reference unless you are invoking a ctor from anothe
cto

He must be gone crazy. Some other people say you _always_ have to use this

Agreed, yet I don't think Juval has gone crazy (just check his books, they are good)

After reading this sosaid coding standard I created one rules for writers o
coding standards

1.1.
Never declare your personal preferences as official standard if over 50% o
other experts have another opinion

Juval never said that this is official, it is the IDesign C# coding standard. It reflects his personal opinions, nothing else. Some are good, others are questionable

-
cod

Freeware Tools, Games and Humou
http://www.deutronium.de.vu || http://www.deutronium.t

Tom Tempelaere.
 
Jon said:
[...]
Writing a "personal standard" seems to be a better bet, really. Maybe I
should have a go at doing that some time...

I'd be interested to read it :-)
 
In fact, having a static constructor will probably end up giving you
lazier access - from what I've seen, the current CLR is likely to call
the type initializer when it first enters a method which uses any part
of the class.

Note that the idea of different static fields being initialized at
different times just isn't going to happen - there's only one type
initializer per type.

Now I understand. Beforefieldinit does not mean to initialize only fields
that have been accessed but instead
means nothing other than "The system is allowed to call the class
initializer before the first field of that class is accessed"
this.

Indeed. I'm lazier - I say "Use this when you have to" and I use
variable names which mean that on constructors I usually have to.
Elsewhere I rarely end up using "this" - although there are times when
you want to use it for entirely different reasons, of course.

But he is consistent is his Standard. If one always use m_* to mark member
variables,
using "this" is never neccessary. I very often use "this" because of
intellisense so I do not have to type in the "long descriptive names" :)

But I was always wondering why they doesn't have introduced a symbol instead
of "this". $ or @ or ven # would be great.

class Numba
{
int n;
public void Numba(int n)
{
@n=n;
}
}
 
cody wrote:

But he is consistent is his Standard. If one always use m_* to mark member
variables,
using "this" is never neccessary. I very often use "this" because of
intellisense so I do not have to type in the "long descriptive names" :)

No need :-) In VS.NET or C# Builder, just start typing the name then
press CTRL-SPACE.
But I was always wondering why they doesn't have introduced a symbol instead
of "this". $ or @ or ven # would be great.

<snip>

This would've alienated C++ programmers :P
 
cody said:
Now I understand. Beforefieldinit does not mean to initialize only fields
that have been accessed but instead
means nothing other than "The system is allowed to call the class
initializer before the first field of that class is accessed"

Yes, basically - and also, it *doesn't* have to call the type
initializer *unless* a static field is accessed, even if you call a
static method.
But he is consistent is his Standard. If one always use m_* to mark member
variables, using "this" is never neccessary.

Actually, it can be - if, say, you want to add "this" to a Hashtable.
That was what I meant by the "entirely different reasons".
But I was always wondering why they doesn't have introduced a symbol instead
of "this". $ or @ or ven # would be great.

Bad for readability, IMO.
 
Indeed. I'm lazier - I say "Use this when you have to" and I use
No need :-) In VS.NET or C# Builder, just start typing the name then
press CTRL-SPACE.

Interesting, I didn't know that. This renders the keyword "this" almost
useless..
<snip>

This would've alienated C++ programmers :P

Who cares...Who isn't able to learn new stuff is not worth to be a
programmer..
 
But he is consistent is his Standard. If one always use m_* to mark
member
Actually, it can be - if, say, you want to add "this" to a Hashtable.
That was what I meant by the "entirely different reasons".


Bad for readability, IMO.


You just are not used to it. In lots of other languages like Basic or Perl
or PHP
or whatever it is common to prefix variables with a single character.
Is m_Number or this.Number really easier readable than $Number or #Number or
@Number?
 
cody said:
You just are not used to it. In lots of other languages like Basic or Perl
or PHP
or whatever it is common to prefix variables with a single character.
Is m_Number or this.Number really easier readable than $Number or #Number or
@Number?

Well, my immediate reaction is "yes", but then I prefer braces to
"begin" and "end", so you certainly have a point.
 
You just are not used to it. In lots of other languages like Basic or
Perl
Well, my immediate reaction is "yes", but then I prefer braces to
"begin" and "end", so you certainly have a point.


It is just the thing that we are used to it :)
When I switched from Pascal to C++ I hated it using & instead of @ and c->r
instead of ^c.r. But I got used to it.
 
Back
Top