PSOTWIFLI

[Marc Clifton]

Pete O'Hanlon wrote:

More importantly, the second example implies that you have opened up the scope of the properties to be read/write as opposed to read only

5! Yup.

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

[Marc Clifton]

Tim Carmichael wrote:

I prefer the first; I can see what the arguments are on each line without having to scan a list looking for something.

Me too, but as others have pointed out, it allows for the properties to be write-able.

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

[Mladen Jankovic]

Parameters that are required for establishing invariant should be part of constructor. For others, do as you're pleased. I prefer #2, but I also like read-only field/properties, but that subject is already covered by others in this thread.

[Tim Carmichael]

Clarification... I prefer the properties to be listed, one per line, as in option 1 versus having them all listed on a single line.

[Jeremy Falcon]

For me, it depends. If it's just a few params I tend to go for the latter since a couple params isn't hard to remember. If you end up with a constructor or method that takes a crap ton of them then I use the former always so there's no guesswork as to what the params are. For me, code is like art. You make it look pretty and readable on a case-by-case basis. If it makes sense to do something then you do it, but it doesn't always mean you do the same thing every time for the rest of your life. It's on a case-by-case basis.

Jeremy Falcon

[Jeremy Falcon]

Johnny J. wrote:

I'm old school, so the second one any day!

Hey there's this new fancy language called COBOL you should check out. :rolleyes:

Jeremy Falcon

[dandy72]

The former, even if only because the list of args provided can keep growing and it'll remain readable. Whereas in the latter form, you've probably already reached the limit of what you can see without scrolling horizontally. If that's the dumbest reason imaginable, then I'll still insist it gives me the ability to merely glance at the code to figure out what it's doing.

[dandy72]

Jeremy Falcon wrote:

For me, code is like art. You make it look pretty and readable on a case-by-case basis. If it makes sense to do something then you do it, but it doesn't always mean you do the same thing every time for the rest of your life.

Whenever I make my code pretty I invariably have to revisit it one more time to make it functional.

[Lost User]

Marc Clifton wrote:

Which form do you prefer? Why?

The first. Because Ctrl-X.

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

[H Brydon]

I prefer the second. Because: - When reviewing code (someone else, or you 6 months later), the idea of what is happening can be seen better from a distance. It is clear what is happening on that one line versus having to parse 8 lines to understand what is happening (we're talking human parsing here). The "verb" is on the left, the "nouns" on the right (well okay, there are 2 things going on here. You are building a thing then using it). [I try to do only one thing per line ... not two or more actions per line and not two or more lines per action... see below.] - There is less code, which is simpler (duh), statistically more reliable and easier to maintain. I like to write (and read) code two dimensionally so that it fills more across the page and is more natural to read by humans. Compare: (1) This is easy to read. (2) This is harder to read Bugs in code tend to occur at a relatively fixed number per thousand lines of code... one of the reasons I always try to use the highest level language possible, and don't violate this previous point. How I would do it

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

Yeah, you're creating another variable, but the compiler knows what to do with it, and the code offers something that the debugger can help you with. This code is more debuggable.

I'm retired. There's a nap for that... - Harvey

[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