A couple questions of style

[Daniel Billingsley]

I'm always curious on some of these style issues if there seem to actually
be objective reasons for doing things one way or the other, so here goes for
a little lighter discussion.

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?

2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region. Lately I've seen code where they are scattered in the
various regions where they are actually used - near the corresponding
property code, for example. The latter seems a bit more useful for someone
like me who loves regions.

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hi Daniel,

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?

I usually write a constructor myself (to be more exact, when you add a new
class from the IDE, the empty constructor is already written for you).

2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region.

This is the style I prefer. In my classes, I usually organize code like
this:

Constants
Private members
Constructor(s)
Public methods
Public properties
Public events
Protected methods
Protected properties
Protected events
Internal methods
Internal properties
Internal events
Private methods
Private properties
Private events

If there are some static members, they go before the instance ones in the
order outlined above.

 

[Jeffrey Tan[MSFT]]

Hi Daniel,

Thanks for posting in this group.
Personally, I think:
1). Because the compiler will generate a default constructor for you, there
is no matter whether you create a empty constructor or not.
2). I think if one class variable is only for property usage, I prefer to
create the variable just above the property definition. I will place other
non-static variables in the same region.

This is just a personally programming style, let's hear some others'
suggestion.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Jeff Louie]

Daniel.... I would lean to explicitly writing an empty constructor if I
wanted to support an empty constructor. If someone updates your code
and adds a custom construtor, the default constructor will be silently
removed!

I usually declare variables at the top. If the variable is _only_ used
in a
local section of code, then I would put it close to the code. This is
the
"principle of proximity," Code Complete, Mcconnell.

Regards,
Jeff

1) Default constructors. Do you always write a constructor for every

class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?<

 

[Kevin Cline]

I'm always curious on some of these style issues if there seem to actually
be objective reasons for doing things one way or the other, so here goes for
a little lighter discussion.

1) Default constructors. Do you always write a constructor for every
class, even when it doesn't do anything special, or do you "trust" the
default one that will be generated?

I like my code lean and mean, so I delete everything unnecessary. It
saves me the trouble of thinking "... ok, default constructor that
doesn't do anything..."

2) Regions. I really really like the region feature for organizing code
and reducing noise in the IDE. I've seen quite a bit of code where people
put all the private class variables together right at the top of the class
in their own region. Lately I've seen code where they are scattered in the
various regions where they are actually used - near the corresponding
property code, for example. The latter seems a bit more useful for someone
like me who loves regions.

I would rather see the member declarations collected at the top, so I
can think "ok, this class has abc and provides services xyz".

 

[Eric Newton]

Agreeing with Kevin, whats the point of a default constructor that does
nothing, yet leaves the object in an invalid state?

COM forced us to perform initialization through a myriad of Property setting
or via an uncommon "Initialize" or Init or whatever the component designer
decided on, which was always a "bad thing" since Components that rely on
particular states can become very hard to program and henceforth hard to
debug if the only way to achieve the proper state is through setting
multiple, possibly "un-grouped" properties before the Component is in a
valid state to do something...

I also get somewhat irritated with some of the .NET Framework functions,
specifically the WebServices where an object that is passed via parameter or
return value from the web service is REQUIRED to have a default constructor
and settable properties, instead of utilizing a Serialization [via
ISerializable] technique to remove this "defalt constructor" requirement.

 

[Frank Oquendo]

Agreeing with Kevin, whats the point of a default constructor that
does nothing, yet leaves the object in an invalid state?

The assumption of course is that calling a parameterless constructor
yields an object whose state is not valid. Such should not be the case.

Personally, I prefer to code my own constructors simply to make the
design clear. Why force readers to wonder where a default constructor
originates in your object hierarchy when you can answer the question
with a single line of code?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Alvin Bruney]

EventArgs constructors.

I normally block the parameterless default ctor in favour of enforcing event
parameter rules on the constructor rather than propertys (they are still
available) but i enforce minimum construction.

 

[Daniel Billingsley]

Indeed! This is one of those points that is both good and objective I was
talking about (as opposed to purely personal style) and hadn't considered.

 

[Daniel Billingsley]

Indeed Frank. In fact, I think declaring the simple constructor also has
the side-effect of explicitly announcing that the object will be in a valid
state at that point, doesn't it? That seems like a good thing to me.

 

[Jon Skeet [C# MVP]]

Why force readers to wonder where a default constructor
originates in your object hierarchy when you can answer the question
with a single line of code?

I'm not quite sure what you mean here. A constructor can *only*
originate in the class itself - it's not like constructors are
inherited.

 

[Daniel Billingsley]

Jon, how would you describe the following behavior, in that
DEF._someInteger will = 20 , without saying DEF inherits the constructor?

class ABC
{
protected int _someInteger;
public ABC()
{
_someInteger = 20;
}
}

class DEF : ABC
{
}

 

[Jon Skeet [C# MVP]]

Jon, how would you describe the following behavior, in that
DEF._someInteger will = 20 , without saying DEF inherits the constructor?

I would say that DEF has a default constructor generated for it by the
compiler and in accordance with the C# specification, and that the
default constructor calls the base's parameterless constructor. (In C#,
every constructor chain within a class other than object terminates at
some stage with a call, implicit or explicit, to one of the
constructors of the base class.)

How would you describe the following behaviour, in that you get a
compile-time error, without saying that DEF *doesn't* inherit the
constructor?

using System;

class ABC
{
public ABC (int x)
{
}
}

class DEF
{
}

class Test
{
static void Main(string[] args)
{
DEF def = new DEF(10);
}
}

See http://www.pobox.com/~skeet/csharp/constructor.html for a more in-
depth discussion.

 

[Daniel Billingsley]

Hold on, I wasn't trying to disagree with ya, just trying to clarify things
in my head. I had seen the behavior you demonstrated as well, which made it
sort of appear there was inheritance in one case and not in the other.

What you say makes sense, except for the part in parenthesis - I did not
know that. What's the point of being able to specify a base class
constructor to be called in the subclass constructor - to override what the
compiler may choose to do by default?

 

[Jon Skeet [C# MVP]]

Hold on, I wasn't trying to disagree with ya, just trying to clarify things
in my head.

Fair enough

(This is a topic it's easy to get me riled up about, I'm afraid. There
was an ugly argument about whether or not constructors were inherited,
despite the spec absolutely *explicitly* stating that they're not.)

I had seen the behavior you demonstrated as well, which made it
sort of appear there was inheritance in one case and not in the other.

What you say makes sense, except for the part in parenthesis - I did not
know that. What's the point of being able to specify a base class
constructor to be called in the subclass constructor - to override what the
compiler may choose to do by default?

Well, sort of. If you don't specify anything, it's the equivalent of
having base() - but you may well want to specify a different one, or
indeed there may *be* no parameterless constructor in the base class to
be called automatically.