PSOTWIFLI

[Marc Clifton]

Richard Deeming wrote:

Also, named parameters can make the constructor look more like the object initializer:

Now that I think about it, I have used that syntax, in ASP.NET/Razor. Personally, I think the only reason they added that form of initialization was so that people used to JSON object initialization in JavaScript would be comfortable. ;)

Latest Article - Class-less Coding - Minimalist C# and Why F# and Function Programming Has Some Advantages Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802

[PIEBALDconsult]

Neither. I'm a white-space supremacist.

Processing.Fire
(
this
,
new ProcessEventArgs
(
fromMembrane
,
fromReceptor
,
membrane
,
target
,
obj
)
) ;

[BillWoodruff]

this one:

Processing.Fire(this, new ProcessEventArgs()
{
try
{
FromMembrane = fromMembrane,
FromReceptor = fromReceptor,
ToMembrane = membrane,
ToReceptor = target,
SemanticType = obj
}
catch(Programmer.SynapsesSluggishError ex)
{
throw new InadequateCaffeineError("get coffee", ex);
}
});

«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it. A few hundred years later another traveler despairing as myself, may mourn the disappearance of what I may have seen, but failed to see.» Claude Levi-Strauss (Tristes Tropiques, 1955)

[Johnny J]

Too soon. Gotta wait a bit and see if it catches on... :laugh:

Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time

[Tom Chantler]

I prefer the first format as you can see exactly what's going on, regardless of the names of the parameters being passed. Please don't make me delete and retype the opening parenthesis to see the intellisense for some abstruse funtion, etc. Also, it is immune to the problem of somebody changing the order of parameters (we all know that should never happen but, well, you know...).

[Gary Wheeler]

I prefer the first form specifically where you are simulating named argument support in a C# compiler that doesn't support it directly (VS2008 for example). This form is useful when the argument has a lot of default values, only a few of which you typically override. I also prefer the first form in general. My local variables are usually named according to their use locally, and not according to their potential use as arguments. For that reason, my locals may not identify themselves well when used in the second form.

Software Zen: delete this;

[Kirk 10389821]

Well, it depends. If it was only one method, then the top has a slightly better flow-read going for it. But if this was one of literally 10's or 100's of methods. Then the bottom method would reduce the tedium involved in scanning the code, and comparing for missing or finding what I want.

[SeattleC]

It's all about the 80-column limit. Remember, from when you typed into dumb terminals that only displayed 80 columns by 24 rows of text (thank god those days are gone). In the modern world, the 80 column limit is still adhered to because it's harder to read code that sprawls across the whole width of the screen. Yeah, I like the keyword = value thing too for documentation purposes, but that's not the (only) reason I lay my code out vertically.

[patbob]

I prefer constructor parameters for pieces of data that must be set for the object to work properly -- as a parameter because the compiler will catch it if you forget something. Not so with constructor initializers -- if you forget some critical parameter, nobody will know until they exercise the code that depends on it at runtime. I also have a philosophical dislike of the encapsulation breakage that constructor initializers allow. It limits the controls that a class designer has over what they want to allow others to do with the internals of the class, and pollutes unrelated code with dirty knowledge of internal implementation details of a class. This makes it harder to refactor the internal implementation of a class.

I live in Oregon, and I'm an engineer.

[Jeremy Falcon]

:)

Jeremy Falcon

[Arkitec]

I mostly maintain my own code, and I prefer the former as 1+ years later, I definitely won't remember the parameter order. Explicit is better for maintainability, even if it requires more typing. And way easier to explain the odd time when I have to bring another developer up to speed. Also, when I show the code to clients, it looks like I have done more work. :) A short little line of code does not look impressive.