Thursday, June 23, 2016

Is C# Better than Java?

Ways it's better:


  1. Default argument values for methods - Java doesn't have them, which means you always have to "fake it" by creating numerous overloads to achieve the same effect.
  2. Support for unsigned integer types - Java doesn't have them, which means you have to play games with signed values of different sizes to achieve the same effect.
  3. Support for multiple languages in .NET. In C#, you can create and interact with objects defined in other programming languages. There is already support for several built in, like VB and C++, and others freely available, like Python.
  4. Lambdas. Java says "Wuh?". Actually, lambdas are a lot like Java anonymous inner classes, except they implement a delegate instead of a class or interface. The same semantics apply WRT closures and scope.
  5. Documentation is excellent in MSDN for C# and all aspects of .NET. There is developer reference as well as programming guides. The primary source of (vendor-supplied) documentation for Java is the Javadoc, which really is just an API reference; if I need guidance, I usually need to google it.
  6. Anonymous methods. Java ain't got 'em.


Shortcomings:

  1. Visual Studio is quite expensive for the average coder for the Professional edition or above, and the free "Express" edition sucks in comparison. Java development in Eclipse provides a free, full-featured IDE.

Similarities:


  1. Static constructors == Java static blocks
  2. You can specify a multi-level namespace in a single statement (instead of multiple namespace statements). This is basically the same as Java's package declaration.


Differences:


  1. A static class in C# == final Java class with only static members and private constructor
  2. Anonymous types are not Java anonymous classes. C# anonymous types are anonymous objects with no defined type at all. Java anonymous classes are subclasses of existing classes or interfaces that are assigned to a variable of that type.



Wednesday, June 15, 2016

Are Unit Test Frameworks Really That Great?


Unit test frameworks seem great. Modern test utilities like Mokito and PowerMokito give you the ability to test any part of your code, no matter how hard they are to get to, and no matter how inflexible and poorly designed the code is.

I can test my private methods! This is great!!

Or is it?

The public interface for that class changed. The functionality is only a little different. But the implementation is bunk, and it has to be redone!

Which would be more work?

A -- update unit tests that verify only the functionality of the public interface (which only has minor changes)?

B -- rewrite the unit tests almost from scratch, because they are tied inextricably to the private implementation and will all completely fail after the production code is rewritten?

The answer should be obvious, but if not...

A complete rewrite is more work, even for test code.