I..
Want..
To murder...
Someone...

Not if I do it first 😡

It might be a dumb question but why?

@gitpush partners in crime, maybe we can share a cell 😂😂😂😇

@Dummybugger 3 different naming styles in one class/file of which one is totally not acceptable as a c# coding convention..

@sladuled 😂😂

@sladuled
Oh crap I didn't notice that yeah that's disgusting 😂😂

I worked with a junior dev before who used to do this and worse. Turned out he was copy / pasting code from stackoverflow and hadn't got the slightest clue what the code was doing in 90% of cases.

I'd smack that shit code out of him quick before it becomes a massive headache

My eyes

Just out if curiosity, how do you enable the reference counter?

@sladuled "...of which one is totally not acceptable as a C# coding convention..." - you mean *two* of which are totally not acceptable as a C# coding convention.

Methods, Classes and Properties should all be Pascal Cased and not Camel Cased (as in the case of pricelistExportMode)

You do find people using Underscore naming conventions in C#, but almost exclusively for descriptive Unit/Integration/Funcional Test methods.

Your solution is not to leave it there; rename those Properties now and if anyone complains point them here: https://docs.microsoft.com/en-us/...

@IceFreak2000 hahha I did.. xD
And thisIsAcceptable if a local variable that helps you solve shit.. but yes, not acceptable for property naming!!

@WhAtEvErYoUmEaN 2bh not sure, i think it's part of the 'you must have theese all enabled to be able to load the project' bundle that I didn't bother to throw out yet..

I stand corrected, it looks like CodeLense is behind this..

Ffs cannot attach img on edits o.O

♪ Two of these are naming violations, two of these are naming violations... ♪

(the second naming style should only be used for variables in C#. But since these are properties, they have the same naming conventions as Classes (so: PascalCase))

@sladuled thank you!

My iris!

Usually I hate when people use curly brackets like that. But it seems unnecessary to put "get" and "set" on their own line(s)

@NoMad 😂😂😂

@NoMad

Just one if they are all in the same head.

@oudalally Not sure about php.. It was written from scratch (copy paste probably) by my ex coworker who had c# in cv.. obviously he heard of it at some point..but I doubt he used it much.. :(

@osx94 yeah, multiple personality disorder would explain a lot in this case.. 😂😂😂😇

@oudalally yes, thankfully ex.. otherwise it'd be a dead ex coworker.. :/

@oudalally & yes, I too was a total noob regarding c# once.. only had one 14day course for VS2005 at my college <- at least I think the 2005 was the new shit back then.. but that doesn't give me the right to just write crappy code without following any conventions.. or say on my CV that I am a VS & c# .net blablabla (insert stuff here) savy, especially if too lazy/stupid/unable to learn new things..

I think I was coding when I thought of my profile name lol 😂

@oudalally Resharper recommends 'var' for everything...

@xorith resharper is weird..

@sladuled

I don't know. My understanding is that var is a better way of doing things. Plus, if you need to know the type of something, you're probably breaking several key principles.

Golang functions in much the same way, and I think it's spot on.

Edit: I should mention that this is for variable declarations in blocks of code, not when declaring a property. Perhaps that's the disconnect.

Could you not enforce a style with precommit hooks and a CI pipeline?

looks like something I wrote :D

@xorith there are upsides and downsides to the whole `var` thing. On one hand everything in JS is var, on the other hand typescript was created to remove that.

You are correct that it should never be used for a property as you should be able to look at the definition of the class and see what it holds / you can access.

To me the same logic applies everywhere though (mostly). If i'm taking over someone else's code and i'm trying to fix a bug and I see:

var result = something.getResult();

Is result an object, an int, a string? Rather than being able to tell by looking at the code I now have to go to the definition of `getResult()` and hope its not also returning var, otherwise I have to read the whole function to understand it.

I think var has its places. I've used it a lot in networking libraries where JSON is being returned and I can't know the mapping type. Outside of something like that, no, I think good clean code should be descriptive and not vague.

@practiseSafeHex

The thing is with C# and doing things the Microsoft Way, you'll be using an IDE with IntelliSense. So you won't need to guess what 'result' is.

Even still, you wouldn't see code like that from me or in this shop. I've been mentored by someone who clean codes in his sleep.

var customer = CustomerQueryObject.Find();

I know what customer is. It's right there in the name. I don't need Customer customer. That's just silly.

Your example with JavaScript and TypeScript is also flawed in the actual functionality of var. In C# var is not a dynamic variable that can change type at will. It's assigned both a type and value. The value can change, the type cannot. So customer will never be a contract later on in the same scope.

Finally, when dealing with generics for polymorphic designs, what is the difference between T and var?

@xorith well I wouldn't start off any argument by saying you do things the Microsoft way (evidence to backup statement: everything since windows XP).

Your naming convention looks good and understandable. But you have an assumption that every developer will always follow the same pattern, or relying on another human to constantly check and modify code. Naming conventions and standards like that are notoriisly difficult to adhere to, and a lot of people will have different views on what makes sense. All it takes is for 1 bad intern to join the team and you will see how frustrating it is to maintain something like that.

I once had to deal with a team of 6 junior devs in a remote office, these plans just don't work unless you have a lot of spare time to devote to it.

Using a linter, you can easily throw warnings for the use of var, Object, any etc. and there you have an automated way of making sure that everything has a readable type, and the benefits of that are far from silly.

@xorith The fact that var is dynamic has nothing to do with the fact that when a human reads the code, its vague. Countless times I've had to read code on stackoverflow or github on a mobile / tablet, trying to debug an issue while traveling and had no access to a full fledged IDE. It hurts nobody to make sure your code is readable just by looking at it.

Polymorphic designs are entirely different. Rather than requiring a concrete type, you can say anything that adheres to interface / protocol X. I have used generics in Swift for exactly the reason of avoiding the use of `any` which is the equivalent of var. I had issues with very similar functions all over the app, all taking in `any` and passing `any` back out. I wrote protocols and super class functions using generics to avoid this so that every call of the function had to specify a named type that conformed to a protocol.

The benefits of this when it came to writing unit tests, and debugging were immense.

@practiseSafeHex

I still have to disagree that 'var' and 'any' are the same. Last I recalled, 'any' can dynamically change type through reassignment. In C# 'var' cannot.

So 'var' is as strongly-typed as using a type name. That basically leaves only opinions. In my opinion, you should name your variables and methods well enough that the type name isn't needed.

Another pro for 'var' is decoupling. When you work on extremely large projects, this is something to keep in mind. Refactoring isn't just something we do because the code is bad. It's a natural evolution of the code we write. Decoupling with 'var' allows for that natural evolution to happen more easily. It's not like you'll accidentally break the signature. The compiler will make sure you don't. :)

@sladuled @oudalally "var cannot be assigned null"

This needs unpacking slightly; the following is invalid code:

var foo = null;

This is because there is no type information that can be inferred from the use of null - so yes, your statement is correct. However

var foo = new Foo();
foo = null;

is also valid, which makes your statement that "if you need to use a null value to check a condition" wrong (or ambiguous at best)

'var' is not a special case type, it's simply a placeholder for a specific type that will be filled in at compile time. It's not a synonym for an 'any' type present in other languages.

@sladuled @WhAtEvErYoUmEaN ReSharper also adds this feature.

@WhAtEvErYoUmEaN It's CodeLense. And you need VS Pro at least.

@DataJockey fuck.
Thank you