|
I'm old school, so the second one any day! 
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
|
|
|
|
|
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. 
Jeremy Falcon
|
|
|
|
|
Too soon. Gotta wait a bit and see if it catches on... 
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
|
|
|
|
|
Jeremy Falcon
|
|
|
|
|
Arriving late to the party (comments indicate multiple edits have been made).
For my older eyes, I prefer the first; I can see what the arguments are on each line without having to scan a list looking for something.
|
|
|
|
|
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.
|
|
|
|
|
Clarification...
I prefer the properties to be listed, one per line, as in option 1 versus having them all listed on a single line.
|
|
|
|
|
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.
|
|
|
|
|
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 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.
|
|
|
|
|
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.
|
|
|
|
|
Marc Clifton wrote: Which form do you prefer? Why?
The first. Because Ctrl-X.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
|
|
|
|
|
Neither. I'm a white-space supremacist.
Processing.Fire
(
this
,
new ProcessEventArgs
(
fromMembrane
,
fromReceptor
,
membrane
,
target
,
obj
)
) ;
|
|
|
|
|
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)
|
|
|
|
|
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...).
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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 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.
|
|
|
|
|
Have you had to walk 500 miles?
Were you advised to walk 500 more?
You could be entitled to compensation.
Call the Pro Claimers NOW!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
what are you havering on about now?
Installing Signature...
Do not switch off your computer.
|
|
|
|
|
Oh. My. God.
Unintellegible but for a few blessed human beings. My wife is a Tennant superfan so I got it but... woah.
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
