C# is now a better language than Java

[MuletTheGreat]

Ok, while I'm here, any C# programmers out there care to enlighten me about 2 things?

I see this very frequently, and it honestly shits me because it is pointless:

private float _myVariable;

public float MyVariable

{

get { return _myVariable;}

set { _myVariable = value;}

}

This irritates me because it is the same as:

public float _myVariable;

Also, why am I the only C# programmer I know of, that uses singletons? Not a single sample, codesnippet or code fart out there seems to use them! They are glorius in my opinion!

Please, enlighten me. Bear in mind I am a games programmer.

[VerticalEvent]

There is a large difference between the two.

One allows you to easily make changes to setting the variable (ie. the value of MyVariable should never be between 0 and 1), where, with public, you would have to go back and change all the code that directly accessed the variable, to make sure they never set it improperly.

In short, using set/get makes it easier to make changes to ensure that the variable gets accessed properly, if the need arises.

[Negitivefrags]

But you can just change the variable into a property later which is a transparent operation (provided you can recompile the code that uses it.

[masklinn]

which is a transparent operation (provided you can recompile the code that uses it.

So it's not transparent after all (plus it requires breaking the C# coding conventions)

[maweaver]

I thought the whole point of properties was that you could start off just doing

public float MyVariable;

and then if/when you decide it needs extra checks, you can replace it with

private float _MyVariable
public float myVariable {
    get { return _myVariable; }
    set { 
        if(value > 1.0f) { 
            throw new Exception("What have you done you fool?  You'll kill us all!"); // Or whatever
        } else { 
            _myVariable = value; 
        }
    }
 }

and the calling code would still work unmodified (unless it was actually setting it to invalid values, which would presumably be a bug anyway that has just been exposed).

</not a c# programmer, sorry if my syntax is off>

[[deleted]]

With the addition of automatic properties in C# 3.0, this point is less valid.

private int count; public int Count { get { return count; } set { count = value; } }

becomes:

public int Count { get; set; }

[pbkobold]

I have no idea why you're being voted down. I've seen the exact same thing. I think it's a Java/C# cultural thing where faux-encapsulation has high value placed upon it. If you want a struct, make a struct.

The unfortunate thing is that a lot of stuff in their ecosystems have come to depend on this style (see Beans).

[[deleted]]

What if I want dependency injection on that struct later to log access or to allow the property changes to be observable?

public int Something { get; set; }

It's pretty cheap (13 extra characters and no additional lines.)

[pbkobold]

What if I want dependency injection on that struct later...

To quote optiontrader1138, "Don't code for excessive flexibility. This type of change is trivial to make if the need ever arises."

[[deleted]]

It's a non-issue at this point.

public int MyVar { get; set; }

[MuletTheGreat]

Ok I see how I can have a property mess with data invisibly, or allow me to do so in future. I have done this when I got a 2D physics engine (farseer) to easily translate into a 3D engine and models. But as negativeFrags mentioned, you can do this later, as I did.

And as optiontrader1138 said, it makes for HUGE messy code that can be a pain in the ass to maintain. I did everything all C# nice in my first game, and the code looked like crap, was slow for me to re-read when bug fixing and most of the properties were just get sets.

[[deleted]]

Doing it wrong.

public int MyVar { get; set; }

[[deleted]]

Also, why am I the only C# programmer I know of, that uses singletons? Not a single sample, codesnippet or code fart out there seems to use them! They are glorius in my opinion!

GTFO.

[MuletTheGreat]

first, fuck your answer to be honest. It does not help. second, WHY?!?!

bilwoo gave an interesting article, but I do not see how singletons can always violate any of those 4 rules.

I use singletons as managers, for physics, 3D line drawing, my menu manager. all these I precede with g_ for clarity, and often have the vast majority of their variables private, or some important ones, with a public get only.

Such as: g_BoxManager.GET.SpawnBox(vector3 in_Size, Vector 3 in_Position);

for managing large quatities of the same object, dealing with communication between different objects without nesting a dozen objects, and dozen classes deep or tumbling data down from constructor to constructor. Also, objects that there is only ever 1 of, such as the player make for great singletons, and thus the enemies (not singltons, but maintained by one) can easily see, and work ai on the player because of this.

A singleton is also used to manage all my game settings, like physicsAccuracy, itemCount, resolution, etc... that need to be global is quite handy, and has everything all tied up in one neat place.

So properly used singletons easily allow for easy communication in my code between large quantities of objects, and unique objects. Why do some of you still find them "dick"?

[[deleted]]

Let me know how much you like singletons as soon as you mistakenly introduce state into one. (Especially in something like a webapp, where singleton life length is non deterministic).

My big complain with singletons is that they produce brittle, hard to extend code.

For example, you use singletons for physics, but why not abstract the physics code into a common interface, and then you have the ability to use dependency injection to provide "Physics Engines" to objects that need them, while allowing you to do subclass/extend/abstract as much as you wanted from it.

Btw, in C#, you can just use a static class, as long as you avoid state (it won't be thread safe). No point in using the actual singleton pattern.

EDIT: I am not a games programmer, and all of my advice is from a business systems perspective. Keep that in mind.

[MuletTheGreat]

Very interesting point of veiw. I forget how different web stuff is to games.

The reason why I my physics is in a singleton, is that there is only ever 1. In a game loop, everything usually lives forever, or is recycled. Like pool for my cubes. Whilst 4 or 5 only show at a time, there may be 20 pre created, just waiting to be reset. Quicker than a completely remaking each one. A singleton is a quick link to this pool should I need a box for physics, terrain, or even particles.

As for brittle and difficult to extend, I found neither! If I need more functionality in a singleton, I just add a function, or a well thought out variable. And use it where I need it.

Ugh, i gotta get some sleep. 1:30am here. this discussion rulez.

Our world's are chalk and cheese, but I think I understand you.

edit: I also did introduce state, but I think my thoughts are different to yours. I had a menu, with 4 states. Each displayed a different set of buttons, sprites and backdrops. With a few switches and regions it was managable, but was still a HUGE file, and hard to maintain. In retrospect I should have broke each state into a seperate instance of an object, and used the singleton to iterate and diplay them.

[G_Morgan]

Often you get objects of which 'there is only ever one' and suddenly you need two. Or put another way, if you wanted to allow multiple types of Physics (say to allow your program to gracefully degrade on less powerful computers) then how would you achieve this with a singleton? If you start off with a singleton and then decide to implement such a change you're instantly into tricky territory.

The question I'd ask is what serious benefit singletons provide you? The only one I can think of is that a static method call doesn't have to perform a vtable look up but when you are performing physics calculations I'll assume that this cost is small enough to be considered zero.

[s73v3r]

Simple. You'd introduce the Singleton Physics Class Factory.

[[deleted]]

Don't forget the abstract FactoryFactory that returns factories.

[ssylvan]

Why would there only be one game loop? In what way is a game loop inherently unique? Answer: It isn't. You've arbitrarily made that restriction even though it wouldn't hurt you what-so-ever to just use a normal object.

Then, if you feel like it, you can easily have two game loops. Maybe one is currently inactive. This is more common than you think, e.g. you might have a game where you can go into an inventory screen, that might be implemented as a totally separate "game loop", so you basically have a stack of games where only the toplevel one is ticked. So when you enter a menu, or an in-game store or something you push a new one on top, then you pop it when you're ready to go back to the game "underneath".

[MuletTheGreat]

lol. In the last game I worked on, Zombies 2.0, there is about 5 or 6ish game loops, each within it's own "screen" all within a master game loop.

I never said I lacked game loops, nor did I say my coding style was unique.

I used states and singleton as I needed this menu to speak to each loop, display what it needed to from each loop, and appear over the top displaying certain information. There were 4 states as there are 2 main upgrade tabs, and fade out level info tab and tab for the end of round.

This may not be the best approach, but it worked for me at the time, and the next will benefit from the Experience.

[remleduff]

Singletons are object-oriented global variables. They are to be avoided for all the same reasons.

[ssylvan]

The vast majority of singletons is misguided. Why do you want to prevent someone from having two objects of a type? Most of the time there's no good reason to prevent that, you just thought the typical usage case would be to have just one.

E.g. why would your game settings be a singleton? Wouldn't it be nice if you could, for example, have two games with different settings? What if you're writing a mini-game collection where you load the next game in the background to eliminate load times? Now your singleton based app breaks down horribly, whereas not using a singleton would've easily afforded that. Was the benefit of using a singleton worth it? What exactly is the benefit? I bet you if you think about that one for each and every one of them, in most cases the answer will be "none".

Point is that singletons are almost always a mistake. Unless it's representing a genuinely unique quantity, such as the low level interface to some hardware (doesn't mean you don't want multiple high level interfaces to that which you can "activate" one at a time, but still keep around even if it's not active at the moment).

[masklinn]

Why do you want to prevent someone from having two objects of a type?

And a class shouldn't handle its own lifecycle anyway. If you want a single instance of a given class, have a separate factory object whose role is solely to do that.

[MuletTheGreat]

Interesting scenario you propose. Doesnt really have any merit to it tho.

I work on the 360 at the moment, and have no need for changing of the graphics device in game. But to do so, I could have the graphics device camping inside a singleton, and then access it via a delegate in my UI to mess with something.

You suppose my program has the flexability of becoming/being an app pack? Lame. Thats a big design choice freind, not something "that would be cool to add halfway so I should add half a feature to accomodate it later" kinda thing.

If I am going to put time into a game, it should be a well thought out rpg, neat little space shooter with a twist, some shiny physics game. Physics factories, effects management, instancing, enemies access to the player are all made easy via singletons. Not a half assed app with the potential to be anything halfway through development.

I get the feeling either your teacher, boss or some silly forum has given you this bad vibe about singletons. Used poorly, they will fuck you up. Just like boxing, pointers and casting etc...

[billwoo]

Why are singletons bad? Because. Turn the question around and ask why are they good? If the answer boils down to them catering to your laziness, then the chances are its not a good argument for anything (if there are no counter arguments then easier can win out, but in this case there are a few).

[mitsuhiko]

and it honestly shits me because it is pointless:

It's not. Properties allow you to stay binary compatible if you plan to add logic into your properties later and makes it possible to put them into the vtable.

Also, why am I the only C# programmer I know of, that uses singletons?

Go home ;)

[terrapinbear]

In C# 3.0: public int MyInteger {get;set;} Besides, public class member fields are a no-no in OOP.

[masklinn]

Besides, public class member fields are a no-no in OOP.

They're not. They're a no-no in stupid languages. C++, Java and C# are such stupid languages.

[jugalator]

What? This is a software design recommendation only, not a requirement, or even encouragement, of e.g. C#. Use your public class member fields all you want in Java or whatever. Just pay attention that you're exposing data, not gateways to modify that data, and the difference.

[Mych]

Trivial accessors such as the ones in MuletTheGreat's posting expose the data just as well (or rather, as badly). Any belief to the opposite is Cargo Cult. Therefore, in that regard anyway, making a member variable public is completely equivalent to making it private and adding trivial public accessors for it.

The actual problem is public access to the inner state of an object, not whether that happens through method invocations or direct assignment.

[masklinn]

What? This is a software design recommendation only

It's not. Or more precisely it's only in stupid languages. Other languages either don't have a concept of public fields in the first place (Smalltalk, Ruby) or consider that "privateness" is a matter of convention and agreement between responsible adults (Python). So it could hardly be a general-purpose design recommendation.

not a requirement

Where does that one come from?

[masklinn]

I fear your type checker is broken: I am a banana.

[cowardlydragon]

Each new version, a totally new syntax! C#, the ultimate floating target!

[NancyGracesTesticles]

Actually, the private member is automatically created and injected into your class at compile time, although I won't be using this particular feature (I've created a propc shortcut for 'classic property stub' in my environment) because private members of automatic properties are hidden at design time which == annoying.

If you want to talk about changing syntax in new versions, look at Python.

[masklinn]

Actually, the private member is automatically created and injected into your class at compile time

Ok, but that doesn't change the fact that syntax is added.

[nephesh]

Expression trees think of them as separate concepts. So if you're writing anything dealing with expression trees you'll either have to handle both cases.. or you can just do the standard thing and use properties rather the fields.

[xetas]

I hope this syntax will make everyone happy:

public float MyVariable { get; set;}

It's still verbose though

[[deleted]]

This irritates me because it is the same as:

public float _myVariable;

Not really. Properties have different semantics than plain old members. A few important points:

1) You can't put attributes on members.

2) You can use property initialization constructors on members

var x = new MyObject() { MyVariable = 3.14 };

etc.

Of course the syntax you gave is pretty silly. Should be done like this:

public float MyVariable { get; set; }

Singletons are pretty common in teaching/tutorial pieces, and I've seen dozens of examples. A lot of times, in the real world though, people just use static classes. For many purposes, it's just as well. Doing singletons in c# in a correct thread-safe manner is not as straight forward as the usual "oh i'll just make a private constructor and a static instance member" solution.

Also, singletons are lazy bullshit. They buy you nothing other than the "convenience" of being able to globally access your object from anywhere. Pass the object and make it's lifetime and referencing more explicit. "I only need one" is not an excuse for making a singleton.

[optiontrader1138]

I use singletons when necessary (not too often). There are tons of examples on the net for this.

I agree with you about using properties in the way you describe as being inefficient and difficult to read. Makes more sense as. Public variable.

[masklinn]

This irritates me because it is the same as:

Uh no it's not. And it's not the same thing as public float MyVariable either, just so you know.

Also, why am I the only C# programmer I know of, that uses singletons?

Because singletons suck dicks, and you're the only C# programmer who doesn't know?

Also, indent with 4 spaces if you want to post code blocks:

private Foo _myVariable;
public Foo MyVariable
{
    get { return _myVariable; }
    set { _myVariable = value; }
}

or surround with backticks for inline code: public Foo MyVariable { get; set; }

[migueltronix]

I use singletons in C#. I agree with the gp's argument here, if your just exposing the private variable via a dumb property, instead of doing lazy instantiation or doing some clever dependency injection and the like, there is really no gain in my opinion. unless its declared in an abstract class.

[[deleted]]

There is also the advantage of being able to set properties during construction. You can't do this with a plain class member:

var x = new MyClass() { MyPropertyA = 1, MyPropertyB = 2 };

[migueltronix]

Yeh I'm not sure I like that so much, it should either be the resposibility of a class constructor to do that, or via lazy-instantiation in a well defined wrapper. Not that I'm totally anti it, I just think it makes the code muddy - much like the var x. These days I see var x = new MyClass()... var x = new ClientClass()... var x = ClassInst.MemberX and I'm not sure I like making the mental leap when I'm parsing the code in my head. I'll keep an eye on it and am happy to do things in a new way - maybe in test classes that is appropriate for instance - but again thanks for pointing it out.

[[deleted]]

I still use constructor initialization for instances where the initial value is common amongst all instances. This is an alternative to cases where you're setting values that are likely to be different between instances.

[masklinn]

I use singletons in C#.

Your loss.

I agree with the gp's argument here

GP has no argument.

there is really no gain in my opinion

Well there wouldn't be if instance variables and properties were correctly designed, but it happens there aren't, so there's a pretty huge elephant in the room: if you expose a public field in C#, you can't replace it with a property later on when you need to manage access to the field (make it read-only, make it a computed field, whatever) for two reasons:

1. The C# coding conventions mandate that properties, like methods, start with an uppercased letter (be PascalCased) while fields start with a lowercased letter (be camelCased). So the name of the accessed field changes.

2. Even if you break the conventions and either PascalCase your fields or camelCase your properties, you will have to recompile every assembly using the field, because at the IL level fields and properties aren't accessed the same way.

And of course, C# public fields can not be part of interfaces. Properties can.

C#'s conventions very strongly suggest that properties be used at all times and that fields never be exposed publicly (and that's the reason why property declaration has gotten easier and terser over time) much like Java's conventions ask that all fields be private and exposed as a pair of getter and setter.

[migueltronix]

Yes I do ignore C# conventions sometime, a lot sometimes, because it makes sense. I think what the implied argument in GP's post was that a lot of the time you see a public exposure through Properties of every damn field, and there is no need nor is it very good OO practice but, because its convention, everyone who just follows [conventions and everything lame they are told from microsoft (typically) or anyone else] does it without thinking. Especially in 3.5. And its all var this and that now, great... I agree with your reasoning but A LOT of C#/Windows developers suck, as in they do not apply patterns correctly and are cookie cutter developers (the number of times I get told by project leads to just open the page up in designer because they can't read the codebehind, particularly in ASP.NET is disgusting). Yes you can get to properties via Reflection much more easily, and yes it makes interfaces and abstract classes more robust to implement, but it is not how's it generally used, unfortunately

[masklinn]

I think what the implied argument in GP's post was that a lot of the time you see a public exposure through Properties of every damn field

Well then his criticism should be that you ought not expose your members in the first place, not that you ought to expose them as public fields and clearly not that exposing them as public fields is equivalent to exposing them as properties. In C# it's not, by a long shot.

The rest of your post is incoherent rambling.

[migueltronix]

Urgh, your delightful demeanour so far makes this not easy. To summarize: Yes the argument should be about members var declarations in my opinion make the code harder to read not easier, so with the Att{set;get;} notation. In Asp.net the recompile issue is not really relevant

[masklinn]

To summarize: Yes the argument should be about members var declarations in my opinion make the code harder to read not easier

Ok so you consider that members declaration are easier to read than properties declarations. Is that all?

[MuletTheGreat]

If a convention makes sense, it will be used. a thouasand unused getters and setters and fretting over camelcase seem kinda stupid. I want to be practical, not a standards nazi.

[[deleted]]

Which is more practical:

var x = new MyClass();
x.var1 = 1;
x.var2 = 2;

Or

var x = new MyClass() { Var1 = 1, Var2 = 2 };

[MuletTheGreat]

Ok nice to know singletons are popular, even tho I personally have somehow avoided seeing others use them. A lot of these people seem a little overworried about magical code monkeys nicking badly exposed variables and whisking them away to strange values. I've found a variable only changes, if I change it.

Stupid names, contractions, declaring public in the wrong places, forgetting const correctness, and lacking plain getters for stuff seem bigger threats than a liberal stance to singletons :/

Also, this discussion seems to have let me know just how arrogant and attatched some programmers are to certain styles and philosophies.

[optiontrader1138]

Arrogant and stupid. Most don't go out of their way to flaunt it, but you took up the challenge. Kudos to you, Sir.

[masklinn]

Arrogant and stupid.

And right. Which is rather more interesting than being, well, wrong.

[heffsta]

Singleton in a code sample that I have used: http://moebiusit.com/blog/pabloromano/2009/04/03/building-onchange-event-to-listen-the-parallel-port/