(there's also an argument in there that "handlers.LoggingHandler" should
actually be called at most "handlers.Logging", but probably even
"handlers.Log". And that the other names are also not great… but that's a
different argument)
On Fri, Sep 8, 2017 at 8:21 PM, Axel Wagner
wrote:
> I think peo
I think people are focusing on the wrong part of Jakob's reply. Focus on
the "if your line is too long, it's probably a symptom of a too complicated
expression" part, not the "line-length limit doesn't matter" part.
I am very rarely exceeding 80 columns. For example:
var h http.Handler
h = handl
I haven't edited on a true text mode terminal since 1992, but a column
limit is still useful. This and the other Go standards for relatively
fixed formatting are not its strong suit.
On Wednesday, September 6, 2017 at 11:36:04 PM UTC-7, Jakob Borg wrote:
>
> On 7 Sep 2017, at 06:10, Sankar >
>
Hi
*Typically you can break your lines after comma ,,
> after opening parenthesis e.g. (, [, {, and after a dot . which may be
> referencing a field or method of some value. You can also break your line
> after binary operators (those that require 2 operands), e.g.:*
Complete answer:
https:/
Even with most modern laptops, I found having 80 column limit is very
useful, when we split panes and read code. May be it is just my personal
preference :)
2017-09-07 12:05 GMT+05:30 Jakob Borg :
> On 7 Sep 2017, at 06:10, Sankar wrote:
> >
> > Are there any tools available for golang to split
On 7 Sep 2017, at 06:10, Sankar wrote:
>
> Are there any tools available for golang to split long functions so that they
> can fit in 80 columns (as long as possible) ?
Don't fear longer lines, most of us are not on text mode terminals any more. :)
When it becomes *too* long it's probably har
