On Monday we talked about a solution to the Roman-to-Arabic problem.  Here it is again

translate :: Char -> Int

translate 'I' = 1

translate 'V' = 5

translate 'X' = 10

translate 'L' = 50

translate 'C' = 100

translate 'D' = 500

translate 'M' = 1000

 

romanToArabic :: String -> Int

romanToArabic "" = 0

romanToArabic [r] = translate r

romanToArabic str = num + romanToArabic rest

   where (num, rest) = oneStep str

 

oneStep :: String  -> (Int, String)

oneStep (r1:r2:rest)

  | translate r1 < translate r2 = (translate r2 - translate r1, rest)

  | otherwise = (translate r1, r2:rest)

 

So far, this is the cleanest solution to this problem I have seen that uses only the constructs covered to the time the project was assigned. That doesn't mean there isn't an even better solution. But this is the best I've seen. I mention this because I want you to know that I value craftsmanship and code elegance. There is no definitive definition of what it means for code to be elegant. Here are a few attempts.

When I talk to you about your code, one of the things I notice is whether you have attempted to make your code elegant. You don't have to achieve perfection, but when I see code that looks like you don't care about it, I downgrade my estimate of you. Among the basic things you should think about are:

• Function and variable names.  They should be meaningful and correct. Also, try to conform to Haskell convention. For example, a list is frequently: a1:a2:as. This means that you are referring to the first element as a1, the second element as a2, and the rest of the list as as, which is often interpreted to mean the "a's". The above example used r1:r2:rest. That's fine. it doesn't have to be r1:r2:rs.

 

• Formatting. The code should be easy to read. Each function should have a declaration.

 

• Functionality. The code should do what it's intended to do in as simple and straightforward a way as possible. More often than not, when talking to people about their code we find ways to simplify and improve it. I want you to think about simplifying and improving your code before talking to me. For example, in the credit card problem I see code that reverses the list of digits multiple times. When we talk about why it was written that way -- rather than just reversing it exactly as much as needed -- it seems that the person hadn't noticed the redundant reversals or hadn't asked themselves why they were doing it that way.
  
  Of course you can't make your code as simple and straightforward as possible unless you understand thoroughly both what the code is intended to do and how it accomplishes that task. If you don't understand one or the other, you portray yourself in a bad light. So be sure that for each function you understand and can explain (a) what that function is supposed to accomplish and (b) the strategy the code uses to accomplish that objective. These are two relatively independent things, and you should be able to explain each one on its own.

I want to see that you have pride in your product. Unless it's clear that you have made the code as good as you can, you convey the impression that don't have pride in your product and don't care about your workmanship.