With the impending release of C# 6.0 and all its new features, I have been thinking about what might come in the next version of C# (v7.0, I’m guessing). There has been talk in the Roslyn forums about things such as pattern matching and record types (the latter being especially important since the primary constructors feature was dropped from C# 6.0).
Below is a quick sketch of how I think record classes should work in C#. You can probably tell that I spend a lot of time programming functionally, because I’ve included a number of syntax features here to make immutability a very easy option.
This is a classic quick programming puzzle: write a function that, given two rectangles, will determine if the triangles overlap. I found this puzzle over on http://leetcode.com/2011/05/determine-if-two-rectangles-overlap.html, and thought it was worth talking about because the solution is wrong, and it was interesting to me because it shows how thinking about a domain can influence your implementation of behaviour.
The mistake made by the original author is with one of the assumptions / interpretations made during their reasoning process. They said “when two rectangles overlap, one rectangle’s corner point(s) must [be contained within] the other rectangle”. This appears reasonable, given the example below:
At my last company I was a team lead and, as such, was one of those responsible for interviewing new candidates. Although I didn’t enjoy the process much, I did become interested in the sorts of technical questions / exercises we could set to get a good judge of a candidate’s abilities.
Developer interviews typically cross a number of disciplines (often arranged in stages) that may include:
- a CV / résumé screening
- a telephone interview
- face-to-face questions and answers
- a technical exercise or written test to be done at home, or to be done in front of the interviewers
I was prompted to write this after reading Mark Seemann’s post (http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/)
Following Single Responsibility Principle will lead you down the road of having plenty of small classes.
Open Close Principle will lead you down the way of encapsulating the core logic of each type in it, and then delegating all other work to its dependencies, causing most of those small classes to have multiple dependencies.
This is another entry in the brain teaser / programming exercise / interview question collection. It goes like this:
Imagine a list of consecutive numbers. The list is, however, unsorted and one number is missing. Write a function that finds which number is missing with the constraint that you may only allocate O(1) memory (i.e. the amount of memory you use cannot vary with the size of the list).
The fact that the list is unsorted means that you cannot step through in a pairwise fashion and compare each element of the list to the next to see if they are consecutive. Sure, we could sort the array first but the fact that you cannot allocate memory according to the size of the array means that you cannot create a helper array in the solution and certain sorting algorithms are ruled out. An in-place sorting algorithm such as quicksort would do it, but I don’t think that sorting the array is the best way to go.
What if we sum the list? We’re talking about a sequence of integers, after all. It turns out that there is a linear formula for calculating the sum of a sequence of consecutive integers: sum(1..n) = n(n+1) / 2.
This means that you can work out what the sum of the input list should be; all we must do it actually sum the list and the difference between the two will be the missing number. Our implementation then looks like this:
let findMissing (list : int array) = let n = list.Length + 1 let expectedSum = n * (n + 1) / 2 let actualSum = Seq.sum list expectedSum - actualSum
Note the let n = list.Length + 1. We have to add one to the length of the list to get the max element in the list because one element is missing. After that it’s pretty simple!
Tabs are blatantly the correct answer.
Tabs separate code content from presentation. Indentation style becomes entirely personal, and each dev can adjust to their own tastes without affecting anyone else. Imagine that I have my editor set to tabs as four spaces. Then, I open a file from another developer who has tabs set as two spaces. Now, in order to write into his file, I have to go into my editor’s options and change my settings to reflect his convention otherwise the code that I’ve written will not match the code that he’s written. Bad times.