This question already has answers here:
With block equivalent in C#?
(19 answers)
Closed 9 years ago.
I was looking at the online help for the Infragistics control library today and saw some VB code that used the With keyword to set multiple properties on a tab control. It's been nearly 10 years since I've done any VB programming, and I had all but forgotten that this keyword even existed. Since I'm still relatively new to C#, I quickly went to see if it had a similar construct. Sadly, I haven't been able to find anything.
Does C# have a keyword or similar construct to mimic the functionality provided by the With keyword in VB? If not, is there a technical reason why C# does not have this?
EDIT: I searched for an existing entry on this before asking my question, but didn't find the one Ray referred to (here). To refine the question, then, is there a technical reason why C# does not have this? And Gulzar nailed it - no, there are not a technical reason why C# does not have a With keyword. It was a design decision by the language designers.
This is what C# program manager has to say:
Why doesn't C# have a 'with' statement?
Small or non-existent readability benefits. We thought the readability benefits were small or non-existent. I won't go as far as to say that the with statement makes code less readable, but some people probably would.
Increased language complexity. Adding a with statement would make the language more complex. For example, VB had to add new language syntax to address the potential ambiguity between a local variable (Text) and a property on the "with" target (.Text). Other ways of solving this problem also introduce language complexity. Another approach is to push a scope and make the property hide the local variable, but then there's no way to refer to the local without adding some escape syntax.
C++ heritage. C++ has never had a with statement, and the lack of such a statement is not generally thought to be a problem by C++ developers. Also, we didn't feel that other changes -- changes in the kind of code people are writing, changes in the platform, other changes in the language, etc. -- made with statements more necessary.
In C# 3.0, you can use object initializers to achieve a similar effect when creating objects.
var control = new MyControl
{
Title = "title",
SomeEvent += handler,
SomeProperty = foo,
Another = bar
};
Rather than:
var control = new MyControl();
control.Title = "title";
control.SomeEvent += handler;
control.SomeProperty = foo;
control.Another = bar;
Note that, although this syntax was introduced in C# 3.0, you can still use it with the 2.0 framework, it's just syntactic sugar introduced by the compiler.
It is not idiomatic c#, but if you really want a with equivalent, you could do this:
Person MyPersonWithALongName = new Person();
MyUtils.With(MyPersonWithALongName, p => {
p.Name = "George";
p.Address = "123 Main St";
...
});
class MyUtils {
public static void With<T>(T x, Action<T> do) {
do(x);
}
}
Update:
It occurred to me that you could trivially make this more concise by turning it into an extension method, perhaps renaming it "Alias" or "As" for reabability:
MyPersonWithALongName.Alias(p => {
p.Name = "George";
p.Address = "123 Main St";
...
});
No, the "with" keyword was intentionally left out of the language.
If you have a lengthy name of reference, you can easily make a shorter reference to it using a variable, and even give it a limited scope:
{
SomeClass r = Some.Lengthy.Path.To.Get.To.A.Referece;
r.Some = 42;
r.Properites = "none";
r.To = 1;
r.Set = null;
}
For these solutions:
// ....
// (class Common)
public static void With<T>(T property, Action<T> action) {
action(property);
}
// ...
// usage somewhere ...
Person person = GetPerson();
Common.With(person, p => { p.Name = "test", p.Age = "123" });
It just seems we are aliasing the variable with "p". As solutions go, I found it easy enough to keep the variable name short, this sort of solution with a "With" generic doesn't buy any elegance.
Ideally, we'd all like to see some reworking of the syntax so the usage is similar to how initialization of multiple properties works today:
Person person = new Person() { Name = "test", Age = "123" };
No, it was a conscious decision made by the C# dev team. People have mixed feelings about the 'with' keyword because it can degrade code readability if abused (nesting with's).
I don't imagine that there's a technical reason it doesn't exist. What I would say though, is that the reason that it doesn't exist is that it's a programming construct that exists solely for the purpose of cutting down on typing. With things like intellisense, and copy and paste, the world doesn't really have much demand for features like this anymore. I use VB.Net, and can't recall if it's even still supported. Never really felt the need to use it.
Related
One use for the var type in c# seems to be shortcuts/simplifying/save unnecessary typing. One thing that I've considered is this:
MyApp.Properties.Settings.Default.Value=1;
That's a ton of unnecessary code. An alternative to this is declaring:
using MyApp.Properties;
-- or --
using appsettings = MyAppp.Properties.Settings;
leading to: appsettings.Default.Value=1 or Settings.Default.Value=1
Abit better, but I'd like it shorter still:
var appsettings = MyFirstCSharpApp.Properties.Settings.Default;
appsettings.Value=1;
Finally, it's short enough, and it could be used for other annoyingly long calls too but is this an accepted way of doing it? I'm considering whether the "shortcut var" will always be pointing to the existing instance of whatever I'm making a shortcut too? (obviously not just the settings as in this example)
It's acceptable code in that the compiler will take it and know what to do with it. It's acceptable code logically in that it shortens code later. It's really not any different than actually defining the variable type (int/bool/whatever) rather than saying var. When you're in the studio, putting your mouse of the variable gives you its compiled type, so there shouldn't be any real issue with it. Some might call it lazy, but laziness is the mother of invention. As long as your code doesn't become unreadable, I can't see how it would be much of a problem.
There is nothing wrong with that, as long as the code is clear.
In Fact, var is more and more used exactly for that : shortening the code.
Specially in the case of
MyClass myClass = new MyClass();
Which is very clear enough using
var myClass = new MyClass();
And btw, ReSharper helps you enforce that var is used everywhere it can be !
Seems fine to me, it can enhance readability especially if you're using that long .notated syntax many times.
As a side, if you're using an indexed property or an autogenerated property (which does work on the fly for the GETTER) multiple times, then there can be a performance hit for each access of this property. That's microoptimisation though, so probably shouldn't worry too much about that.
Just be careful to know that the static variables you are referencing do not change from underneath you. For instance, the following would break your "shortcut":
var appsettings = MyFirstCSharpApp.Properties.Settings.Default;
MyFirstCSharpApp.Properties.Settings.Default = new DefaultSettings(); // new reference
appsettings.Value=1;
Of course, I am not suggesting that you would ever write code that does this, but we are talking about global variables here... any code anywhere can change out this reference. Caching the reference in appsettings CAN be dangerous in cases like these... one of the many pitfalls of being coupled to static variables, IMO.
I was busy looking deeper into things like multi-threading and deadlocking etc. The book is aimed at both pseudo-code and C code and I was busy looking at implementations for things such as Mutex locks and Monitors.
This brought to mind the following; in C# and in fact .NET we have a lot of syntactic sugar for doing things. For instance (.NET 3.5):
lock(obj)
{
body
}
Is identical to:
var temp = obj;
Monitor.Enter(temp);
try
{
body
}
finally
{
Monitor.Exit(temp);
}
There are other examples of course, such as the using() {} construct etc. My question is when is it more applicable to "go it alone" and literally code things oneself than to use the "syntactic sugar" in the language? Should one ever use their own ways rather than those of people who are more experienced in the language you're coding in?
I recall having to not use a Process object in a using block to help with some multi-threaded issues and infinite looping before. I still feel dirty for not having the using construct in there.
Thanks,
Kyle
Stick to the syntactic sugar as much as possible. It's concise, more maintainable, less error-prone, well understood, and they created it for a reason.
If you must have manual control over something (e.g. manipulating an IEnumerator<T> instead of using foreach), then yes, ditch the syntactic sugar. Otherwise, being idiomatic is a good thing.
The biggest cost of software development is maintenance over the long term, so the answer is always, do the thing that will give you the easiest and most cost effective maintenance path (with all the exceptions that might prove the rule, perf for example). If you can use syntactical sugar to make your code more readable then that's your answer if the syntactical sugar gets in the way then don't use it.
In C#, this linq statement:
var filteredCities =
from city in cities
where city.StartsWith("L") && city.Length < 15
orderby city
select city;
is syntactic sugar for (and equivalent to):
var filteredCities =
cities.Where(c => c.StartsWith("L") && c.Length < 15))
.OrderBy(c => c)
.Select(c => c);
If you know C# well, the latter version is far easier to pick apart than the former; you can see exactly what it is doing under the hood.
However, for typical everyday use, most people find the sugared version cleaner to look at, and easier to read.
Your example of not being able to use a using construct is my most common deviation from the new approaches made available in .Net languages and the framework. There are just a lot of cases where the scope of an IDisposable object is a bit outside of a single function.
However, knowing about what these shortcuts do is still as important as ever. I do think many people simply won't dispose an object if they can't wrap it in a using, because they don't understand what it does and what it's making easier.
So I do wish there was something like a tooltip helptext for some of these wonderful shortcuts, that indicated something important is happening - maybe even a different keyword coloring.
Edit:
I've been thinking about this, and I've decided that I believe using is just a misleading keyword to have chosen. foreach does exactly what it sounds like, whereas using doesn't imply, to me, what's actually going on. Anybody have any thoughts on this? What if they keyword had been disposing instead; do you think it'd be any clearer?
This question already has answers here:
Lambda variable names - to short name, or not to short name? [closed]
(11 answers)
Closed 9 years ago.
We normally follow coding / naming standard for all C# syntax. For Example, if we declare string inside the method, we use Scope-datatype-FieldName format. (lstrPersonName)
List<Person> icolPerson;
private LoadPersonName()
{
string lstrPersonaName;
}
i am kind of thinking how do we follow the naming standard in Lambda Expression. Especially when we defined the arguments for func delegate, we use shorted names like x. For Example
var lobjPerson = icolPerson.Where(x => x.person_id = 100)
if you look at the above line, X does not follow any standard. i also read that one purpose of lambda expression is to reduce the lenghthy code.
i am here to seek help to get the right approach for naming standard.
var lobjPerson = icolPerson.Where(x => x.person_id = 100)
OR
var lobjPerson = icolPerson.Where(lobjPerson => lobjPerson .person_id = 100)
My lambdas use one letter arguments, usually the first letter of what the parameter name would be:
buttons.Select(b => b.Text);
services.Select(s => s.Type);
But sometimes I add a few more letters to make things clearer, or to disambiguate between two parameters.
And when there isn't much meaning attached to the things I use xs and ys:
values.Aggregate((x, y) => x + y);
All said, the standard I use for lambdas is shortness first, expressiveness later, because the context tends to help understand things (in the first example it's obvious that the b stands for a button).
I've done a lot of programming in VBScript (ASP), and there the use of hungarian notation to keep track of the data type was crucial to keep sane. In a type safe language like C# I find no use at all to use hungarian notation that way.
Descriptive variable names does very much for the readability of the code, but it doesn't always have to describe every aspect of a variable. A name like persons indicates that it's a collection of person objects, whether it's a List<Person> or IEnumerable<Person> is usually not that important to understand what the code is doing, and the compiler tells you immediately if you are trying to do something completely wrong.
I frequently use single letter variable names, where the scope of the variable is very limited. For example the i index variable in a small loop, or in lambda expressions.
I usually just use the first letter of the type I am querying so in your case since it is of type Person I would do:
var lobjPerson = icolPerson.Where(p => p.person_id = 100);
Another example if it was say type Car I would do:
var lobjCar = icolCar.Where(c => c.car_id = 100);
I do this for quickness, however, I don't think there is anything wrong using full names in the query i.e. car => car.car_id
I think the naming standard you use (hungarian notation) was the need of the hour when high profile tools like Visual Studio were not present. Today you have technologies like Intellisense which tell you most of the things you are doing wrong with a variable as you type, like assigning an int to a string. So, as of today, it is not an exclusive part of good coding conventions or standards as it used to be. Most people follow pascal casing or camel casing these days. If anybody uses it, I think it is more because of a personal preference.
Having said that, according to the way you code and name your variables, you should follow the second approach instead. Again, this boils down to you personal preference.
PS: This comment does not mean that I am looking down on your usage of hungarian notation. :)
There is no the right approach at all. Naming standard like any other coding standards (like spaces and new lines after/before expressions) is a convention inside group. So just write your code as you like and as you should do it at your company. But do it consistently!
i prefer use underscore prefix in names of private fields. but your style(visibility + type + name) looks for me like an old WInAPI code citation(Hungarian notation) =).
As long as your lambda expression is only a single statement, I'd keep the variable name as short as possible. The overall purpose of naming is to make the code readable, and in these cases, the method name and general context should be enough.
You don't have to use x all the time. For a Person object, I'd tend to use p instead.
If you need to write a more complex expression involving braces and semicolons, I'd say that all the normal naming rules apply.
If your collection is called something-persons, then it's obvious that when you're doing persons.Where(p => p.Whatever) that p is a person. If your lambdas are so complicated it's not immediately obvious whatever the parameters you're using are, then you shouldn't use lambdas at all, or make them drastically simpler.
As for your other conventions, what is the point of using Hungarian for calling out that personName is a string? It's obvious that a name would be a string. And why do you need a prefix to remind you that a variable is a local? Its declaration is necessarily in the same method, so that can't be so long ago that you've already forgotten it. If you have, then your methods are too long or complex.
Just have your identifiers appropriately describe what the meaning of the variable is, then the rest will be obvious.
LINQ is not just for the developers who used to write queries for databases but also for the Functional Programmers.
So do not worry if you are not very comfortable with SQL kind of queries, we have a very nice option called “Lambda Expression”.
Here I am going to demonstrate the scenario for both the options with a small example. This example has an array of integers and I am only retrieving the even numbers using the power of LINQ.
Here we go
using System;
using System.Collections.Generic;
using System.Text;
using System.Query;
using System.Xml.XLinq;
using System.Data.DLinq;
namespace LINQConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
int[] arrInt = {1,2,3,4,5,6,7,8,9,10};
#region Place to change
//Language Integrated Query
var aa = from s in arrInt
where s % 2 == 0
select s;
#endregion
foreach (var item in aa)
{
Console.WriteLine("{0}", item);
}
Console.ReadKey();
}
}
}
If you do not want to use the different approach of query for Language then you are free to use Lambda Expression.
So just replace the #region area with the following code block results will be identical.
#region Place to change
//Lambda Expression
var aa = arrInt.Where(s => s % 2 == 0);
#endregion
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have two specific C# coding conventions I've been practicing with mixed feelings.
I'd be curious to hear what people think. They are:
#1. Name instances after the class it's an instance of, camelCased
#2: "Matching property names"
Here's the rationale:
#1. Name instances after the class it's an instance of, camelCased
I use this as my default setting for naming convention. Of course, there are exceptions. But used consistently it dramatically improves code clarity and maintainability. The code looks like this:
var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.
FileInfo fileInfo = new FileInfo();
Timer timer = new Timer();
//etc.
I'm at the point where code like this causes me physical pain:
DataConnection dbConn = new DataConnection();
I can't stress enough how this convention has taken away the pain and anger of the variable name game.
This convention is in sharp contrast to attempting to name things in ways that try to indicate what the instance is doing, which amounts to trying to creatively embed the business case in code. Code has a way of getting refactored to the point where those original names are misleading at best.
To me this convention is gold. It also prevents the horrible practice of slightly tweaked variable names for the same thing.
An example of this convention in practice is:
class Person { ...
public string FirstName { get; set; }
//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.
Very easy to read. Very boring. Boring is good when it comes to maintaining code.
However, this convention leads me to #2:
#2 "Matching property names" ( for lack of a better title )
Here's an example:
public class ShoppingCart { ..
private Item item;
public Item Item { //<---- ?
get { return this.item; } ...
The compiler is perfectly happy with this. And, in fact, it exposes a very nice interface:
//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();
shoppingCart.Item = item;
Now, the alternative is to be creative -- You actually need to drum up two good variable names for Item: the public property name and the private member variable name.
How many times have you seen this and just want to retire immediately?
public class ShoppingCart { ..
private Item cartItem;
public Item ShoppingCartItem {
get { return this.cartItem; } ..
///....
ShoppingCart userShoppingCart = new ShoppingCart();
userShoppingCart.ShoppingCartItem = userSelection;
I feel strongly enough about convention #1 that I think I can live with #2.
What do you think ?
in case you were not aware and if you care , C# already has a naming standard
http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx
Also, looking at your conventions again ... here's some more suggestions.
fileInfo looks pretty next to FileInfo but it has no meaning other than it's type which I can quickly get by mousing over the type or in intellisense. I would suggest naming your variables with meaning and some context if available. remoteWebServerLog, localWebServerLog, or even localWebServerLogFileInfo if you like the type in the name.
If I can hand off any advice from coming back to code you've written 6+ mos later. You will be scratching your head trying to figure out and track down what the heck all your dbConn and fileInfo's are. What file? What db? Lots of apps have several dbs, is this dbConn to the OrdersDB or the ShoppingCartDB?
Class naming should be more descriptive. Wwould prefer ShoppingCartItem over Item. If every ListBox, DropDown etc named their collection items "Item" you'd be colliding with a lot of namespaces and would be forced to litter your code with MyNameSpace.ShoppingCart.Item.
Having said all that ... even after years of coding I still screw up and don't follow the rules 100% of the time. I might have even used FileInfo fi = ... but that is why I love my Resharper "Refactor->Rename" command and I use it often.
Convention #1 can become confusing. If you were to have two FileInfo objects in the same method-- say a Source and a Target-- you'd need to deviate from the convention in order to name the two.
Variable names should be mnemonic-- to indicate to the casual observer the intent of its use.
Perhaps you'd be happiest with a combination of the two conventions... such as sourceFileInfo and targetFileInfo, per this example.
Obviously, you can't name every System.String in your project string*, but for things you don't use a lot of, esp. things you only need one of, and whose function in your code is obvious from its name, these naming conventions are perfectly acceptable.
They're what I do, anyway.
I would go with a more specific name for, say, the Timer object. What's it a timer for?
But I would definitely name a DataConnection dataConnection.
*Even if "string" wasn't a keyword...
I do 1 all the time and find it very readable. I'm on the fence with 2. I find it confusing in certain situations, mainly because it's hard to distinguish the type from the property due to the identifiers being identical.
I would normally follow convention #1, although for long class names I tend to just use the initials of the class. If I am referring to more than one object of the same type then I would pre-pend the type name with a name indicating which one it is or what it’s used for.
I quite often use convention #2 if it makes sense. There is nothing worse than having something like the example you listed of cart.ShopingCartItem, the very fact that it is a property of ShoppingCart makes that part of the property name totally redundant. However I would quite likely name the class ShoppingCartItem and the property Item. Item is a little too generic a name whereas ShoppingCartItem tells you what kind of item you are working with.
I follow convention 1 all the time. Although, I do add an additional qualifier if there are two objects side by side.
But having said that, making this convention mandatory may be problematic:
In a certain context cart may be a good enough name for a ShoppingCart object (if, for example, there is no other 'cart' in the same function to be confused with).
Sometimes the convention may completely obscure the purpose of the declared object. For example Window scoreBoard = new Window() says that we have an object which is indeed a Window but is being used as a scoreBoard. Very expressive. But following convention 1 you'd have to write Window window = new Window() which totally hides the intention behind this window.
So I'd say use this naming idea everywhere except when it hinders meaning or appears unreasonably demanding.
About convention 2, I totally agree. Keeping property names succinct and letting the object name complete the full meaning of its invocation is an elegant thing. It works perfectly with well named objects. So there's little reason to be shy of using it.
I strongly dislike the notion of having multiple identifiers in scope which differ only in their usage of upper/lower case; if I had my druthers, code which used an identifier would be required to use the same combination of upper/lowercase letters as its declaration, but code would neither be allowed to declare two identifiers in the same scope which differ only by case, nor access any identifier which would--except for case--match an identifier in an inner scope. Although no language I know of (certainly not VB nor C#) enforces such rules, code written in compliance with such rules could be freely portable between case-sensitive and non-case-sensitive languages without having to rename identifiers.
Consequently, I dislike the pattern #2. CLS compliance requires that any identifiers of that style be restricted to private or internal scope. Since both vb.net and C# allow names to start with underscores, if a property is named Trait, I see no reason to favor trait over _trait. Use of the latter name would clearly distinguish cases when the programmer wanted to write to the backing variable from those where his finger slipped on the shift key.
As for pattern #1, in cases where the whole purpose of a type or method resolves around a single encapsulated object of some particular type, I prefer to prefix fields with my or parameters with the. Even in cases where the compiler would allow the same names to be used for instance members and parameters, using distinct prefixes avoids the possibility of accidentally using one where the other is required.
I came across this code and wanted others to provide their point of view... is it good or bad ? ;)
Class ReportClass
{
public string ReportName {get; set;}
}
Then it was used as follows in code:
displayReport(ReportClass.ReportName = cmbReportName.SelectedValue.ToString())
That is about the simplest form example I can give you.
Quetion is... why can't I find examples ? What would this be called? Is this just asking for trouble?
EDIT: I'm referring to the inplace assignment. Which I wasn't aware of until today
I tend to avoid in-place assignment - or indeed any side effects like this - except for one common idiom:
string line;
while ((line = reader.ReadLine()) != null)
{
// Do something with line
}
(And variants for reading streams etc.)
I'm also okay with using object initializers in parameter calls, e.g.
Foo(new Bar { X=1, Y=2 });
but assigning to a property in an existing object... well, it's all subjective but it's not my cup of tea.
I think this is harder to maintain/harder to debug/harder to understand code. I would do the assignment on a line prior to calling that method.
ReportClass.ReportName = cmbReportName.SelectedValue.ToString();
displayReport(ReportClass.ReportName);
I've never really been a fan of compound statements.
It is totally fine. Both of them.
Automatic properties (the {get; set;} thing): Introduced in C#. Very useful feature.
Assignment in the parameters: Rarely used in C# but totally legal. Basically it assigns the value of the expression to the right of the assignment operator (=) to the property to the porperty on the left, and then passes this value on to the method.
This is more common in C, but I see no reason why shouldn't it be allowed in C# as well. Sometimes it might help readability, sometimes it makes it much worse. Use common sense to decide which applies when.
Did you mean the automatic properties or the in-place assignment?
Depends on your team IMO. If your team were comprised of C-style devs. Then I think it is ok.
But if this code is gonna be maintained further by, say, VB developers, then you'd need
to make this more readable.
Examples? The assignment operator (=) in C langauges also return the values it's assigned.
var a = 0;
var b = 0;
// This makes a *and* b equals to 1
a = b = 1;
// This line prints 3 and a is now equals to 3
Console.WriteLine(a = 3);
// This line prints 7 and a and b is now equals to 7
Console.WriteLine(a = b = 7);
I think it is rather natural for this kind of assignment to happen. Because the C-languages seem to encourage shorthand notations IMO.
If you need more readability and less trouble, then I'd say a newline is a nice add.
displayReport(
ReportClass.ReportName = cmbReportName.SelectedValue.ToString());
Make your intentions clearer when each compounded statements are on different lines. (but still a compound statement)
Or, extract the right part out into its own variable first, e.g.
var reportName = cmbReportName.SelectedValue.ToString();
displayReport(ReportClass.ReportName = reportName);
I use it all the time, and I havn't seen anyone confused upon reading it yet.
Personally I find the assignment as parameter not very readable. The overall flow of execution is just skewed by having an operation actually happening inside the parameter list.
I like to think that my code should express intent, not save whitespace. And my intent in this example would be exactly what EvilSyn suggests, first assign value, then pass it to the method.
The Microsoft Framework Design Guidelines discourage the placement of multiple statements on one line, except where there is direct language support, such as in the for statement. Since there is explicit language support for multiple assignment,
int a, b, c;
a = b = c = 0;
is permitted. On the other hand, code of the form used in your example is discouraged.
How about this one, people?
while ((packetPos = Packet.FindStart(buffer, nextUnconsideredPos)) > -1)
To avoid the inline assignment, you would have to factor redundantly, like this:
packetPosition = Packet.FindStart(buffer, nextUnconsideredPosition);
while (packetPosition > -1)
{
...
packetPosition = Packet.FindStart(buffer, nextUnconsideredPosition);
}
As far as naming the property goes you have a ReportClass, I would change that to Report and the property on it changed from ReportName to just Name. Saves you on typing (although yes intellisense is available). Looks better when coding up as Report.Name.
I know its a little off topic but hey ho
Seems fine to me. It is probably compiled with C# 3.0 and that allows C# automatic properties.
Is that really valid code? Seems like a static class to me.
I would have guessed you used it like this:
displayReport(new ReportClass { ReportName = cmbReportName.SelectedValue.ToString() } )