When your variable naming is on point

George4 is best

I would research and link if i wasn't on cell with horrible internet but basically the character's sprite brush was drawn before he was named, so they saved the file as 'guybrush' and it stuck. There's some kind of origin story for Threepwood too but I don't remember off hand what it is. I'll look it up when I get off work.....

[edit] From Wikipedia:

The origin of the name "Guybrush" comes in part from Deluxe Paint, the tool used by the artists to create the character sprite. Since the character had no name at this point, the file was simply called 'Guy'. When the file was saved, Steve Purcell, the artist responsible for the sprite, added 'brush' to the filename, indicating that it was the Deluxe Paint "brush file" for the "Guy" sprite. The file name was then "guybrush.bbm", so the developers eventually just started referring to this unnamed 'Guy' as "Guybrush".[2][3]

And the surname:

Guybrush's surname "Threepwood" was decided upon in a company contest and is derived from P. G. Wodehouse's family of characters including Galahad Threepwood and Freddie Threepwood (with whom he shares similar characteristics).

https://en.wikipedia.org/wiki/Guybrush_Threepwood

An implementation of the Factory Pattern using a static class.

https://en.wikipedia.org/wiki/Factory_method_pattern

For example:

public static class EnemyFactory
{
    private static Enemy ScaryEnemy()
    {
        [insert complicated algoritm to get constructor params here]
        return new ScaryEnemy(params) as Enemy;
    }
    private static Enemy WeakEnemy()
    {
        [insert complicated algoritm to get constructor params here]
        return new ScaryEnemy(params) as Enemy;
    }
    public static List<Enemy> MakeMob(numberOfWeakEnemies, numberOfScaryEnemies)
    {
        var result = new List<Enemy>();
        [iterate the private factory me thods, adding to result]
        return result;
    }
}

This is an example of what I would describe as a static factory class. It is a static class (obviously) which has factory methods.

Why are you questioning my common sense? Do you not understand OO design patterns?

There are four cornerstones and five principles which describe robust OO code (C# is a primarly OO language which supports FP as well).

The four cornerstones of Object Oriented Programming are Encapsulation, Abstraction, Polymorphism, and Inheritance (Thanks, /u/LyonesGamer, for pointing out my typo).

The five guiding principles are SOLID: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

My approach is justified because it exemplifies encapsulation, abstraction, and single responsibility by letting a generic class (List) handle the inevitable management of the collection.

This approach, while technically valid, is going to be a real pain in the ass later. It makes iterative programming almost impossible. If we use a collection, we can quickly iterate and filter it. Trust me on this, you will thank me later.

There are infinite reasons to use iterable data structures to store groups of objects which have a common purpose. For example, suppose that you want all enemies within 10 meters of the player to aggro on him. With your approach, you would need to write something like this:

if(Physics.Distance(Enemy1, Player) < 10) {
    Enemy1.Attack(Player);    
}

if(Physics.Distance(Enemy2, Player) < 10) {
    Enemy2.Attack(Player);    
}    

if(Physics.Distance(Enemy3, Player) < 10) {
    Enemy3.Attack(Player);    
}

if(Physics.Distance(Enemy4, Player) < 10) {
    Enemy4.Attack(Player);    
}

This alone is tedious as fuck! Imagine implementing aggro chaining (so all enemies in a cluster attack when the player gets in range of one). That would be almost impossibly tedious, and your source code would bloat soooo much.

If we use an iterative approach, we can write objectively better code to solve the same task (less development time, more maintainability, more extensibility):

Enemies.Where(enemy => Physics.Distance(enemy, Player) < 10).ForEach(enemy=>enemy.Attack(Player);

Or without LINQ (because not everyone likes functional programming):

for(Enemy e in Enemies) {
    if(Physics.Distance(enemy, Player) < 10) {
        e.Attack(Player);
    }
}

The approriate place to use a singular type is when we are working with a singular object.

The appropriate place to use a collection type is when we are working with a collection.

TL;DR: If you use tools appropriately, you will be a lot more productive. Use collections to handle groups of similar objects. Use singular types to handle individual instances. Microsoft has written some incredible tooling for the .NET Framework -- embrace it!

He's brandishing a knife, it's shia /u/leBoef

It's terrible on mobile. :(

That's awesome

Dude, your website breaks if you use the back button. Stop using JS magic.

Privacy Badger extension makes the site look like crap.

I bound it to a keybind and pressed it. I still haven't received a screen shot of my friend's monitor though. What did I do wrong?

Alternatively:

1. Install ShareX
2. Hit ctrl+PrtScn
3. Mark what you want
4. Wait for image to be automatically uploaded to imgur
5. The imgur link is now copied to your clipboard

He clearly sent it through text, why would his friend go through that trouble???

Snipping tool automatically saves to clipboard, no need for step 3.

plug for puush

Yeah. Why waste private variables when you don't need to do anything fancy in your getters/setters. Also, this is freaking C#, not JavaScript. Get your camel case right.

So private set is implied? I always wrote this kind of stuff as

public Enemy NumberOne { get; private set; }

I think you mean {get; private set;}. The way you wrote it, the property can only be set by a constructor, and can't be changed in that instance anymore.

That's interesting. I work with a guy who has a degree in CS and ONLY uses the underscore notation (unless a group agrees on something else, of course). It seems like it's preference? You seem to vehemently oppose the notation, but others down below like it.

I use that "stupid notation" everywhere I can. Why? Because if you forget how a member on your class is called, all you have to do is write "_", then ctrl+space and get a quick refresh of all the class members.

Yeah, you have the outline view (Which usually is also cluttered with, well, everything else) and other windows, but I guess is something out of personal preferences.

Of course, if told by my boss to stop bitching around, I will do as told, I'm not going to enter on a fight for a coding convention, just trying to provide a different point of view.

If you are doing anything related to modern desktop ui development in c# (WPF), you are required to back every field with a private member so that you can fire INotifyPropertyChanged in the setter. If you don't, you get no ui updates. If you ever want to have any extended logic besides simply getting/setting, ie lazy loading from a database you want private field backed properties. What would get someone laughed out of my office in this is the public field. No, kill it with fire.

There's a difference between "unnecessarily declaring a private backing field to a public property" and "declaring private members differently from public ones to easily differentiate them from each other." The former is perfectly fine to hate on, but it has nothing to do with prefixing a private member with an underscore.

yeh the whole underscore thing is totally retarded. The whole point of "properties" is they save space. If you start doing the underscore crap you might as well went old school because it doesnt save space anymore.

Thanks! Those makes sense. I mostly know C++ but am trying to branch out into C#. I appreciate the answer.

Qualified functions? What do you mean with that? And my only use for "this" is

void SetAmount(int amount) {
    this.amount = amount;
}

Technically, static refers to the lifetime and scope, not its address. It might be implemented such that static puts it in a separate address space, or might not.

In C#, you can't have static const. It's basically always static by definition. You may be thinking of readonly.

1.) this is a pointer to the current object. Am I missing something?
2.) I know that. But if a class member is constant, is it ever necessary to have to create the member on each instantiation of the class?
3.) Okay.

Yea, which is why I was saying don't use public vars

He used the name 'NumberOne' for a variable which isn't a very good name unless it stores the value '1'.

Thus I made a joke about it.

It was a terrible joke made worse by having to explain it.

Something similar to factorio

What is horrifying on static classes? Is good for global variables and stuff.

It's Unity.

The correct solution is to use a ScriptableObject - this saves data in YAML.

I really hate how Unity has no structure whatsoever. UE4 is much better in that sense. Tons of good structure that you can easily understand. Still has a component system but it's not insanely free and open.

In UE4 for things like that we have level blueprints and can adjust everything placed in a level by instance but our "level object" is the scene. You can't not have a level object because it defines the level.

Isn't that exactly what he's doing here? Level15 extends the class Level.

Yeah i probably would have let it slide if not for that comment :/

I see what you did there.

Yeah! It's a stealth survival game:) We have physically modeled reverb, occlusion and diffraction. We also use tools like wwise so working through an engine like unity allows us to easily have multiplatform support while the use of external tools allow us to have boss audio capabilities since unity kind of has a shitty audio engine.

hey thanks, I didn't know that.

Thank you Thank you! Now I can stop feeling dirty making so many public fields! Private + SerializeField. Thank you kind sir.

Unity's usage of C# is an abortion which uses an old version of Mono, before auto-properties existed. It is an archaic system which uses reflection at runtime in the designer UI to determine user editable properties, and doesn't include properties.

Hopefully now that the .NET framework is open source they'll work on fixing issues that were introduced by using Mono (which was needed for cross platform compilation), but it'll either take a long time or a semi / total rewrite. The only way I see it happening anytime soon is if Microsoft buys Unity (like they did with Xaramin) and decided to properly integrate it into .NET and Visual Studio.

Good call, just gave that stuff a read.

Unity can be a somewhat special case of C#, although I'm pretty sure it still supports properties. Their implementation of JavaScript is... Interesting, to say the least.

Link please, I wonder why that is.

And it's the first thing I change when installing ReSharper

In some other languages, like JavaScript, it's standard to have it on the same line. It just depends what language you're in and the style guides you're working with, but if a developer is used to one language then they might be thrown off when they see another and it's different from how they expect.

:(

TNT

So this is where you Unreal Engine guys are hanging out.