Let’s try to add an additional method for retrieving all employees with a specific job title. The signature for this method was already defined in the IEmployeeRepository interface so I first tried to ask Copilot a question in a comment //Q:What interface member EmployeeRepository does not implement from IEmployeeRepository? ,but he wasn’t able to identify which methods are missing from an interface and I got zero suggestions for that one. After that I provided a comment in a natural language //implement GetByJobTitle which returns a list of employees with a given job title which in the current code context was clear enough for him. Copilot knew that method should return a list, not a single employee, as well as which property to include in the filter. Also, not from a comment but from the current code context, he could make an assumption to exclude deleted employees since the same condition was used in previous queries.

You need to provide descriptive and clear comments to Copilot. The better comment you provide – the higher your chances of getting a better suggestion. E.g. if we omit part of the comment related to the return value, Copilot couldn’t conclude that there could be more than one Employee with the given job title(since job title is not a unique identifier).

Let’s go one layer above, to EmployeeService. This class implements business logic. It contains methods that perform various operations related to employees. The class also uses a repository interface IEmployeeRepository to interact with the data layer and a mapping tool AutoMapper to map entities to DTOs (data transfer objects) and vice versa.

Let’s try to give Copilot a hint to implement retrieving of employees on a Service level with this simple comment. A simple comment //implement GetByJobTitle without pagination will do the work. Again, based on the comment it knows that it should call the GetByJobTitle method, and based on code context, it knows that it should use the repository for this call and that result should be mapped to DTO objects. Also, based on code context (e.g GetAll method), it returns distinct employees based on their email addresses.

Let’s try to add another, a little bit more complicated method to EmployeeRepository. The method is supposed to retrieve all employees who made a desk reservation in the current year. For this purpose, we should use Reservation property (collection navigation property) that allows the employee to access the related “Reservation” entities.

Firstly, I tried to ask Copilot for help to understand better what is Reservation property and what is the relation between Employee and Reservation table. In the image bellow you can see the questions I asked (comments starting with //q:) and the answers I got from Copilot, also via comments starting with //a:

Some of the answers Copilot provided were not correct. E.g. the answer to why ICollection<Reservation> is better to use is correct. Copilot sad that ICollection is more flexible than IList which makes sense, since ICollection is a more generic collection interface that allows more implementation freedom and versatility. But the reason Copilot provided (the last answer in the image) is not valid. ICollection<T> inherits from the IEnumerable<T> interface, which provides a subset of functionality for iterating through a collection, but it does not inherit from IList<T>. It’s the other way around, IList<T> inherits from ICollection<T>. Also Copilot stated that Employee table holds a foreign key reference to Reservation table, which is not correct.

Let’s continue with retrieving Employees who made desk reservation in some office in the current year. We received two suggestions from Copilot.

In terms of performance, the second query is likely to be more efficient than the first query. This is because the second query performs a single database query that filters the Employees table and loads only the relevant data into memory, while the first query performs two separate database queries and then filters the data in memory using LINQ. Copilot can generate multiple suggestions for code, but it is up to the you to evaluate them carefully and choose the best suggestion that fits your needs.

I tried to ask Copilot what a potential bug in this code might be, by providing it with a question within a comment (//q:What is a potential bug in this code?) but I didn’t get any suggestions while ChatGPT was more helpful with providing insights in potential bugs and issues with some peace of code.

The potential bug in this code is that it only checks whether an employee has a reservation with a start date in the current year. It does not check whether the reservation end date is also in the current year. This could result in returning some employees who have reservations that started in the previous year and ended in the current year.

Copilot can produce code with bugs or not completely correct code so it’s important to carefully review and test any code generated by Copilot to ensure that it meets the required functionality and is free of bugs or issues.

Docstring is a special type of comment used to document a method, property, class, or other elements of your code. Docstrings are written using XML documentation comments that provide a structured way to document your code.

Let’s try to test how Copilot can be helpful in this. Firstly, I tried to make Copilot generate the whole docstring for a simple method that retrieves an employee by its id, providing him just a comment, but I didn’t get any meaningful suggestions.

Since I didn’t get any relevant suggestions for multiple variations of this comment, I added docstring for a few methods manually expecting that Copilot will learn from the code context(the structure and content of the documentation, as well as from the code itself) and give me more useful suggestions later.

Here is an example of some docstrings I added manually.

So now, let’s go back to our method and see how Copilot behaves now. In the video below, you can see that after some learning, Copilot is able to generate docstring by itself, step by step. Each new row is a request to Copilot service and a new suggestion, so Copilot is still unable to generate the whole docstring suggestion within one request.

To avoid some unnecessary requests(for opening and closing xml tags) to Copilot service, since they sometimes can have bigger latency, I used a combination of manual docstring writing and Copilot suggestions. One issue here is that Copilot doesn’t offer any suggestions until I separate the start, value and the end of the XML tag in a new line. The suggestions provided by Copilot in this and other examples were useful for me and saved some of my time, but some of them weren’t accurate or clear enough and they needed corrections.

So, yes, Copilot can be a helpful tool for generating code and providing insights into programming concepts, but its answers may not be completely accurate or optimal. Therefore, it is important to carefully review and validate any comments or code generated by Copilot to ensure that it meets the requirements of the project and follows best coding practices.