On 13/11/2015 15:01, Jan Stolarek wrote:
My view on this is:
Firstly, I hate explaining myself to Arcanist. When prompted to explain the
reason for too long
lines I typically enter "wontfix" without thinking too much.
Secondly, I really don't like how warnings clutter code reviews.
I have my Emacs highlight text beyond 80th column with a really ugly colour, so
I strive real hard
to maintain 80-column limit whenever possible. But sometimes fitting in that
limit is nearly
impossible: imagine being in a let nested in a do-notation nested in a guard
nested in a where
clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I
would support
introducing a hard limit on having no more than 80 columns.
Janek
PS. It makes me really sad that we don't have any coding convention for GHC: we
mix camelCase with
underscore_case, indentation is inconsistent (good thing we at least got rid of
tabs!),
whitespace usage is inconsistent, etc. I could make this list very long.
Why not write down a set of style guidelines and get everyone to agree
to them? I'd happily compromise my personal stylistic preferences if
there was a standard style that we all agreed on and tried to adhere to.
Personally I think a good starting point is
http://chrisdone.github.io/hindent/HIndent-Styles-JohanTibell.html
Incidentally the mixed camelCase and underscore style is deliberate:
underscores for local identifiers, camelCase for exported functions.
It's a cute idea I've been using for a long time, but we don't have to
do it that way. At work we use camelCase exclusively and it's fine.
Cheers,
Simon
---
Politechnika �ódzka
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the individual
to whom it is addressed.
If you are not the intended recipient or if you have received this message in
error,
please notify the sender and delete it from your system.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
