3 ms·
I agree with you, up to a point. I find Ruby code pretty awful to make sense of with very little type information. Type inference with explicit return types for
by jinst8gmi 11y ago
I agree with you, up to a point. I find Ruby code pretty awful to make sense of with very little type information. Type inference with explicit return types for methods strikes a nice balance between verbosity and readability. I think Scala, Kotlin and to some extent C# do a better job of this than Java.
There are also many less favourable cases where you see things like:
Customer customer = new Customer();
String str = "I'm a String"
SomethingOrOtherFactory factory = new SomethingOrOtherFactory();
which isn't any clearer than:
val customer = new Customer();
val str = "I'm a String"
val factory = new SomethingOrOtherFactory()
Having a dozen getter/setters is generally a code smell, but having a dozen getters isn't.
- RyanZAG 11y agoAgreed, but: Animal customer = new Cat(); It makes it clear how the new object will be used. It does come up quite frequently, especially with Collection and List. Nobody was saying it is not verbose and can lead to boilerplate. The assertion is that when viewing a large code base, you are always sure of the type of value you are dealing with on a local level. If all of your objects are well defined, you don't even need to look at how the class is created (a billion getters and setters? irrelevant to the local function) as you only need to deal with the local function.
- lmm 11y agoThat's there if you want it though. val customer = new Cat(): Animal I can see arguments against inter-method type inference, but I think there's no real argument against type inference within a single method (requiring explicit types on method boundaries). If you have a billion-line method you have bigger problems.