C# windows search and move

[semaphore]

var ignorePersonStirringKak = true;
var kakStirrer = new Person("semaphore");
if(ignorePersonStirringKak)
   KakUitsorteerder.Ignore(kakStirrer);

In other words - probably

It was a valid question. I find it makes code unreadable without having to hover over the var to see its inferred type.

 

[Hamster]

It was a valid question. I find it makes code unreadable without having to hover over the var to see its inferred type.

Separate discussion. Personally I don't find it difficult to read at all. I just hate it when you have generated classes with very long names and people do this:

AGeneratedSubClassOfASubClassOfAnotherClassOfAnXSD option = new AGeneratedSubClassOfASubClassOfAnotherClassOfAnXSD ();

 

[_kabal_]

var ignorePersonStirringKak = true;
var kakStirrer = new Person("semaphore");
if(ignorePersonStirringKak)
   KakUitsorteerder.Ignore(kakStirrer);

In other words - yes

c# allows you do to this?

can you do:

var firstName = "bob";
firstname = 123;

 

[semaphore]

c# allows you do to this?

can you do:

var firstName = "bob";
firstname = 123;

You cannot change the inferred type after compilation. Unless you use the dynamic keyword.

 

[semaphore]

Separate discussion. Personally I don't find it difficult to read at all. I just hate it when you have generated classes with very long names and people do this:

AGeneratedSubClassOfASubClassOfAnotherClassOfAnXSD option = new AGeneratedSubClassOfASubClassOfAnotherClassOfAnXSD ();

In that case you know the end type. Nm. There are different groups to this type of syntactic sugar.

 

[_kabal_]

You cannot change the inferred type after compilation. Unless you use the dynamic keyword.

At least that is slightly less vomit worthy then


Hamster, you must have hated java 6 generics

List<String> strings = new ArrayList<String>();

at least it improved in 7:

List<String> strings = new ArrayList<>();

 

[semaphore]

At least that is slightly less vomit worthy then


Hamster, you must have hated java 6 generics

List<String> strings = new ArrayList<String>();

at least it improved in 7:

List<String> strings = new ArrayList<>();

He doesnt do java.

 

[Hamster]

He doesnt do java.

Actually did some work in Java 7 for Treasury - that's not generics In the words of "Al", Java is C# Beta

 

[semaphore]

Actually did some work in Java 7 for Treasury - that's not generics In the words of "Al", Java is C# Beta

Java 8 is nice using that a bit now days.

 

[Hamster]

Java 8 is nice using that a bit now days.

From what I can tell of the stuff they showed us in a TI session it wasn't too impressive. Maybe the samples were bad but it looked like they made it easier for developers to code but harder to read that code afterwards. And those interfaces with default implementations :wtf: Isn't that just an abstract class?!?

 

[_kabal_]

Actually did some work in Java 7 for Treasury - that's not generics In the words of "Al", Java is C# Beta

well 90% of your daily interaction with generics is via collections.

So I will change my statement.

You must have hated java 6's lack of generic type inference, on the right hand side

 

[Bar0n]

thnx for the advice, used the file.exists delete

If it exists, delete it, then copy the new one in??? Never do that. Just because file names are the same does not mean the contents are.

And use recursion, otherwise you'll always go only one directory deep to find your files. With recursion, you can traverse your entire hard drive.

 

[Bar0n]

So do you use var for every simple piece of code?

Not unless you're a JavaScript programmer.

From Eric Lippert, a Senior Software Design Engineer on the C# team:

Why was the var keyword introduced?

There are two reasons, one which exists today, one which will crop up in 3.0.

The first reason is that this code is incredibly ugly because of all the redundancy:

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

And that's a simple example – I've written worse. Any time you're forced to type exactly the same thing twice, that's a redundancy that we can remove. Much nicer to write

var mylists = new Dictionary<string,List<int>>();

and let the compiler figure out what the type is based on the assignment.

Second, C# 3.0 introduces anonymous types. Since anonymous types by definition have no names, you need to be able to infer the type of the variable from the initializing expression if its type is anonymous.

So no, you should definitely not start putting standard ints and strings in vars.

 

[semaphore]

Not unless you're a JavaScript programmer.

From Eric Lippert, a Senior Software Design Engineer on the C# team:


So no, you should definitely not start putting standard ints and strings in vars.

Yep read that post a few months back.

And to add to your javascript, one of the reasons to use the var keyword is to prevent the variable becoming global.

However typescript allows you to define types as such:

var isDone: boolean = false;

 

[Hamster]

So no, you should definitely not start putting standard ints and strings in vars.

Well it is there now so I am going to misuse it to my heart's content! MWHAHAHAHA! :twisted:

 

[Bar0n]

Well it is there now so I am going to misuse it to my heart's content! MWHAHAHAHA! :twisted:

Nothing prevents you, but it's not GPP according to C# conventions/standards.

Also, there is ambiguity when declaring simple types, i.e. "var x = 3;". Is var of type int, double, short, byte, etc? If you were given code on paper or on a blog where there is no intellisense, is it still clear what the code means and which data types are used? That's the ultimate test of properly written code, I would say. No ambiguity, regardless of scenario/environment.

 

[semaphore]

Nothing prevents you, but it's not GPP according to C# conventions/standards.

Also, there is ambiguity when declaring simple types, i.e. "var x = 3;". Is var of type int, double, short, byte, etc? If you were given code on paper or on a blog where there is no intellisense, is it still clear what the code means and which data types are used? That's the ultimate test of properly written code, I would say. No ambiguity, regardless of scenario/environment.

Don't argue hes on a team that promote this type of development

 

[Bar0n]

Don't argue hes on a team that promote this type of development

Doesn't mean it's the right way to code. It's unconventional, not GPP according to C# standards, and ambiguous unless working with Visual Studio and hovering over the variables / function return types.

 

[semaphore]

Doesn't mean it's the right way to code. It's unconventional, not GPP according to C# standards, and ambiguous unless working with Visual Studio and hovering over the variables / function return types.

Did i say it was the right way ? Perhaps read between the lines. I am very much against var.

 

[Bar0n]

Did i say it was the right way ? Perhaps read between the lines. I am very much against var.

var has its place. It's very useful, but should be constrained in use to its original purpose.