There was a similar-ish question here on SO https://stackoverflow.com/questions/9475795/how-do-you-share-code-across-teams-working-on-very-different-projects but mine is about writing documentation.
Scenario:
Let's say my team is working on a software project, a Fany-WordPad like application which has a feature called Fancy-Word-Art ( just like MS Office's word Art). Now I wrote the code for the main window( using WPF in .Net, or using Window Builder in Java, doesn't matter which tool/language).
Now if my colleague Mr Spongebob is writing the Word-Art part, how would I tell him what functions to call / Api to use to draw on my window? i.e. How do I let Mr SpongeBob know that he needs to call GetWindow() method to get a reference to the drawing surface, the parameters he needs to pass along , and so on?
I hope I am being clear here. Is this the procedure?
Step 1 : Use your company wiki site to understand your colleague's written code
Step 2 : Write the GetWindow() method so that it works well with the rest of the project
Step 2 : Now put a wiki on your intranet with the method parameters/ data type requirement for your GetWindow() method or use Doxygen/ Confluence as suggested below
Step 3 : Now its your colleague Mr Spongebob's headache how to find how to draw his word-art on my window.
This just doesnt sound right .. With tons of functions, Spongebob's life will be hard, just as mine. Both of us rummaging through documentation to find the right functions to do our job. What if then I change GetWindow() to GetWindow(string title).. Now how do I literally tell the poor spongebob he needs to redo his code.
Am I missing something here? Please share your experience, how do you tackle this problem in a real world software house environment? If your fellow developer is on the next table , do you actually show them how to implement a certain method as they get stuck, or how do you deal with this situation?
thank you
Thanks
A good question. Of course i do not have the universal solution. Code documentation in msdn/sun style is a good base. But for concepts, architecture and so one you need more than this. In some projects we use wikis for that. For customer requests, we have a kind of ticket-system where we also store some (no-code) information to solution. All in all there is no central place for all the documentaion stuff.
Edit: Your code in self is often the best documentation, following clean code guidelines or something else is a real best practice :-)
Wikis are a cracking idea (good suggestion #Micha!). I used to use one in a previous company for a large engineering software/hardware project. It obviously spanned hardware and software guys and so it was a great way to share info across all teams. It's really useful if it's a long term project too - you can keep track of changes to functionality/API as things inevitably morph over time.
We used a paid service - Confluence if I remember rightly; but there are free wiki hosting sites too e.g. wikihost (just a quick google search, I can't vouch for them).
On another note though - have you thought about self documenting code at all? For example "Doxygen" or similar? Takes a lot of pain out of documenting every single function and also sets up a decent framework that can be padded out with more info where necessary. It also creates a nice UI for stepping through all the functions /class etc.
Edit: I've actually just started using Google Sites (sites.google.com) to create a wiki for a dev team I'm not working with. It's free (as in 'beer') and seems pretty good so far, although it does lack auto code formatting.
IMO you need both API documentation and plenty of examples.
You might get some mileage out of documenting your code of course, but if you're truly writing a system properly, your clients will never see your code. (That goes for clients in the calling sense, not necessarily in the "paying for your services" sense).
That's a fundamental of good practice and SOA, so you should really discard the "self documenting code" approach.
An alphabetic list of functions/methods/properties/whatever has value once the client has "got it" but until then, it's not immediately useful.
So that leaves you with having to showcase your creation. Give a bunch of immediately useful examples that demonstrate the kind of thing you envisaged. Make sure you have a simple example that demonstrates every function in its basic form with minimal interaction with the rest of the system (too many required interactions and you've probably not got a clean system anyway).
Once you have that, put it on a Wiki and encourage your users to enhance it. Consider using something interactive like a Stack-Overflow-like platform. MSDN is a good model but their examples often suck and can lack context. You might have the luxury of having more tight and specific uses than, say, the entire .NET framework. Early response to questions and updates to your examples/documentation will ensure your message gets across in the vital early days. This will help your documentation burden tail off quickly by looking after your clients and giving them useful, practical help.
Hope that helps.
In my projects I use a short description in my class files at the top, like:
//======
//
// modul: fileRunner.cs
// ...
// what: for playing audio/video
// depends on: consoleOutput.cs (Form)
//
//=======
#region HowToUse
//=======
//
// HowToUse
//
// 1. create instance of fileRunner:
// fileRunner p = new fileRunner();
// 2. run console program [progPath] with arguments [cmdsString]
// string output = p.RunExternalExe(progPath, cmdsString);
// 3. handle [output]
// if (output == "anyError"){do something;}
//
// [OUTPUT]
// "0" : process ended w/o errors
// "C" : canceled by user
// else: output is the string of the StdError, the called program submitted + StdOut after "Std output:"
//
// IMPORTANT
// Mention, this file depends on consoleOutput.cs to parse the output for gui.
// It doesn't support input ways, because the way ffmpeg is outputting doesn't allow it, it's not active
//=======
#endregion
For other classes I just named the public functions, that are self-describing.
An other option is to write on the top that they should look an the comment in the code and on the top of the public functions I use similar explanations:
#region convert an audio or video file from a drop
// FUNCTION: convertTo
// DOES: converting a file from a drop
// does not delete the original
// INPUT1: [path] as string,
// path to the destination file
// INPUT2: [e] as System.Windows.Forms.DragEventArgs,
// the args, the drop-object submits
// path of source file is in here
// OUTPUT: isConverted as bool,
// true if not (canceled or error raised)
public bool convertTo(string pWorkingFile, DragEventArgs e)
{
...
}
#endregion
If something changes you can mention it at the top too.
I think with SCM software it's a good option to mention the most important w/o wasting too much time on documentation.
as Stupid as it sounds, I would write him (Spongebob) a mail, or just tell him what he will need. If you already know who will need something in the near future, it is great if you can inform those peope before they strat to search and get headaches. Not everything in a project needs a technical Solution very often a human to human is much better.
Your documentation can also be in a wiki and then you can simply send Spongebob a link.
To reduce the pain involved in changing specifications over a large api, I'd suggest you follow the msdn/javadoc convention as mentioned earlier and also advice your team mate to use a modern IDE with autocompletion/autosuggest feature. Most of the common editors that provide auto suggestion also display documentation for the method/member to be used.
If you are seeking agile here, then docs and wikis are slight overkill; my 2 cents.
Why don't you just put your work in one git/svn project instead of working on the project parts independently? Then when you change a core function, you will see what it breaks and be responsible for fixing the methods that call it before committing your changes.
I am not a big fan of documenting extensively during development. It slows you down too much and you will have to redo it over and over again. Just create descriptive method names and be generous with you in-code comments.
For starters:
To help the situation between spongebob and yourself working together you will need some sort of Code Asset Management software (GIT, TFS, etc).
What if then I change GetWindow() to GetWindow(string title).. Now how do I literally tell the poor spongebob he needs to redo his code.
You should always start your day coding by "GET LATEST", meaning download code from the repository. If spongebob does this he will immediately see that he now needs to pass in string title as his code will stop compiling. It would be preferable that you literally tell spongebob that you have changed your code and he now needs to pass in a value, but if you are both checking in code every night and getting latest when you start coding for the day you should be both informed.
As far as the use of a WIKI or if you use Sharepoint doesnt matter. I would say to make it a little more efficient why not do this:
In your document repository (Wiki/Sharepoint) call the files by the page name so one is WordArt, the other is MainDocument, maybe one is PrintDocument (assuming these are different pages) and in the code you can simply put:
For more information on this visit the ___site at :http://yourrespositoryname.com/nameofprocedure
Related
I wrote an app in which there is a ton of comments.
This may be a bit unusual, but I would like to know if there is a way in Visual Studio to elegantly arrange the comments in a dedicated file. Or, is there a way to write text somewhere in a text file?
It is true that using comments is great, but my code is still congested.
Currently I plan to use a new class for comments, which will only contain comments with details on the parts of the code that are concerned.
If you have a better idea, thank you very much for sharing it.
I can't stress enough how much of a bad idea this is.
Code comments are best:
Being near the code they concern
Short and simple
Used sparingly - code often changes, comments can very quickly fall out of sync with this, and then before you know it the comments are doing more harm than good.
If there really is some functional explanation you're trying to get across, e.g. why something is needed and how it works, rather than how to use it, I'd recommend writing a document to explain this.
There are all sorts of ways to do this:
Word documents on a shared system (e.g. a network drive / sharepoint)
A wiki system online / internally (e.g. Atlassian Confluence, or GitHub wiki)
(to name a couple)
As per other user's suggestions though, you should ensure that there aren't a lot of comments as they just add noise (something you're clearly discovering).
Sidenote: I once worked for a company that insisted on using comments everywhere, every function had to have a banner comment with its name, signature, who wrote it and an edit history (even though we used source control), and nearly every line of code had to be commented to state what it was (supposedly) doing. If you're in a similar position, perhaps try to explain the problems this causes?
I've got an ASP.NET web application, that is essentially our intranet site. I made a lot of progress on the administration office's employee management pages. It ties into an SQL server database, and I'm using a three layered design (Objects, Logic, DataAccess). It was all reviewed and all of it was accepted, except! for the part that manages vacations and vacation histories.
My question, before I go into details is, how does one efficiently "untangle" code that is no longer necessary?
For example: previously I was treating each VacationDay as it's own entity with it's own history. Such that I could track the history of an individual day. To help in tracking, I have an enum called VacationDayAction, which includes options such as .Submitted, .RequestDenied, .CancellationRequested, and so on. This was in an attempt to provide meticulous detail for each day. It was then determined that we no longer need that. We do, however, still need VacationDays and all the basic functions of that (saving days, getting days, etc.), but now we no longer need any of the "history" related classes.
My problem is, when I right click a class that I no longer need in VS and go to "Show All References," I get a ton of results scattered across several pages. I need to get rid of all of them, without breaking the rest of the application. Is there not some kind of "smart" technique or method for easily untangling parts that are no longer necessary? This is particularly difficult because 90% of what I did was just fine, and needs to stay like it is. Yet scattered in that 90% is 10% of stuff that is no longer needed. I can't just go storming through with the delete key either, because with the removal of each reference, I need to be sure that any dependencies on that reference are also fixed in a way that they don't call stuff that isn't there anymore. And I still need the application is a compilable state, so that I can test along the way that the rest of the application didn't fall apart as a result of some deletion.
To give you an idea of my low level of experience, I started two years ago with having never used C#, ASP.Net, or Visual Studio. It blew my mind when, way after starting and as I was learning, someone taught me that I could use breakpoints. And then it really really blew my mind when I learned about multi-layered design. I'm wondering if there is not some technique or trick or feature that can help in scenarios like this, where you have to "untangle" and throw away unnecessary stuff.
This is not a simple question. In fact, I would say this is one of the major challenges for any systems developer; how to handle and get rid of old code which is not in use. There is lots of literature on this, and few really excellent answers. A good book may be "Working effectively with legacy code" by Michael Feathers, which deals with many related problems. It is no light read though, and will probably take some time to get through, but it will likely help you become a better coder, and better at these kinds of tasks in particular.
Maybe you can have a look at the Resharper tool? ( http://www.jetbrains.com/resharper/ ) It is a productivity tool which among other things shows "dead" code (unused code) in grey, and lets you remove it. It will also help you remove unused references from each class (again, they will be grayed out and let you remove them automatically).
Drawing diagrams where each major piece of code /component is a box with a line linking it to any related component might help you get a better overview; try to draw a hierarchy showing how different parts of the code are related and dependent.
The bottom line as far as I know, is that you just have to muddle through it, commenting out code a little at a time, then recompiling and testing it. If it still works, fine, now you can remove the commented out code completely. This would be easier if you had unit-tests covering your code, but I take it as a given that you don't, as is unfortunately often the case.
I'm trying to write a visualiser for some code which generates graphics for barcodes and labels. The way I want to do this is by recording the methods+parameters being run to a file, so I can play them back and see the visual output generated at each stage (so a kind of visual debugger to help me fix issues with measurements in the drawing)
I have access to the methods, and I can put anything I like in them - but I'm stuck on the best way to record the method signature being called and the parameters, especially since a lot of them are overloads etc.
Is there anything simple that will help me serialize/record actual method call information? (with a view to replay it back, so I need to programmatically load the information and call it) Perhaps something reflection-related?
Note: I'm an intern on the project I'm working on, and I'm probably not allow to introduce new assemblies etc. into the build, so I think aspect-based things requiring libraries are out. (At the same time, I'm not just asking a Q. I should be figuring out myself - this is more an additional thing I'm doing during my lunch break to help my main task)
It might be a good idea to start from an existing profiler as a base - e.g. from http://code.google.com/p/slimtune/
Note that profilers themselves are quite complicated - for .Net they require some C++/COM knowledge - but if you start from a base like slimtune, then hopefully you'll be able to avoid this core code and will instead be able to focus on your own visualisation requirements.
Recording the method name itself is easy, parameters will be more difficult. I think the only way to generically retrieve the parameters is to use reflection--the alternative is to have an ungodly amount of logging code where you explicitly log every parameter.
Also consider that you'll need all parameters to be serializable, and depending on how you want the file to be used (by a program vs. human readable) you might have to implement quite a bit of boilerplate serialization code.
You should really consider existing profiling tools and testing tools rather than thinking of inventing something new. It sounds like performance tests or integration tests may be more valuable than a "playback" utility.
If it is possible to auto-format code before and after a source control commit, checkout, diff, etc. does a company really need a standard code style?
It feels like standard coding style debates that have been raging since programming began like "put the bracket on the following line" or "properly indent your (" are no longer essential.
I realize in languages where white space matters the diff will have to consider it but for languages where the style is a personal preference is there really a need to worry about it anymore?
Auto-format can really only address whitespace.
It wont address developers giving variables bizarre nonsensical names.
It won't address some developers having functions return null on an error vs throwing an exception.
I'm sure others can think of more examples.
This is what we do at my work:
We all use Eclipse. We don't have a policy for using Eclipse but somehow none of us is an IDEA/IntelliJ guy. We also think our code should be written with legacy in mind. This means our code has to be readable in a certain way even years after (#1) no matter who wrote it and if that person even is in the company anymore.
Eclipse has couple handy features, automatic format on save and a specific Formatter tool. As you can see from the linked screenshot, it can be configured with XML. Thus there's a bunch of premade XML:s available for every worker in our company so that when a new guy comes in, we walk him through of the whole process and configure their Eclipse for them (yes, it's slightly evil thing to do) so that it actually uses those formatting XML:s we have provided. We do not enforce automatic format on save, we don't want to be completely intrusive, we just want to push all our developers into the right directions. For even increased compatability, we mostly use rules defined in JCC.
Next comes the important part, the actual builds. We are those who embrace automatic builds and for that we use Hudson Continuous Integration Server. There's two important parts in our configurations beyond this:
We use CVS loginfo to trigger builds whenever something is committed.
We utilize several plugins available for Hudson, including Continuous Integration Game in conjuction with the most important one, Checkstyle.
The Checkstyle Plugin is the magician in our code style enforcement guide line:
After commiting code to CVS, Hudson build is triggered
After build has been completed succesfully (all unit tests pass etc.), Checkstyle inspects the actual source files
Checkstyle ranks the code based rules we have defined for it
Continuous Integration Game sees the result of Checkstyle and awards/takes away points for the person who has the ownership for the relevant part of the code
Leaderboard shows total points for every commiter in system
Basically this means that when anyone commits ugly code into our CVS, our build server automatically reduces that person's points.
This means that eventually any one of us can be ranked on the Leaderboard based on the general code quality in both look and OO principles such as Law of Demeter, Cyclomatic complexity etc. etc. Naturally this isn't a completely serious statistic, but it's a good indication you're doing something wrong when causing a build to be initiated in our CI won't reduce your points - most of our commits are worth between 1 and 5 points.
And is it working? Sort of, I don't think anyone of us at my work writes ugly or unmaintainable code and personally I love to hunt all kinds of scores so it's definitely motivating me to make code that looks nice and follows all the OO paradigms I know of.
And do we as a company really need it? I think we do as you should see from reading this entire answer, it can be considered a good practice for the advancements it brings.
#1: in a related note, I refactored legacy code from 2002 today which used those standards, didn't look "bad" at all even in its original form and certainly not worse in its new form
No, not really.
If you can actually get it to work consistently and not make it flag code has changed due to a different style of laying the code out.
However, this is just a small part of coding standards. It won't cover multiple return statements, the use or not of ternary operators, etc.
It is always nice if the coding style that the shop uses is the same one that is also followed by the development tools.
Otherwise, if there is a large body of code that already follows a shop standard which is NOT the same as that of the tools you have two choices:
Modify all of the code to follow the tool standard, or
Maintain the existing shop standard.
Many shops do the latter. Regardless, there does need to be some kind of standard, and it does need to be followed.
Some development tools allow you to tweak their standard. In some cases you may be able to bring the tools in alignment with the shop standard.
It probably doesn't matter that much anymore if you can ensure that everybody in the team sees the source code "correctly" formatted, whatever they think it is. However I've not seen a system that can do that - you can do parts of it (say, reformat before and after checkin/checkout) but these days you also have to consider web interfaces into the version control, external code review systems that interact directly with the version control system etc.
The main purpose of a standard code style is (IMHO) to ensure that you can read other team members' code easily without having to start reverse engineering it because all the code is written using the same sort of guiding principles. Indenting and parentheses placement seem to be a major hangup on this but they are only a very small and in my opinion, somewhat overblown and not very important part of the need to make code consistent.
Unfortunately I'm not aware of any tools that can automatically apply consistent coding principles to source code...
Yes, coding styles are needed if there is a desire to have a homogeneous code base. Such a code base can be useful in preventing individual ownership of parts of the code base, which can cause problems when people leave the team. If you can't imagine having wildly different styles and problems understanding all of it, just look at all the different ways English text can be organized in various communications, all written but quite different such as tweets, e-mail, text messages, IM, message board posts, etc. and changes in fonts, capitalization, decorations, etc.
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