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 1 year ago.
Improve this question
Our team of software developers consists of a bunch of experienced programmers with a variety of programming styles and preferences. We do not have standards for everything, just the bare necessities to prevent total chaos.
Recently, I bumped into some refactoring done by a colleague. My code looked somewhat like this:
public Person CreateNewPerson(string firstName, string lastName) {
var person = new Person() {
FirstName = firstName,
LastName = lastName
};
return person;
}
Which was refactored to this:
public Person CreateNewPerson (string firstName, string lastName) {
Person person = new Person ();
person.FirstName = firstName;
person.LastName = lastName;
return person;
}
Just because my colleague needed to update some other method in one of the classes I wrote, he also "refactored" the method above. For the record, he's one of those developers that despises syntactic sugar and uses a different bracket placement/identation scheme than the rest of us.
My question is: What is the (C#) programmer's etiquette for refactoring other people's sourcecode (both semantic and syntactic)?
I would worry less about politeness and more about the economics. Every code change induces a huge number of costs:
code changes must be tested by QA
code changes must have test suites written for them by development
code changes that affect user experience may need to be documented
code changes can introduce bugs; those are obviously enormous costs
and so on.
I would not dream of making a minor "aesthetics-only" change to any production-quality code, whether it was "mine" or not. The benefits of the change do not come anywhere even close to justifying the cost.
You might consider reminding your colleague that you're in the coding business not to produce beautiful code that you all find aesthetically pleasing, but rather to produce profit for your company in a weak economy. You're not artists, you're engineers, so act like engineers; all changes should be justified by a business purpose.
I believe in collective code ownership i.e. that code belongs to the project, not to an individual engineer. So I have no problem with someone refactoring something I wrote as long as it complies with the project standards. If the project doesn't have coding standards, then the team should define some.
An etiquette should always be done on the level of the team. So talk with your colleague about this and then talk with the complete team to define a rule.
Common rules may contain not to change the code, if it is only for beatifying and disputed coding styles. If someone has to maintain your class in the future, then it is usual, that he can change anything.
Define some base-rules, some anti-patterns (that always can be refactored by your coworkers) and so on.
Such rules don't have to be very strict, so the placement of braces or similar things don't need to be defined. But in that case, nobody should beatify code, someone else maintains. If you get into conflict about one thing, talk about it in the complete team, to create a new rule for this case.
Without coding-style guidelines/rules, he might not even be aware that the change is causing annoyance.
That said, the style is fairly non-standard and on a personal level, I'd be annoyed with a "refactor" that does not change the meaning of the code but rather serves only to stamp his coding style in your face. I'm not sure it even qualifies as a refactor. Pretty selfish.
IMHO this doesn't make the code any cleaner, just imposes the other guy's coding style on it. You should discuss it with your colleague(s) whether this type of "refactoring" is really necessary (and whether there are really no better ways for your colleague to spend his/her time :-)
The most important aspect of this is consistency. Your team should decide on whether to use type inference and object initializers and write down some coding guidelines.
I believe the most important thing is to be able to disagree and commit. We all have our preferences, but changing non-important things back and forth waste everybody's time.
Ruthlessly adhere to the standard. If there is no standard then that is your problem, not that other people can and do change your code.
Also, before getting upset about code changes, you need to determine intent. Was it malicious, or an innocent change?
If I'm modifying a file that is owned by a colleague, I try to keep the changes consistent with their style. This way, even though half of our files prefix "m_" for fields and half prefix "_" (among other minor things), at least a single file/class is self-consistent.
Did he produce a majority of the code for the project in question? If that were the case, I could understand what he did. When entering into a project that's already well underway, I try to match the formatting that's already in use throughout the code.
That may not apply to your situation, of course. If whatever project has received generally equal contributions from all of you, maybe take Mnementh's advice and bring the issue to a head.
I would simply talk with your fellow developer about what you want to refactor and why. Only refactor the code if you agreed on something.
This will result in discussions where most probably both of you will learn something from each other.
I think in this specific example (C# that is), you should simply follow the guidelines provided by Microsoft. Consistency with the code standards of the .NET Framework makes for easy to read class and code structure.
The other thing is Visual Studio auto-corrects to various formatting rules as you type which would help. For example, when closing a bracket or ending a statement.
I personally think that cosmetic refactor looks ugly and decreases readability, whereas your code adhered to the .NET conventions.
Related
I'm sorry to ask such a localized question but until I get confirmation I don't feel confident moving on with my project.
I have read lots about the template pattern, Wikipedia has a good example.
It shows that you create the basic virtual methods and then inherit the base class and override where you want. The example on the site is for Monopoly and Chess which both inherit the base class.
So, my question is, if you had an application which was only going to be Chess and never anything else, would there be any benefit in using the template pattern (other than as an education exercise)?
No, I think that falls under the category of "You Ain't Gonna Need It."
To be more specific, design patterns exist to solve a particular problem, and if your code doesn't need to solve that problem, all they do is add lines of code without having any benefit.
No. Expressed in a very simplified and superficial way, the template pattern is just worthwhile starting at a certain relationship between total code size and templated code size. In your example, the chess game is going to be the entire program, so there'll be no need to use the template pattern here.
The template pattern is used in specific situations. It is used when you want to sketch out an algorithm but let the specific steps differ.
This could be useful in a Chess application. However, you should not start developing an application with the idea 'I'm going to use this pattern and that one and..'. Instead, you develop the code and you discover that you need certain patterns.
This is where a Test Driven Development approach is really handy. It allows you to refactor your code each step of the way.
A nice book that explains this is Refactoring To Patterns.
I would suggest writing your chess game and then if in the future coming back and changing things to fit monopoly too. But its something totally different if you want to use the pattern to learn the pattern, in that case its good to start simple so the complex is easier to understand.
It really depends on the parts of the program. The whole idea of Template is to have an algorithm that never changes and to be able to add or edit certain steps of that algorithm.
It may well be that you never change, however, this is the issue with design principles, it IS good practice and you may later wish you'd implemented them. I would say though that if you are 100% sure then you can leave it out as it usually saves time and lines of code. Depends if you want to learn Template usage or not.
Also the GOF principles website is quite good:
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
So we have varying opinions on how to deal with our source in regard to parallel Scrum teams sprints. The background info is we have two 7 man teams working on the same baseline of code in 2 week iterations towards the same product release.
Team A: In one camp we have the preferred approach being: Each team work in its own branch and at the end of each sprint if the changes are acceptable then merge to the trunk. The reason is team A doesn't want to risk having bad code introduced from team B.
Team B: In the other camp we have the preferred approach being: Both teams work in the trunk, check in small working changesets early and often and rely on the continuous integration build to prevent and identify broken builds early. Team B does not want to perform large merges every few weeks.
Thoughts? Is either approach more valid than the other? Is there a 3rd approach neither team has recommended?
Edit: Just to clarify both teams want CI, but Team A would have a multiple nightly builds, one for each branch. Team B is in favor of a single build on the single branch.
Thanks~
In any normal case with people involved the merging will soon be postponed "until we've stabilized this one thing". This one thing rarely gets stabilized very soon, so the branches start diverging. It's not bad in the beginning, but soon you'll notice that you'll have merging and stabilizing sprints going on. This is what's happened in all projects I've seen branches being used for something like this.
Of the two options above, I would suggest biting the bullet right away, and using option B. It will generate some overhead, but at least people end up merging their changes immediately when they still remember what and why they are doing things. In a couple of weeks, it'll be much harder.
Solution C could be to extract a third project with the common code for both teams, leaving the actively developed parts for each team to modify at will. The shared code base should hopefully be more stable. Don't know if such a solution would work in your case.
Team B. You're introducing overhead -- the large merges -- for the purpose of avoiding a hypothetical situation ("bad code") that won't occur often, and if it does, will cause less work to correct than all of the merges will accumulate. Also, these merges themselves may introduce errors.
In short, you're adding more work to deal with an unproven problem which in the end might cause yet more work.
On the other hand, if team B (or A for that matter) is checking in bad code, the place to catch it is in the CI, and if they are introducing bad code, that's a management problem, not a procedural problem.
Why not let Team B work on the trunk and Team A on a branch? Everyone gets what they want! (just kidding: this is really no different from approach A)
Seriously, though, you are trying to choose between "work in silos" and "have only one huge team" (or more diplomatically: "stable workspaces" and "proactive collaboration"). I would suggest a hybrid approach. But I also agree with Kai Inkinen's idea to refactor the codebase into shared vs team-specific code. Your teams are large enough that the code they generate will be significant: more components makes sense and might avoid this issue altogether. Assuming you don't have that option:
Some disadvantages of A:
(think: what's the trunk going to look like at the end of week 2? How confident will you feel about that code?)
encourages "big crunch" merges near the end of a sprint (in fact you are planning on it!). Expect conflicts, duplicated effort, and sub-optimal code structure after the merge.
prevents a team from taking advantage of good changes made by the other team
at the end of the sprint: who gets to merge to trunk first? That team might as well have been on the trunk all along!
Some disadvantages of B:
(think: Team B wants to share changes among themselves that aren't good enough for the trunk yet. You know this will happen, or else why are there two teams at all?)
discourages frequent checkins
encourages "working copy transfers"
whenever someone from Team B "breaks" the codebase, Team A will say "I told you so"
My suggested approach:
have both teams use separate branches, to encourage frequent checkins for each team. Checkins are good. (If a team (A) wants to keep their code protected, they will find ways to achieve the same ends even if you don't give them a branch, i.e., working copy transfers: "hey Kim, I know it's not perfect, and you haven't checked it in yet, but can you send me your fix for that file?")
have both teams "deliver" to trunk often: not just at the end of a sprint. Deliver each "story" as it is completed.
have both teams "sync" from the trunk often (ideally after every "delivery" from the other team). This, in conjunction with the action above, keeps merges as small as possible and should make the end of the sprint completely painless. Team A may resist this; they should be encouraged to "respond to change" in the code -- they'll have to merge eventually.
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync
With this approach, teams will be rewarded (with comparatively easy merges) for checking in often and for delivering changes to the trunk as soon as possible. Both of these are good things.
I should also point out that with something like git/Mercurial, you have a bit more flexibility.
I'd go for continuous Integration. There are very few reasons to do otherwise. Check this link by Martin Fowler for an excellent explanation of the advantages of it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
A very open question. I've been programming in C# for the
past 5 months doing small projects that I completed
successfully.
Today I went to an interview for a C# role. The 1st question
was 'Tell me about boxing'. Given my experience I had no
idea what the guy meant. Needless to say the interview
didn't go that well. Others questions were 'why isn't it
recommended to use an ArrayList of int', 'tell me what you
know about threading', etc.
I don't really want this to happen again so I'm planning to
spend some time reading (and practising) more on C#. I
understand that the best way of learning is by coding but
coding wouldn't have really helped me answer the question
about 'boxing' for example.
I'm not asking you to answer the above technical questions.
In fact, I know now their answer as I went straight to
Google after the interview and it's how I realised that my
C# knowledge is somewhat limited.
My question is: in your opinion, which knowledge should any
C# developer have? Ideally it would be better if you could
categorize it (Basic knowledge anyone should have without
exception, Advanced knowledge, Expert knowledge etc). No need
to go into details. Doing research on whatever you list will
be a good exercise for me.
I would expect someone going for a professional C# job to know about:
Generics and generic collections
Interfaces (general)
Interfaces (specific), namely -
IDisposable: how it's integrated into the language and why
IEnumerable: including common extension methods, iterator blocks, and deferred execution
Overview of serialization in .Net (maybe not have done it, but understand what it is and know where to look in the namespace heirarchy and documentation)
Overview of Xml in .Net (same as serialization)
Overview of threading concepts (same as xml/serialization). Bonus points for understanding why most thread-safe collections aren't.
Have used anonymous delegates / lambdas in at least one project, and therefore also have a basic idea about closures.
Comfortable explaining some basic concepts from at least one of winforms, wpf, webforms, or MVC
Be able to answer some easy questions on specific common classes in the .Net BCL: namely from System.Data (think parameterized queries!) and System.IO (filestreams, path).
Garbage collection: when should you call GC.Collect (hint: pretty much never) and why
Here is a good list: What Great .NET Developers Ought To Know.
My personal experience from a long time ago when I was in school.
I went to see my father at work in a bank. At that time, most of his day was taking care of accounts and making sure every thing worked. What I saw was he was trying to tally/calculate large numbers and calculating(basic additions/multiplications...).
After noticing him, I asked him: Dad, if all you have to do is basic additions and multiplications, why bother to study till graduation?
His response was : While you don't have to use all the knowledge you have acquired, that knowledge would help you make learned decisions.
Coming to your question: While you dont have to use the entire set of concepts, knowing that they exist would help you make good decisions while you code.
My suggestion along with the others posted would be to try and spend some time on stackoverflow every day.
Good luck.
A good interviewer isn't going to grill you on trivia. That's why we have Google. A good interviewer is going to find areas you don't know, and ask you questions there, as that's the best place to find out how you react when confronted with something you don't have down pat.
The best advice I can give for interviews is to not worry about the technical trivia too much. Instead, in an interview, focus on problem-solving skills. If you don't know something, don't try to hide it, just admit it. If you think you know, it's okay to say "I'm not sure, but I think it's this." And don't get flummoxed either - at that point, usually the interviewer will give you a hint. This is not just giving you the answer, it's another part of the test - to see if, given a nudge in the right direction, you can extrapolate from there.
For the boxing/ArrayList/int questions, if I was interviewing and you didn't understand boxing, I'd give you a basic description of what boxing did. Then I'd ask you, knowing what I just told you, why you might think using ints in an ArrayList might be a bad idea.
One thing that will go far in any interview is focusing on the requirements, the desired result, and boundary conditions or edge cases. As most programming interview questions fall into the "write this method" category, make sure you get the following correct:
1) The inputs to the method
2) The expected output of the method
3) Boundary and edge cases.
This sounds ridiculously basic, but it's amazing how many developers, even ones with experience, don't bother thinking through these things. Code solves a problem - if you don't understand the problem correctly, you can't solve it correctly.
I would have to say that if an interviewer can be fooled into thinking someone has more .NET / C# experience by he or she visiting a webpage, then the interviewer is failing. I've interviewed a number of people myself, and I really like the approach of giving them some easy to understand problem to solve, and asking them to write some code on a white board. Even if they've memorized the answers to every question on Scott Hanselman's blog, I would learn a lot about how comfortable they are in the language, as well as how they go about problem solving. I'm looking for a developer, not a partner for Trivial Pursuit, .NET Developer Edition.
That said, keeping up with blogs like Hanselman's is a fantastic way to keep up with the jargon. You could code C# in a vacuum for years, fully understand the advantage of a strongly-typed List<int> over ArrayList, but never actually use the term "boxing". But it's much more time consuming in an interview to ask, "Describe the advantage of iterating through a List<int> instead of an ArrayList of int," than it is to ask, "Tell me about boxing." Plus, actually researching the answers to Hanselman's .NET interview questions (especially if you explore the details and ask "Why?") will make you a better developer. So by all means, keeping reading Hanselman.
And one more note... If I ask someone whether a String is a reference type or a value type, and they simply say "Hmmm... Reference type," I'm not going to be nearly as happy as I would if the response was, "Hmmm... Reference type, but that's an interesting question." "Why is that?", I say... "Because string is implemented so that the string is immutable, allowing you to do things with it like safely use it as a hash key. Or pass it to a method, knowing the value cannot be changed. So in a way, strings can act a lot like value types..." And that would be a great conversation, leading me to ask, "So tell me more about why hash keys should be immutable..."
It's not just the difference between answering a 50/50 question correctly and all the additional information in the second answer. Having an intelligent conversation with a interviewee leads me to think I'll have intelligent conversations like that on a regular basis once the interviewee becomes my coworker. And that's something I'm definitely looking for.
Also depends on the role. If this was advertised as a jnr role then a threading question is a little tough...sometimes agencies/employers have unrealistic expectations.
A similar thing happened to my significant other taking a driving test. The state trooper said, "make a roundabout" and she didn't know what he was talking about. Both of us think a roundabout is a type of road layout with a big circle, not a u-turn as the instructor meant. So I know what you mean.
Programming job interviews vary wildly. Some people think you can't really judge a programmer well in an interview and are willing to give anyone who makes a good impression a chance. Others are grueling things which only those overqualified for the position would pass, and you will probably be suprised how often you get a call back from those.
This is something I have been pondering myself a lot lately. Using C# plenty but not sure what I am missing.
I ordered
Microsoft® .NET Framework Application Development Foundation
Which covers a lot of ground related to C#
Also looking at C# in Depth
Read some of this already. Has some great information from a high quality author.
In depth is on sale too via Jon Skeet's blog
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 8 years ago.
Improve this question
We're hiring a .NET developer soon, and I was assigned to create a test, which would take aprox: 1h to solve. A test which would test the programmers knowledge in (mainly) C# and ASP.NET.
This is what i've come up with so far:
Use project #1 to read data(HTML) from the specified URL and output all links(anchors) containing anchor name “xxxxxxxxx”. You are free to use 3rd party libraries. My main thought here was to test how the developer would go about solving the problem. For example:
Create a regex which would parse all the data needed.
Create a DOM-tree and use XPATH to find all anchor nodes.
Iterate the whole string and perform manual string compares.
Create a new solution where you demonstrate the usage of .NET masterpages.
Connect the solution to the ******** database. And output all customers from the “********_customers” table.
Create a new button which refreshes all users using AJAX.
Pretty basic stuff. Though, I also added the one below. Mainly to test the developers OO knowledge. Do you think this is too "overkill", or what kind of test would you suggest? If you were to hire a ASP.NET developer, what would your main focus be? ADO.NET? IO? string handling?
Create an interface/abstract class implementation demonstrating the functionallity of either the Factory, Factory Method, Command or Decorator pattern. You wont need to implement any functionallity, just use comments in your abstract class.
Thanks in advance!
The task you gave is essentially a day or two worth of coding if you want to have reasonably readable code. Within an hour I guess I would do it, but you'd have to read code that has cryptically named methods, unreadable regexes, weird callbacks, no error handling and overall is pretty darn ugly. Looking at it you would not hire me.
Before you give your question to candidates, first make sure that your peers/programmers can do it first. And that you can code it in less than 60 minutes in a way that would satisfy you.
That said, I do not know if test is the best choice for hiring anyone. A few interviewing bloggers wrote about their experience coming from conducting tons of interviews:
Guerilla Guide to Interviewing by Joel Spolksy
Truth about interviewing, Get that job at Google (and many others) by Steve Yegge
I totally agree with them. Having conducted about a gazillion of interviews myself, I find that asking basic technology related questions is not nearly as good as asking to implement a bit of recursion or pointers (if someone claims to know C/C++).
By hiring someone who understands recursion/algorithms you get a smart guy who can learn new technology. When you hire someone who knows how to connect to a database, who knows how to connect to a database but not necessarily qualified to do much more than that.
There are a few sources of good programming questions that are somewhere between coding and algorithms that may inspire you. They do not test .NET at all, but are very good indicator of smart programmers.
Top Coder
Google Code jam
Within 1 hour you can only test his programming skills, but it's not enough to write the code sample.
Take a look at this C# / ASP.NET MVC test:
http://tests4geeks.com/test/asp-net-mvc-c-sharp
After the applicant will pass the test and result will be good, then invite him to the interview and talk about his experience. Ask about most difficult features, that he implemented in his projects. In other words, you must understand, if he know and can do enough to take part in your project.
If you still want to ask him to write some code. That is some idea:
There are the students and subjects. Please ask to write 3 pages (asp .net mvc or web-forms). First and second - for editing the dictionary of students and subjects. Third form must contain be the table. The students are in left column. The subjects are in the top row. The marks are at the intersection. Each mark can be edited (text box) and saved. Saving could be implemented by clicking the common button "Save". Or it could save each cell automatically using the Ajax.
This is very simple example, but it would show you how user writes the code, what techniques does he use.
I would have thought that it would be better to simply create a test that would make it easy for you to put developers into different 'skill buckets'.
Why not have three or four sections or features that the developer must 'layer' features on top one another to show their programming and design skills.
Part 1: Implement x easy difficulty
features.
Part 2: Implement x medium difficulty
features.
Part 3: Implement x difficult
features.
Part 4: Implement x very difficult features.
And give the developer 1 hour to write the application. Make it realistic that they can implement the features in the given time frame.
As Joel and Jeff say on the Stackoverflow podcast, there is a direct correlation between developer skill and speed.
Think about the way exams are structured? We can all get 100% of the questions correct in any exam we sit if we had infinite time, but in 1 hour?
This way, If a developer takes your test and only implements features up to Section 2 in the time period, then you should have a safe indication that they are not suitable for the job. Section 3 features all done then they are good enough and section 4 complete would indicate that they are very experienced and a slight cut above the rest.
However I would also look at the overall polish that the developer has given to the code. If they implemented all features up to section 4, but poorly, then they are also not going to be someone you want. IF a developer only did up to section 3 but implemented everything very elegantly, then I would want to hire them.
I also think that 1 hour is perhaps a little too long. I would aim for 10-40 minutes obviously you may need to cut out section 4 that I proposed.
You should check
GeekInterview -- a good source for interview questions
There are hundreds of questions.
I think you would be much better off coming up with a single question that will allow you to see more than just development skills using your target technologies. Strong problem solving skills are as important as expertise in a specific technology stack.
I would even recommend that you explore the two aspects of a candidate in different parts of the process. I usually ask a bunch of questions about the technology stack we are using on our project to gauge the candidates level of knowledge as it relates to that stack.
Then I ask them a pure problem solving question and I allow them to use whichever technology they are most comfortable with to solve the problem (their choice of technology can be an important indicator).
I particularly like Graph Theory related problems. The candidates solutions will tell you a ton about how they approach, solve problems as well as how they validate their solutions.
As part of the problem solving portion of the interview you should be looking for:
Proper data structure design
Implementation of OO best practices
Proper solution (can they debug problems effectively... one great way to see this is do not allow them to use a computer, make them code on a whiteboard and debug in their heads)
Proper solution validation (do they come up with test cases)
My 2 cents:
We have a programming test in my company that is easy. Basically, you have to implement the listener pattern extending the ArrayList class, create unit tests for it (based on at least what we require), document the corner cases, document the program itself if you want to, and then send the test back to us.
A developer has 48 hours to complete that test. We ask for production quality in the test. We want to test the following items:
Was the developer smart enough to cover the corner cases?
Is the developer implementation of multi-threading satisfactory?
Are the unit tests good enough? Do they cover enough cases?
Is the code well written and documented? Will someone be able to maintain that code in the future?
Does he care about his code? Did he explain why he did "A" and not "B"?
I don't think short tests are capable of evaluating a developer. You may ask for a tool or technology that someone have not been using in the past months, and whoever is being tested for that technology will need sometime to get up to speed - but if a developer was working with that the day before, he will know by memory how to use it, and he/ she will seem smarter than the other developer, what may not be true.
But if you ask for something that is tricky and you are interviewing the developer, you can check how he is going to solve the problem - I don't think it really matters if he/ she cannot get the 100% right answer, as long as he/ she can talk about the problems that you found on the code and show that they actually understand whatever you explained to them.
In the past we have used problems from Google code jam. the problems in the early rounds are easier and they get gradually harder. They are kind of algorithmic in nature, you can solve them in whatever language you like. As they get harder there is often an obvious 'brute force' kind of answer that won't work because of the size of the data. So you have to think of something more optimal.
The first test you suggested should take 10min-40min for a basic dev - I would use a web-crawler I have in my library that converts HTML to XML then easily use Linq to XML.
I would test for lambda expressions, performance patterns maintain files, or writing an object to several files dynamically.
Maybe you would like to test unmanged code, pointers etc.
I donno, im just writing-jabbering while things are comin up to my mind, i wrote things that was hard for me to implement.
few days ago I was invited to pass C# programming test at skillbox website there was 30 questions quiz and 45 time to pass it. Below is some of them:
1) What will be printed by running the program?
#if DEBUG
Console.WriteLine("DEBUG");
#else
Console.WriteLine("RELEASE");
#endif
2) What will be the result of calling SomeMethod():
public static void SomeMethod()
{
string s1 = "a";
string s2 = "b";
Swap(ref s1, ref s2);
Console.WriteLine(s1);
Console.WriteLine(s2);
}
public static void Swap(ref Object a, ref Object b)
{
Object t = b;
b = a;
a = t;
}
Here is a link for reference, I think you can find more C# quezzes there http://skillbox.io
For those of us that have programmed enough I’m sure we have come across many different flavours of coding standards that you can use when it comes to programming.
e.g. http://msdn.microsoft.com/en-us/library/ms229042.aspx
You might derive your coding standards for the current company you work for or from the original author of the code you’re working on. Coding styles are often used for specific program languages and some styles in one coding language might not be considered appropriate for others. Of course some coding standards can be applied across many different program languages.
Thank you for your time.
EDIT: As we know there are many related articles on this subject, but C# Coding standard / Best practices in SO has some very useful links in there which is worth a visit. (Check out the 2 links on .NET/C# guidelines by ESV - Accepted Answer)
Google has a posted style guide for C++ here which I consult sometimes. Just reading through the explanations and reasoning, despite whether you end up agreeing with some of the styles or not, may teach you some things you might not have thought about.
My best advice regarding coding standards: don't let them get in the way when trying to get work done.
A big bureaucracy might actually hinder progress in projects instead of helping to achieve better team work. When people complain about not following coding standards instead of the actual quality of the code, then it is too much regulation.
Other than that, pick one from the many suggestions and try to stick with it for as long as possible to build a code base following a single standard that you are used to.
Coding standards are good, but coding standards written from scratch in which the company reinvents the wheel, or coding standards imposed by a single "prophet", can be worse than having no coding standards at all.
This means:
Coding standards should be discussed and agreed upon.
The coding standards document should include the reasons behind each rule.
Coding standards should be at least partially based on reliable sources.
The sources I know of for the languages in your tags are:
For C++: The book C++ Coding Standards by Sutter/Alexandrescu.
For C#: 4 or 5 PDF's I found googling for C# Coding Standards :)
Adam Cogan has a great set of rules on his web site. There are coding guidelines, but there is much more there also.
Adam Cogan's Rules to Better...
Coding standards are great. We've been using Lance Hunt's C# Coding Standards for .NET almost without modifications
If you are maintaining code that continue to use the same standard as the original code was developed in (there is nothing worse then trying to debug a problem when the code looks all higgildy piggeldy)
Some comment to the post suggesting looking at the Google C++ guidelines. Detailed discussion about some aspects of these guidelines are posted at comp.lang.c++.moderated.
Some weird or controversial points include:
We don't believe that the available
alternatives to exceptions, such as
error codes and assertions, introduce
a significant burden.
As if assertions were a viable alternative... Assertions are usually for programming errors and situations that should never happen, while exceptions can happen (are somewhat anticipated) in the execution flow.
Reference Arguments: All parameters
passed by reference must be labeled
const. ... In fact it is a very strong
convention that input arguments are
values or const references while
output arguments are pointers.
No comment, about weasel phrase a very strong convention.
Doing Work in Constructors: Do only
trivial initialization in a
constructor. If at all possible, use
an Init() method for non-trivial
initialization. ... If your object
requires non-trivial initialization,
consider having an explicit Init()
method and/or adding a member flag
that indicates whether the object was
successfully initialized.
Yes... 2-phase init to make things simpler... What if I have const fields? This rule is probably the effect of attitude towards exceptions.
Use streams only for logging
Which streams? IOStreams, standard C streams, other?
On one hand they advise to use macros only in exceptional situations, while they recommend using DISALLOW_COPY_AND_ASSIGN to prohibit copy/assign. They could have advised the approach with special class (like in Boost)
Do not overload operators except in rare, special circumstances.
What about assignment, or arithmetic operators for numeric calculations, etc?
Default parameters are more difficult to maintain because copy-and-
paste from previous code may not reveal all the parameters. Copy-and-
pasting of code segments can cause major problems when the default
arguments are not appropriate for the new code.
The what? Copy/paste from previous code?
Remember that reading any of the guidelines can introduce a bias to your way of thinking. And sometimes it won't be beneficial for you or your code. I agree with some other posts advising reading good books by good authors beforehand. When you have sufficient amount of knowledge, then you are able to look at the guidelines and find good and weak points easily, without creating a mess in your brain ;)
If you plan to introduce a code-formatting standard to an existing programming team, get input from each member of the team so they'll have "buy in" and be more likely to write code to that standard.
Programming styles are as difficult to change as habits, and you'll have to accept that some people won't make their code 100% compliant 100% of the time. It would be worth your time to find (or write your own) pretty-printer program and periodically run all your code through it to enforce consistency. (I always felt uneasy when manually checking in source code changes that only consisted of formatting corrections for other peoples' code; I worried that others would label me a nitpicker.)
Sun Java Code Conventions
Python Style Guide
Zend Coding Standard for PHP
Having asked this question. I found that the accepted answer proved to be sufficient for my needs.
However, I realise that this is not a 'one-size-fits-all' scenario, so there is a large quantity of information within the thread that you may find more or less useful. Weel worth a read!
For Java and other C-family languages I recommend Sofware Monkey's coding standards (of course, since they're mine).
In general, keep them simple, and provide examples and justification for every requirement.
What's in the standard doesn't really matter all that much. What matters is that you have one, and that your developers follow it.
It doesn't quite answer the question, but it's worth a mention...
I read Steve McConnell's Code Complete. Whilst it doesn't give you a pre-baked set of coding standards it does set out a lot of good arguments for the various approaches. It'll make you think about things you'd not thought of before.
It changed my little world for the better.
Coding standards themselves are great and all, but what I think is much, much, MUCH more important is keeping with the style of whatever code you're maintaining. I've seen people add a function to some class written one way and forcing their coding standard on just that function. It's inconsistent, it sticks out, and, in my opinion, it makes it harder to enjoy the class "as a whole".
Whenever you're maintaining code, look at the code around it. See what the style is. K&R braces? Capital Camel Case methods? Hungarian? Double-line comment blocks between every function? Whatever it is, you should do it too in that specific area.
Before I leave, one thing I'd like to note that's related - naming files. I'm mainly a C++ guy, so this may not apply to whatever else, but basically it goes _.h or .cpp. So, Foo::Bar would be in Foo_Bar.h. Common things (i.e. a precompiled header) for the Foo namespace would be in Foo_common.h (note the lowercase common). Of course, that's a taste thing, but everybody who has worked with this has come out in favor of this.
i think Code Craft - The Practice of Writing Excellent Code pretty much sums it all up
Very popular are Ellemtel rules for C++.
For C# I recommend Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition) (Microsoft .NET Development Series).
Mono Coding Guidelines
The answers here a pretty complete, thus I am not pointing to another coding standard document. However, once you decided to stick to one style you should use an automated coding style enforcer throughout your team.
For Java there is checkstyle and for .NET Microsoft Style Cop.
Here is a similar discussion on Stackoverflow: C# Coding standard / Best practices
Camel and pascal casing alone solves a lot of coding standard problems