[adamtulinius]

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(..);).

[viraptor]

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.

[mst]

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?

[collyw]

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

[viraptor]

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.

[acqq]

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.

[rld]

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.