Hacker News Reader

Comment by adamtulinius | Hacker News Reader

And obviously practicality can get in the way. 80 character lines will be a nightmare in a java-project with verbose naming schemes (FactoryFactoryObjectThingymybobProducer thingy = new FactoryFactoryObjectThingymybobProducer(..);).

View on HN

Or python if you're already in a function in a function in a class (so 68 chars left). If you also standardised on importing modules, not classes things can get silly. My favourite counter-example to the 80 char limit was a line in openstack which was:

    return some_loaded_module.fairly_descriptive_but_necessarily_long_name(not_very_long_argument)

The way applied to fit it without forced line breaking?

    fdbnln = some_loaded_module.fairly_descriptive_but_necessarily_long_name
    return fdbnln(not_very_long_argument)

(yes, actually using first letters of words) Because yeah... that makes things simpler than just crossing the limit in that place.

In perl I'd just write -

    return $some_loaded_thing->fairly_descriptive_but_necessarily_long_name(
      $not_very_long_argument
    );

Surely python has something approximating an equivalent?

Come on, you can get rid of the return statement if it is the last line in a subroutine.

sorry, it was the return itself that was making it too long already. Basically assigning it locally took just exactly the number of characters, return was sticking out by one or two.

Is Java still lacking constructs like

     var thingy = FactoryFactoryObjectThingymybobProducer

The compiler actually knows what type is on the right of the = sign. Having to write FactoryFactoryObjectThingymybobProducer is not good for anything.

Usually this is not what you want to separate interfaces from implementations. For example, this:

    List<T> l = new ArrayList<T>();

is preferred to this:

    ArrayList<T> l = new ArrayList<T>();

Of course, it would be nice for the compiler to assume the latter if no type is specified on the left side.

Reply on news.ycombinator.com