|
W∴ Balboos wrote: Would you, in your partial disagreement, agree that the syntax, at the basic level, is such that it's almost automatic that one knows C# if one know C++ (new layers of convolution notwithstanding)?
That's a difficult one, because moving from C++ to C# isn't necessarily as easy as you think it will be just by looking at the syntax.
I came up the COBOL -> FORTRAN -> Pascal -> Assembler => C -> C++ -> C# route, and it's the superficial similarities that throw you off: you expect to need pointers and they aren't there. Same for globals, and references, and all the little nuances that you get used to in C++. So you end up trying to use C# as a "retarded brother" to C++ instead of a separate language in it's own right that shares some syntax with C++. You are actually better off forgetting C++ completely when you learn C# I think.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
At least there's nothing you're forced to use. You can keep coding using a .NET 2.0 style even though you're developing against the latest library, and the latest language features are at your disposal--which you can choose to ignore. The way it's once been described to me is that it's all "syntactic sugar".
Or am I misinterpreting what you mean?
|
|
|
|
|
Yes you can - but not everyone else will, so you get a lot of lazy coders using var all the time for example and to hell with the poor sod who has to maintain it in six months time!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Of all the useless things that have been added to the language over the years, var isn't one of them. I've long been opposed to var myself, but these days, when I see I've used var in some of my older code, it generally means the exact type didn't matter to me back then, and it still shouldn't matter to me today.
Some will abuse it for sure. But it's got its use.
|
|
|
|
|
It has it's uses - you can;t do Linq without it - but when you get lazy f'wits using it on every variable definition it's a PITA for maintenance:
var i = 666; Is just lazy.
var p = ComplicatedFunctionInAnotherClass(long, list, of, parameters); Is lazy, stupid, and uncaring of maintenance or the poor sod who will have to do it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: t has it's uses - you can;t do Linq without it
Linq is itself too often used/abused when often it's really not necessary at all, it's backward syntax order is a PITA for those of us that work in multiple languages and later need to unravel some newbies 'I can do it all in one line' compound statements. I'd not loose a second sleep if it were removed entirely.
signature upgrading ... please wait.
|
|
|
|
|
I completely agree on the syntax - that's why I use the methods instead - but Linq does have some advantages over the "loads of loops" approach!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Agreed! Linq makes things easier to write, easier to maintain, easier to understand, and just makes code 'prettier'. I cannot stand ugly code!
|
|
|
|
|
Does linq make the code more readable to the next programmer who picks up your code? If the linq covers a simple loop with some decisions inside which will be easier for the next person who maintains the code? Writing code for an organization with multiple programmers and engineers, not only must your code perform what is intended without breaking, but must be as quickly understandable by the next person who pick up the code. Because, you can be sure that your code will change as the customer needs change.
|
|
|
|
|
I agree with using a var for what clearly should be an int. Or should it be a long? Or a 64-bit unsigned int?
As for your 'p' example--it all depends on what you do with it next. If you just need to hang on to it so you can eventually return it from the current function, or to pass it as a param to another function, then under those circumstances I'd say the exact type shouldn't matter to a reader.
|
|
|
|
|
The first example is OK. I as a maintaining programmer know that i will be an int of some sort. The second example, what is p? Do I have to look at the function or intellisense to figure it out? Do I need to look at the context of how p is used later? No to all of these. The professional engineer's job is to not only make the product work as expected but to also make it easier for the next engineer to pick up the work and take it to the next step. (It's in the IEEE code of ethics.) It would seem that is the difference between a programmer/code jockey and an engineer.
|
|
|
|
|
OriginalGriff wrote: C# needs to be ripped apart and the same exercise done again
Couldn't agree more. It's getting so bloated and ugly that it's starting to look like C++.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Actually, they simplified C++, as did Java. C++ was getting quite complicated and watching Bjarne Stroustrup running through the variations of template examples was enough to make your head swim. Both Java and C# are good attempts to simplify what C++ has become. Also, most people decided to take up C# because of the pointer problems with C++. Too many times, a raw pointer would be missed or deleted too soon and problems would arise. This was occurring in much larger programs. So, I am happy (so far) with C#.
|
|
|
|
|
I'd also agree on "C# in a Nutshell" by Joseph and Ben Albahari. If you ever really want to take a deep dive into C# and the CLR I highly recommend "CLR via C#" by Jeffrey Richter. In the meantime though, the Microsoft Docs on C#[^] are quite good to start off with
|
|
|
|
|
Jon McKee wrote: "CLR via C#"
This book is awesome. Must read for an in depth understanding of C# on top of .net.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
This is the best choice, especially if you're coming from native c++. You need to learn not just the c# language, but how to use it effectively on the .net platform. I also came from c++ to c# via this book.
|
|
|
|
|
Always read the spec. Anything else is wrong.
|
|
|
|
|
So you are wrong
|
|
|
|
|
|
|
Programming in the key of C# by Charles Petzold is excellent, especially when coming from older C-family languages
|
|
|
|
|
I know this is not exactly an answer to your question, but I would warmly recommend the following:
1) Job interview questions as by far the best source of condensed information about very handy C# features. A 100 questions interview is worth 314 pages in a book.
2) F..k Occam's razor. Complicate! Go to Stack Exchange and check three solutions to your problem, even if you know how to solve it. It helps build your skills beyond trivial.
3) Twitter for practicing code optimization.
|
|
|
|
|
If you want something that starts at the core of C# and - to a degree - programming, I'll have to recommend Rob Miles' Yellow Book[^]. It certainly helped me learn C# quite thoroughly, although I'll have to admit that he was one of my lecturers when I attended university.
|
|
|
|
|
|
Hi,
I have had good luck with the "Dummies" books. I needed to learn C++ in two days and the "Dummies" book was right on target. I also got a lot of value from the Python "Dummies" book. Try C# for Dummies.
|
|
|
|