C# Learning Curve
-
Can anyone give me an idea of what their learning curve was with C# for someone with a strong C++ background already? Thanks
Very short, really take a look at the material available online and you will see, it shouldn't take you too long. :) -Nick Parker
-
Can anyone give me an idea of what their learning curve was with C# for someone with a strong C++ background already? Thanks
C# as a language - very low. There a re a few nifties you should know before doing serious stuff - sitting down with a C# book for an afternoon or two should give you an idea. However, you won't be able to capitalize much prior MFC / Win32 knowledge. If you e.g. plan to do some Windows Forms aplicaiton, it will be a little PITA to hunt around the namespaces to see which class implements the funcitonality you're looking for. (There's a namespace lookup tool with the SDK, it makes things much easier) However, once you're used to it, it's ok.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen -
C# as a language - very low. There a re a few nifties you should know before doing serious stuff - sitting down with a C# book for an afternoon or two should give you an idea. However, you won't be able to capitalize much prior MFC / Win32 knowledge. If you e.g. plan to do some Windows Forms aplicaiton, it will be a little PITA to hunt around the namespaces to see which class implements the funcitonality you're looking for. (There's a namespace lookup tool with the SDK, it makes things much easier) However, once you're used to it, it's ok.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenpeterchen wrote: C# as a language - very low Agree, as in its quick to learn, on the other hand the .NET Framework is big , I'm still finding new overlooked methods everday after a year now :) I did a bit of Jaba before that, so it was is relatively easy.
-
Can anyone give me an idea of what their learning curve was with C# for someone with a strong C++ background already? Thanks
Yep, as mentioned the learning curve for C# is not very bad although there is tons of "gotcha"s. After working with C# for about a year I just noticed today that you cannot use static variables in methods, that have to be defined in the class. I would recommmed you look for a good book on C# from a C++ point of view. The .NET Framework though is the roughest part. I think there is something like 8,000 classes in the .NET Framework. It is no wonder most people are still learning. There is also a lot of programming concepts that change. I know I used to hesitate to break things up into DLLs. Too much hassle to use all the time. Now with .NET I often break up a program into many modules that allow me to work in a more componentized method. One last point, with .NET there are so many ways to go about doing something that I find I spend more time trying to figure out the most logical choice. It might help to do some checking into the "best practices" for coding. Opps.. Going one more.. Now that it is frowned upon to use hungarian notation, it becomes less clear on the proper way to label things. Most of the time it is like Java where you first letter caps except for the first word. But there are several different camps on style nowadays. Some still use "m_" prefixes for member variables while others have picked up a format that reminds me of the old assembler days where they prefix member variables with a single underscore (yuck). Some use the "this." to prefix member variables in usage (I think just so that they can use the intellisense ;) ). The road is good once you get past the pain of letter go ;) Rocky Moore <><
-
Yep, as mentioned the learning curve for C# is not very bad although there is tons of "gotcha"s. After working with C# for about a year I just noticed today that you cannot use static variables in methods, that have to be defined in the class. I would recommmed you look for a good book on C# from a C++ point of view. The .NET Framework though is the roughest part. I think there is something like 8,000 classes in the .NET Framework. It is no wonder most people are still learning. There is also a lot of programming concepts that change. I know I used to hesitate to break things up into DLLs. Too much hassle to use all the time. Now with .NET I often break up a program into many modules that allow me to work in a more componentized method. One last point, with .NET there are so many ways to go about doing something that I find I spend more time trying to figure out the most logical choice. It might help to do some checking into the "best practices" for coding. Opps.. Going one more.. Now that it is frowned upon to use hungarian notation, it becomes less clear on the proper way to label things. Most of the time it is like Java where you first letter caps except for the first word. But there are several different camps on style nowadays. Some still use "m_" prefixes for member variables while others have picked up a format that reminds me of the old assembler days where they prefix member variables with a single underscore (yuck). Some use the "this." to prefix member variables in usage (I think just so that they can use the intellisense ;) ). The road is good once you get past the pain of letter go ;) Rocky Moore <><
The style I use, which is (or was) adopted from MS's recommended style: Uppercase first letter of each word on method names and properties. camelCase* local variables and method arguments. camelCase private member-variables in a class. If you have an abbreviation, that would normally be all capitalized and it is only 2 or 3 letters long, then only the first letter gets capitalized (to fit in with MS's naming of the Sql* and OleDb* classes). I don't always follow this one, especially when I have something like CustomerID. Putting a lowercase 'd' there just looks wrong. No m_ or _ for private variables. Constants/readonly variables have uppercase first letter for each word. *camelCase means to capitalize the first letter of each word, except the first, also Java style. Rocky Moore wrote: Some use the "this." to prefix member variables in usage (I think just so that they can use the intellisense ). It depends, if you have a private member variable named
myVariableand you need to use that variable in a method which has a local variable or argument,myVariable. To access the private member you need to prefix the name withthis.otherwise you access the argument/local variable. Typically you see this with arguments because (to me) having a local variable of the same name just seems wrong. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him -
The style I use, which is (or was) adopted from MS's recommended style: Uppercase first letter of each word on method names and properties. camelCase* local variables and method arguments. camelCase private member-variables in a class. If you have an abbreviation, that would normally be all capitalized and it is only 2 or 3 letters long, then only the first letter gets capitalized (to fit in with MS's naming of the Sql* and OleDb* classes). I don't always follow this one, especially when I have something like CustomerID. Putting a lowercase 'd' there just looks wrong. No m_ or _ for private variables. Constants/readonly variables have uppercase first letter for each word. *camelCase means to capitalize the first letter of each word, except the first, also Java style. Rocky Moore wrote: Some use the "this." to prefix member variables in usage (I think just so that they can use the intellisense ). It depends, if you have a private member variable named
myVariableand you need to use that variable in a method which has a local variable or argument,myVariable. To access the private member you need to prefix the name withthis.otherwise you access the argument/local variable. Typically you see this with arguments because (to me) having a local variable of the same name just seems wrong. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with himJames T. Johnson wrote: The style I use, which is (or was) adopted from MS's recommended style: Well, a lot of code from Microsoft still has underlining. Seems many still are not with the program ;) This is the style I have used since I started but I have ran into a little problem with this though. If you have a private variable called "customerID" and you have a property called "CustomerID", when you build a contructor and pass in a varible, it looks off to have a parameter "customerID" and be forced to use the "this." in front of the member variable. That is the only I have found where some prefix on member variables could be a good thing. One of my other pet peeves is that C# does not allow private variables at method level. I know it is not that big of thing to have them declared at class level and some people reason that it should be declared there to make it more obvious that it exists. Personally, I think the knowledge of the variable should only be at the method level, nothing outside the method should know or have access to the variable. But I understand that "static" does not quite mean the same thing as it did in our C++ world. James T. Johnson wrote: I don't always follow this one, especially when I have something like CustomerID. Putting a lowercase 'd' there just looks wrong. I agree with that. I still use "customer_ID" in mine which is the only time I use an underline. Rocky Moore <><
-
The style I use, which is (or was) adopted from MS's recommended style: Uppercase first letter of each word on method names and properties. camelCase* local variables and method arguments. camelCase private member-variables in a class. If you have an abbreviation, that would normally be all capitalized and it is only 2 or 3 letters long, then only the first letter gets capitalized (to fit in with MS's naming of the Sql* and OleDb* classes). I don't always follow this one, especially when I have something like CustomerID. Putting a lowercase 'd' there just looks wrong. No m_ or _ for private variables. Constants/readonly variables have uppercase first letter for each word. *camelCase means to capitalize the first letter of each word, except the first, also Java style. Rocky Moore wrote: Some use the "this." to prefix member variables in usage (I think just so that they can use the intellisense ). It depends, if you have a private member variable named
myVariableand you need to use that variable in a method which has a local variable or argument,myVariable. To access the private member you need to prefix the name withthis.otherwise you access the argument/local variable. Typically you see this with arguments because (to me) having a local variable of the same name just seems wrong. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with himJames T. Johnson wrote: If you have an abbreviation, that would normally be all capitalized and it is only 2 or 3 letters long, Actually, that only applies if it's three letters long like
System.XmlIf it's two letters long, both are capitalized, likeSystem.IOso your CustomerID is fine. :)
Hawaian shirts and shorts work too in Summer. People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage... -Anna-Jayne Metcalfe on Paintballing