|
Why are you using named parameters? They use more stack space than standard parameter passing, and therefore performance suffers. IMHO, they also have no tangible benefit with regards to code readability.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 1-Dec-16 13:35pm.
|
|
|
|
|
John Simmons / outlaw programmer wrote: They use more stack space than standard parameter passing, and therefore performance suffers.
Don't think so, naming them is just some syntactic sugar.
Anyway, they were named because the method being called was some code generated from an Oracle package.
When the Oracle package changes so does the code, so by naming the parameters they're not messed up (well, apparently they are  ).
|
|
|
|
|
John Simmons / outlaw programmer wrote: They use more stack space than standard parameter passing
Nope.
void Main()
{
Foo(1, 2);
Foo(x: 1, y: 2);
}
void Foo(int x, int y) { }
Decompiles to:
IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: ldc.i4.2
IL_0003: call UserQuery.Foo
IL_0008: ldarg.0
IL_0009: ldc.i4.1
IL_000A: ldc.i4.2
IL_000B: call UserQuery.Foo
IL_0010: ret
Calling the method with named parameters compiles to exactly the same IL as standard parameter passing.
John Simmons / outlaw programmer wrote: they also have no tangible benefit with regards to code readability.
Depends on the method.
If you're using Office Interop, named parameters are much more readable than passing 500 ref missing parameters.
And if your method takes a bool - or worse, mulitple bools - then named parameters make it clearer which parameter each value relates to.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
However, passing them in an order that is different from the unnamed, normal, order does use more stack space!
public void Main()
{
Foo(1, 2);
Foo(x: 1, y: 2);
Foo(y: 1, x: 2);
}
void Foo(int x, int y) { }
IL:
IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: ldc.i4.2
IL_0003: call instance void Foo(int32, int32)
IL_0008: ldarg.0
IL_0009: ldc.i4.1
IL_000a: ldc.i4.2
IL_000b: call instance void Foo(int32, int32)
IL_0010: ldarg.0
IL_0011: ldc.i4.1
IL_0012: stloc.0
IL_0013: ldc.i4.2
IL_0014: ldloc.0
IL_0015: call instance void Foo(int32, int32)
IL_001a: ret
It must do this because the passed arguments are evaluated in left-to-right order of the call, not the order that the called method expects.
(Section 7.5.1.2 of "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC#\Specifications\1033\CSharp Language Specification.docx" as installed with VS2013.)
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
|
|
|
|
|
Tell Microsoft - if they don't know about it, then they can't fix it.
Not that they do fix bugs, of course... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hmm, I've maybe had to use named parameters a handful of times but never had any issues. Possibly stupid question but have you ensured the ordering is correct? Named parameters are evaluated in order passed not by the ordering in the function passed-to. This may not be applicable but I never assume people's objects (Input in this case) are side-effect free.
Example:
static void Main(string[] args)
{
int num = 0;
Test(z: ++num, y: ++num, x: ++num);
Console.ReadKey();
}
public static void Test(int x, int y, int z)
{
Console.WriteLine($"X: {x}, Y: {y}, Z: {z}");
}
This is a pretty contrived example, but I can't reproduce with this, no matter how I arrange the named input:
static void Main(string[] args)
{
int x = 1, y = 2, z;
List<int> values = new List<int>() { 3, 4, 5, 6 };
IEnumerable<int> query1 = values.Where(num => num % 2 == 0);
IEnumerable<int> query2 = values.Where(num => num % 2 != 0);
Test(y: y, x: x, query2: query2, query1: query1, z: out z);
Console.WriteLine($"Z: {z}");
Console.ReadKey();
}
public static void Test(int x, int y, IEnumerable<int> query1, IEnumerable<int> query2, out int z)
{
Console.WriteLine("Inside Test:");
Console.WriteLine($"X: {x}, Y: {y}");
Console.Write("Even: ");
foreach (int val in query1)
Console.Write($"{val} ");
Console.Write("\nOdd: ");
foreach (int val in query2)
Console.Write($"{val} ");
Console.Write("\n");
z = 7;
}
|
|
|
|
|
I've always maintained that named parameters were a bad idea, and it sounds like your coworker has found a way to make my case.
Functions have signatures - I'm more than happy to rely on them; I should be able to remain completely ignorant of any and all implementation details (yes, I consider a parameter name to be an implementation detail I should not have to care about--ever).
IMO that's not a constraint - it's something I rely on.
|
|
|
|
|
dandy72 wrote: I consider a parameter name to be an implementation detail I should not have to care about--ever
File.Replace(string, string, string, bool)... Good luck figuring out what those parameters are 
Properly naming your variables (and classes, methods, parameters, etc.) is one of the first rules of clean code.
I don't name them when I call the function, but I sure as hell like to know what goes where.
|
|
|
|
|
Of course, it should have a name that makes enough sense that I can tell what I need to provide at a glance, without having to look at what the function does with the parameter (even assuming I had access to the source).
However my point was that I shouldn't need to know exactly how it's spelled out. For all I care, the documentation could say the third string is DriveLetter, whereas the actual implementation uses lpszDriveLetter or __drv0. Named parameters remove that abstraction (if you want to call it that).
|
|
|
|
|
I haven't run into this problem, and I haven't seen any reports of other people encountering it either. (Except yours, of course!  )
Anything strange going on with the generated package?
Are you definitely using the same version of the package at run-time and compile-time?
Have you installed a non-standard version of Roslyn?
Can you reproduce the problem in a simple example project?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
We even checkout out the project on my machine to try it there, but with the same results.
Haven't created a sample project yet.
|
|
|
|
|
Can you not see the bovines, because of their cowmooflage?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
cowmooflage: Moove on, nothing to see here
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
That's an udderly ridiculous suggestion!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Cud chew repeat that?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Where's the beef?
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
This is bull***t!
DURA LEX, SED LEX
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
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Is there a joke hidden in there?
|
|
|
|
|
no I think that's a yoke
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
|
Now you're just milking it!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
|
4th day at the new job, commuting to work, as the manager doesn't like people working remotely. The irony is, I remote in to my machine at home for various things, like CP, and cough working on stuff while I'm basically warming a seat here.
At least the first couple days were basically sitting around waiting for apps to install and TFS  to download the code repos. Never thought I would say it, but I miss Git!
Yesterday was a bit more interesting, got in early and in an hour had the start of a test jig working for exercising the entry points that the application calls for custom business logic (everything here is XML packets!) Ironically, one of my coworkers popped in to my cube and asked if I had written anything yet that called some of the BL components.
There was much ooh'ing and aah'ing when I showed him the test jig.
Today is waiting for more security / authorization permissions so I don't get a 404 error when trying to run test code and hopefully getting some clear definition of what, besides warming a chair, I'm supposed to actually be doing.
The people are great, it's nice working with laid back and relaxed developers, though the aforementioned manager needs a few counterclockwise turns of the screw in his arse.
Marc
|
|
|
|
|
I hope that not only the people there are pleasant, but also the work you are going to do...
...when you finally get some work 
Besides, to loosen the screw of a gas cylinder, you have to turn it clockwise 
(in contrast to a normal bottle, at least here in Germany)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
