3 ms·

I think jbooth is talking more about forced verbosity such as Map<String, Customer> customerMap = createCustomerMap(); where in other less verbose languages

by RyanZAG 11y ago

I think jbooth is talking more about forced verbosity such as Map<String, Customer> customerMap = createCustomerMap(); where in other less verbose languages you find val customerMap = createCustomerMap(); Always seeing the definition of a value in the current function context is actually very nice for maintainability, but does give Java the reputation of being overly verbose. Stuff like getters/setters on all values in a class are awful though and are both a code smell and unnecessary. They break the OO principles and should not be there in the first place. It's good that Java makes those 6 screens worth of getters and setters awful - they are awful. For objects which are used solely for transfering state, check out Google's AutoValue ( https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value ) However if you do see a class that is 6 screens of just getters and setters then you know exactly which class you need to fix.

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 ago
  Agreed, 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 ago
    That'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.

by RyanZAG 11y ago

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 ago
Agreed, 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 ago
  That'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.