Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm coming to C# from java. Java has a set of conventions that make it easy to see the use of an identifier by its casing.
Reading up on the Microsoft conventions it seems like they want you to Pascal case almost everything except parameters. It seems to me this is a much less information rich convention.
Is it really considered bad form in the .NET/Mono world to break this convention and do I just need to get used to it, or can I carry my Java habits over to my C# code that others are going to use?
Well, ultimately it depends on you what you choose. If others are ok with the Java style of naming, you can use it, but I would probably stick to pascal case at least for public members your classes to be consistent with the rest of the language.
ReSharper offers quick way to convert naming conventions be reformatting code, so you might also try to use your learnt ways for new classes and let it perform it's magic before you check in the code for others to see :-) .
Personally I think that the name of the function is far more important than it's casing, as well as it's XML comments. Even if you don't stick to any conventions, nobody will have a problem in using your code as long as these 2 things are in order. And on the other hand - no amount of tradition is going to help with DoMagic2_2(int a, string b, decimal bb). So focus on that and use whatever convention is easier for you.
It all depends on readers of your code. If you're the only one reading it, or the other readers are going to be Java-versed, it might not be a problem. Then again, if your code readers will be more C#y people, your code will look strange to them, and might confuse them.
I recommend going with the convention as it makes your code more civilized. Given that there will be more C# developers reading (or) will be interested in reading your C# code rather than Java developers. For instance, if you want to post things in a blog or a thread like StackOverflow, your code will make more sense / won't look too foreign to corresponding developers if you follow the convention. Also, I believe adapting to a specific convention isn't tough at all. I'm a C# developer and I currently work on Rails, so take my word on it.
I don't find why it should be less information, anyway the casing don't tells everything, but the most information about what you're dealing with comes from the syntax and usage instead. Although I never done any serious Java, so far they're not that different, probably the most notable being the method names being lowercase (Java) vs uppercase (C#).
In any case, they're just conventions, and like any convention, they're to some extent arbitrary. It really depends on what you prefer more, who will have to read your code, and what code is already on the codebase. The most important thing about conventions is to make all the code look the same, in whatever style you/others like.
If you already have code written (by you or by others) and have to modify that, by all means stick to whatever it's already there, just for the sake of consistency. But if starting from scratch, you may either want to decide to follow Java standard for your own comfort or C# standard for ease of reading by others. Or, why not decide with your team on a "middle ground" custom convention?, so that everyone is happy with it.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
First, please no spamming because I am not necessarily an OOP devotee. That said, I have been a programmer on and off for almost 30 years and have created a lot of pretty cool production code systems/solutions in several industries. I've also done my share of break/fix, database development, etc. Even a bout 10 years as a web programmer, not developer, so I an not so much a newbie but someone trying to get an answer about something that frankly is eluding me.
I started as a "C" programmer int he early 1980's and "C" served me well into the early 2000s (even today most scripting and higher level languages use "C" syntactical elements).
That said, overloading seems to violate every principle of what I was taught were "good coding practices" by increasing ambiguity in the opportunity for omission of intended code to be executed for a given condition or actually running a routine you didn't expect to due to some condition falling through the cracks. Also generally seems to creates LOTS of confusion for learners.
I am not saying overloading is bad per se, I just want to better understand it's practical application to real problems other than simply a way to provide input validation or perhaps just to handle inputs from other sources that you have no control over in an API or something else that you don't necessarily know the type of (again not clear on how or why that could actually happen either) C# has a lot of parse and try catch to handle this as do most OOP languages.
In over a decade, I have yet to get a straight, non judgmental and dare I say unsnarky answer to this question. Surely there is someone who can offer a reasonable explanation of why it is used.
So I pose the question to you the stack overflow gurus, Personally, does having a method/function that is potentially callable multiple different ways with multiple exclusive code segments really a good thing, or does it just suggest lack of good planning when designing software. Again, not knocking, judging, or disparaging, I just don't get it.....please enlighten me!
I'd say std::to_string is a pretty good example of good use of overloading. Why would you want to have different functions for converting different types to std::string? You don't. You just want one - std::to_string and you want it to behave sensibly whatever type of argument you give it - and it does just that. Using overloading keeps the client code simple.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Question:
What are some good libraries that've been written in VB.NET? The best would be open source, as that would allow interested developers to take a look at some good VB.NET code and see how the language can be used effectively. But I'd be interested to know about any libraries at all, particularly reputable ones.
Long-winded explanation of where I'm coming from:
Generally speaking, when VB.NET and C# are compared, there is a lot of strong support for C#, accompanied by some bashing of VB.NET until a respected developer comes along and acts as The Voice Of Reason, pointing out that while VB prior to VB.NET had its fair share of issues, VB.NET is really a very strong, fully OOP language that is, feature-wise, right about on par with C# (with the exception of certain things like a full-bodied lamba syntax [pre-VB10] or the yield keyword, as many C# faithfuls are quick to point out).
I myself, having written plenty of code in both VB.NET and C#, fall squarely in the "I prefer C#, but don't consider VB.NET any less of a language" camp. However, one thing I have noticed is that when it comes to respected and/or widely-used libraries for .NET, everyting is written in C#. Or at least that's been my impression. This strikes me as a little strange because, aside from the abovementioned sprinkling of nice features (in particular the yield keyword), I tend to view the VB.NET/C# divide as primarily a matter of personal taste. Obviously, plenty of developers prefer C#. But I personally know some developers (good ones) who prefer VB.NET, which would lead me to suspect that surely some libraries (good ones) would be written in VB.NET.
I'm thinking they must be out there, and I just haven't found them.
I write VB.NET and C# interchangeably (about 50/50) in the apps I manage, and I've always had a slight preference for VB.NET (I've been programming in BASIC-lineage languages for 25 years, since I was 9, but only about 15 years in C-based languages).
That said, I find C# is a better language for libraries.
This has nothing to do with VB.NET's limitations and everything to do with C#'s.
I want my libraries to be easy to call from both VB.NET and C# code. When I write in C#, I tend pay attention to things that matter when calling the code from C#. Two examples of this are C#'s case sensitivity and its lack of optional parameters. But when I write library code in VB.NET, I'm not as tuned-in on issues that could make my API less friendly to C# callers.
Generally speaking, my opinion is that the languages are really the same. It's the convenience of the syntax. Personally, I like that you can have multiple things happening within the same line. Once I switched to using C, Java, JavaScript, Perl, and the curly bracketed languages, I found it easier to understand simply because you could see much more in fewer characters.
As far as good frameworks written in VB.NET, check out anything written for (and including) Dot Net Nuke.
Another good point is that most of the Design Patterns, TDD, DDD, Agile, etc. use Java as examples, which is very much like C#. It's like trying to translate British to English rather than Spanish to English.
BASIC = Beginners All-purpose Symbolic Instruction Code.
Throw a "visual" in there and its still a beginners language ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been programming for a few years in C# and XML. I used only the basics of those languages and have survived on the web for info like arrays and text manipulations. But when I am get interview, the interviewers ask only advanced questions - I found the answers later in the Advanced sections in the books on the subject.
Why do the interviewers ask such advanced questions? The job looks almost the same as what I was previously doing, so there's need for advanced knowledge, like what class delegate is or XPath commands.
Questions are:
What version of XSL does .NET 3.5 uses?
What XPath command to use to get value in element X?
What are class delegates in C#
Does C# allows multiple interface inheritance?
How do you access GAC in C#?
There are two reasons that I ask them.
To see a person actually say "I do not know the answer to that", as opposed to trying to BS through the question.
To see what kind of logical problem solving skills a person has.
Usually a question will be of one or the other, but not both. Both are extremely valuable in screening a perspective employee, however.
Also, the question might not actually be "advanced" for the position. It is reasonable to assume that Senior-level and/or Architects can answer questions that a Junior to Mid-level might not.
Perhaps because they are trying to find programmers who know more than the basic stuff. If they are trying to distinguish between a field of candidates, it isn't helpful to ask questions that everyone knows the answer to - how do you select among those candidates? If you're going to hire only 1 or 2 out of a pool of candidates, you need to find some harder questions that only 1 or 2 out the pool can answer.
Getting the answer wrong is what I want from an applicant in some cases.
One of the reasons I like to ask a question that I think the applicant will get wrong is to see how they adjust to the situation. How they handle getting something wrong and handle someone telling them how they should have answered etc. If they are very defensive or rude when you tell them they are incorrect then it is a good indication of how they will work on a team when many times your ideas will be challenged.
If they take the solution or recommendation and realize they can learn from it or even add to it that is usually a sign of someone what is easy to work with and willing to work 'outside of their box'. If they just make excuses and dance around trying to say why they could be right or should be right (in cases where they are clearly not) then this tell me when the same issue arises in the future this applicant is going to cause headaches.
Not so worried about the answer, more interested in how they react to the question / solution.
Another reason would be to gauge their level when hiring as well. You might be hiring for a bunch of positions but not sure where this applicant fits. Hard questions that show problem solving and attention to detail can sometimes make it easier to categorize their skill set.
I ask advanced questions for a few reasons:
Some of my questions are advanced usage of things everyone should know (not a trivia question) -- I want to see you reason through the answer using knowledge you have, but in a way that isn't common.
I want to see what happens when you don't know something -- do you give up?
I want to hire people that are serious about what they do. People that really care about the technologies they use tend to want to know the advanced stuff.
I want to see if there are gaps where you just don't know that an entire area of knowledge even exists. For example, in your XPath example -- I might be ok with: "I believe that XPath could be used to help solve this, but I don't know it well enough to write it out here" -- then I would show them a little XPath and see if they could apply it. If you don't even know that XPath exists, google isn't going to help you.
Likely they're just getting a gauge of where you are. They probably got stuck on this problem themselves and perhaps wanted to see if you could think of an answer on your feet.
I've experienced the same types of questions, and considering when I program I use excessive resources, this type of thing usually throws me off. Their loss.
Because competency as a programmer involves both depth and breadth of knowledge.
The interviewer is trying to devine your level of knowledge, and he is copping out by "borrowing" a question from the last chapter of that book.
Really, this is sloppy work on his part, relying on one question to guage your expertise level. You may have low programming skills, but recently come across the buzz-word, and are able to ace the interview.
I did get burned once in interviewing a candidate who professed high levels of C expertise. It turned out that he was reading "C for Dummies" and managed to BS through the interview process. I admit that I wasn't concentrating on his programming skills, but was looking for other aspects, which he also managed to BS through. Turns out his whole resume was a pack of lies.
Nowadays, I make sure the candidate has working knowlege of variable scope, persistance, pointer arithmetic, basic algorithms, structured programming, object-oriented programming, polymorphism, multitasking and inter-process communication. I will quiz him on his debugging skills, and zero in on details such as race-conditions, heisenbugs and security vulnerabilities.
Depending on the job, I will ask about experience in the target language - such as key=>value maps (arrays) in PHP, Swing programming in Java, event handling in C#, tables vs CSS in html -- you get the picture.
If the candidate passes the first part of the interview (I usually know within about 5 minutes), I will then give him a binder and send him into the coffee room (nice couch and table there) to prepare for 20 minutes for a code review on a selected module.
That's when I send in the troops - employees are instructed to use the coffee room normally, introduce themselves and make conversation for about a minute.
What I'm looking for is the ability to concentrate on a task (blatant ADHD), the ability to work under pressure, and interpersonal dynamics.
When the candidate returns, I have him act as main presenter and start our normal code review process. The first thing I look for is if he read the page titled "Code Review Process". I'm not looking for him to complete the review - about 10 minutes is enough. As a matter of fact, the fewer main lines processed, the better - within reason.
I haven't been burned by a new hire for a long time now.
Your username suggests you like coding (duh), but your question suggests you don't. If you really liked coding, then you should love to learn about it. Those questions that you listed are not that advanced.
Even if those questions were advanced, the interviewer is trying to gauge how much knowledge you have in the area that you say you have knowledge in. They are also trying to gauge how well you would fit into their group.
P.S. Not to be mean, but if you program using XML and don't know what XPath is, then you are a little far behind.
They probably want to see if you really know what you're talking about or if you're a novice programmer who gets along on the web using only what he has picked up through trial and error...
1.What version of XSL does .NET 3.5 uses?
Because they can't tell important things from non-important ones. Bad sign.
2.What XPath command to use to get value in element X?
Because they want to see if you know XPath. This can be either because they use it extensively and you need it to get they job done or because they think XPath knowledge == skill.
3.What are class delegates in C#
(I've never heard the term "class delegate" and a google search shows no definition, so I assume you mean just "delegate").
Delegates can hardly be considered an advanced topic.
4.Does C# allows multiple interface inheritance?
If they really asked about "interface implementation", it's part of the most basic concept so it's a valid question (although too simple to really mean anything). If they really asked about "interface inheritance", it's more of trivia, but I would still say acceptable. Bonus point for them if they asked what "interface inheritance" really means.
5.How do you access GAC in C#?
This is the kind of thing every team MUST have one person who knows. I'd say it's also a indication of seniority (which BTW, I don't care much about) since nobody reads about these things, the only way to find out is to be forced to solve a real-world problem.
I ask advanced questions to try see how people work through the problem. I like to ask questions that I don't know off the top of my head for that reason.
I want someone who is a critical thinker rather than just an academic who can recite text books to me.
They want to find someone with practical experience that extends beyond what is taught in beginner courses. When my company interviews candidates, we often find that most of the applicants cannot solve what we would consider to be very basic programming problems simply because they don't know the API or don't understand when to use various basic data structures.
If you want to impress an interviewer, work on your own programming projects outside of class. Learn a good chunk of the language API, and start learning about third-party libraries that can greatly simplify your work.
Another reason is to gauge your response to a question they really don't expect you to know the answer to. Problem solving skills are essential, so asking you questions you already know the answer to is not going to address that, is it?
There are even instances of companies asking odd, non-programming related questions just to see how you think your way through a problem. There is the classic "Why are manhole covers round" question, reportedly asked at Microsoft interviews.
More Microsoft interview questions
I'm not meaning to offend you but maybe your understanding of the job is not deep enough and it in fact requires knowledge of advanced techniques.
Also, you can do a lot of things with basic methods but advanced methods might the better way to implement regarding complexity, time to implement or maintainability.
There are many possible reasons. They may:
actually use those techniques (delegates and XPath aren't particularly rare or obscure)
have a large pool of candidates and want to try to find the more knowlegable ones
want to see where the limits of your knowlege are, so they ask question up to the point where you start to be unable to answer well
want to see how you might approach areas that are unfamiliar to you - to see how you might adapt to new stuff
want to show off their own knowlege (probably not a legitimate reason, but it certainly happens)
I've heard these really aren't in use anymore, or at least not nearly as much as they used to be, but you might be interested in this. I picked up a pretty cool short book a few days ago that has to deal with the "Microsoft style" logic interview questions that are sometimes asked. I'm a few chapters in and it gives a neat little history of the tech field's interview style and has a ton of logic problems, complete with answers in the back.
It's called "How Would You Move Mount Fuji" and it's on amazon for pretty cheap.
http://www.amazon.com/gp/offer-listing/0316919160/ref=dp_olp_used?ie=UTF8&condition=used
I've just completed a round of interviews, where I use a three or four stock 'simple' C# code fragments that the interviewee will look through and attempt to explain what the expected result will be. In each case the code sample is no more than ten lines of clearly-formatted code that utilises basic C# skills (inheritance, generics, anonymous delegates); also in each case there will be a 'gotcha' - but like others have stated, I don't put these in to be spiteful, they're there because I want to see how the candidate reacts when confronted with something that doesn't work as expected.
We had a candidate recently that had sailed through the first part of his interview; impressive CV, was apparently the Lead Developer of a team of 10 and had been developing code in C# since 1.0; yet apparently had no idea what "Console.WriteLine()" did (nor could he even hazard a guess), nor could he even begin to cope with the tiny anonymous delegate example.
Another candidate was self-effacing, and didn't know how to grade herself as a developer - she'd had less experience than the former candidate yet she sailed through the code samples, fell for a couple of the 'gotchas' but asked the right questions to get the correct conclusions and genuinely learnt from the experience. Needless to say, she was hired.
If you're claiming domain-specific knowledge (like XML) you should expect to be asked specific (and sometimes hard) questions about that domain; if I'm interviewing a senior ASP.NET developer and they've got no idea about HttpModules or HttpHandlers (like some recent interviewees) then alarm bells start to ring.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I use LINQ in my code all the time. I've gotten to the point where it just seems so natural to Group, Order, an organize a bunch of objects using the LINQ syntax that I struggle to think how I would do the same things without it.
I had never delved into the SQL-esque world before this, but I imagine many people who learned even the normal SQL syntax suddenly felt constricted by most normal programming languages abilities to wrangle complex object hierarchies?
Am I painting myself into a corner becoming reliant on LINQ to do my more complex tasks? It just feels so much more expressive than if I wrote plain C# code.
Is becoming dependent on the LINQ syntax in my day-to-day programming going to hurt me in the long run if I end up switching languages or frameworks where something like it isn't available?
Fortunately, no. The "LINQ" way of thinking is more properly understood as a "functional" way of thinking, and this is a highly transferable mindset.
Obviously when you move from language to language and framework to framework the syntax and framework methods will be different but the mindset is the same. The important skill that you have aquired is the ability to think in terms of sequences and functional pipelines that process those sequences.
Instead of looking at your prospective future outside of C#, I would concentrate on what helps you get your work done today.
If that means using and becoming fluent with LINQ, so be it. As long as you're willing to learn and adapt in the future (just like today) it won't be that big of an issue.
Yes, your concern is valid.
That is, when you get good at using any tool, you start to forget how to function well without the tool. You also get frustrated when that tool is not available.
For millions of years humans were able to feed themselves without the use of metal tools. They weren't miserable. Today very few know how to do that, and most are scared of what that would be like.
For tens of years humans wrote software without real-time interaction with a computer, e.g. punch cards. They weren't miserable. Today very few know how to do that. The idea of doing that sounds miserable to me.
If you become adept with Linq, you will miss it when it's not around. It's a great tool. As your skill with Linq grows, your skill of programming without Linq (which you aren't practicing) will become rusty.
In all the above cases, we have replaced a human skill with a tool + a new human skill. Each time, the idea of giving up the tool sounds scary. I believe there's always some value in exploring the older, lower-tech way of doing things, as it helps me become more well-rounded, but usually I'll pick the higher-tech way.
So, don't shy away from Linq, but do explore other ways of doing things, as part of your self-education as a programmer.
Does it matter? Every language has its unique nice features. It's like saying "Will using braces in C# make it hard to transfer it to another non curly brace language?"
Its not going to hurt you. I truly believe all modern languages are going to move to this syntax very shortly. Java is already moving in that direction, and other languages will follow with something similar. MS, for all of the bashing they take, were way ahead of the curve on this one. The wiped out a whole class of bugs related to temporary variables/arrays in terms of querying array objects. The benefits to this are enormous.
LINQ is a great thing. It will spread. In fact, the spread has already begun.
If it could be equated to learning OO, I know people who have gone from C to an OO language and back to C and although they didn't have objects available, they tended to be able to use many techniques in a language without objects.
Could the same thing happen with LINQ?
Yes, it will hurt you if LINQ to SQL is the only sql you know.
I find that understanding the logic behind it helps me feel better about using LINQ extension methods. If you can write your own Where or Group ..etc extension methods then there is no shame in using them.
I think it's important to understand what's going on behind the scenes of high-level abstractions like LINQ - otherwise you can have problems such as performance. Funnily enough our host's latest blog post is on this subject.
So if "thinking in LINQ" means forgetting this, which I suspect it does for some developers (present company excepted), it could be considered "bad".
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been a VB.net developer for a few years now but I am currently applying to a few companies that use C#. I have even been told that at least one of the companies doesn't want VB.net developers.
I have been looking online trying to find real differences between the two and have asked on crackoverflow. The only major differences are a few syntax difference which are trivial to me because I am also a Java developer.
What would be a good response to an interviewer when they tell me they are looking for a C# developer - or similar questions?
I've had to interview people for a few C# positions and this is my general advice for VB.Net developers interviewing for a C# position:
Make sure you are clear that you have been working VB.Net. This seems obvious but is something that apparently isn't (in my experience).
Try to give a code sample, if possible. I've seen some horrible VB.Net (and C#) written by VB programmers who didn't seem to learn much in the transition to .Net.
Be able to write in C# during the interview, if asked. I know there aren't many real differences between the two, but I don't want to pay you to learn the new syntax.
For your specific question: I've asked that type of question before and what I wanted to hear about was how the underlying system and framework were the same. If possible, talk about garbage collection, IDisposable, finalizers, the dangers of unsafe code blocks, stack vs heap, etc. All the kind of stuff to show that you really understand the intricacies of the .Net framework. Right or wrong, the heritage of VB brings with it an expectation of a lack of understand of lower level programming and windows in general (which, ironically enough, a c++ developer would have of a c# developer... and so on).
Lastly, how you frame your experience can make a world of difference. If you position yourself as a .Net developer, rather than VB.Net or C#, the stupid, pseudo-religious, banter may not enter the conversation. This of course requires that you actually know both VB.Net and C# at the time of the interview, but that's a good policy regardless.
The truth of the matter is that if you find that the person interviewing you writes you off simply because you've previously been developing in VB.Net, it's likely not going to be a place you want to work at anyway.
Some differences (that are more substantial than syntactical) that suitably catch me out sometimes:
VB.NET does not have anonymous delegates
Unsafe code blocks aren't in VB.NET
I love C# to death, but I envy VB.NET's optional parameters. Office automation in C# is so very, very painful.
I think the truth will-out on this:
I'm a software developer, the syntax of the language is the final part of the puzzle. By employing me, you're getting someone with demonstrable experience of problem solving and logic. I'm experienced with the .NET environment, the CLR and the associated Windows stack, including SQL and Windows server. I don't know the C# syntax, but, I am used to object-oriented approach, I will have no problem getting totally up to speed on the finer points of the syntax within a couple of weeks. You can see from these examples of my code that I'm an experienced developer, I assure you the transition will be seamless. I have already made a start learning the language, I haven't had any problems so far.
#DAC - VB now (in .net3.5) has support for lambdas:
Function(x) x.ToString()
In an interview I'd say that understanding the CLR and what the code's really doing is what's important, and that you're happy to code in either (assuming that you are).
I'm also a C# feller to the death but the differences are not just syntax. There are places where VB wins HANDS down
Optional parameters
Late binding
Working with COM from C# can be a very frustrating affair. (Which is not to say impossible!)
Truthfully? If you're a Java developer too, I'd lead with that. A Java developer with some experience in .NET will generally make a better impression than a VB developer with experience with Java. If you can answer questions on the difference between .NET and Java you should be in good shape.
I'd also recommend you learn the C# syntax ASAP. If you're experienced with VB and Java it won't take long.
A lot of developers have issues with VB and the people that use it. Valid or not you'll have to deal with that reality.
VB or C# both are syntax only diffrent but if you are applying way of logic is same.