-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 25.11.2014 v 13:27 Josef Reidinger napsal(a):
>> Ok, that's probably too much... What about 120? Personally I think the 80 >> chars limit does not make much sense with wide screen LCDs anymore... > > wide screen LCD do not help you in textmode with 80 chars width terminal. Also > it is not so easy to get code that is on so long line. In general need for > such > long line is code smell :) OK, I limited the length to 100 and fixed few longer lines. Going down to 80 is not that easy, rubocop reports 320 errors... >>> Another question why do you disable align of Arrays and Hashes? [...] >> Um, there was some problem with it, I'll look at it again... > > If there is problem if would be nice to document what exactly. Ok, found it, I had to set a different default style as I didn't like the rubocop's default. PR updated. >>> Is there reason to use new lambda syntax? >> >> Not really, our style guide does not mention this and the upstream style >> guide (https://github.com/bbatsov/ruby-style-guide#lambda-multi-line) >> suggests >> using ->() for single line functions and "lambda" for multi-line. [...] > It can be intersting how others see it. Any other opinions about this? I think this is not a critical decision as lambdas are not used much often... (My quick grep shows that there are ~3700 lambdas in all Yast code, but ~2700 out of them are in the old tests which should be replaced anyway. The rest is usually workflow sequence definition...) >>> Also what is reason to not check extra indentation for multiline operators? >>> I think it really helps with code readability and with coupling lines >>> together. OK, enabled, there was actually no problem with it... [...] >> We will need to adapt the config for each repository anyway, for example the >> maximum code complexity or max. method length will be different in each repo. > > agreed. But it would be good to define goal which we want reach. Like > complexity > smaller then 7 do not make sense. I think we should use common sense and decide case by case. The tool should work for us, not the other way round... For new code we could use stricter limits while for the old (converted) code we could use relaxed settings to just make sure we do not make the code worse. As it depends on the specific repository (how "good" the current code is) there cannot be a global goal. For the new code the goal could be to pass using the default rubocop code metric limits (i.e. without need to override/raise the defaults). - -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 [email protected] SUSE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUdK59AAoJEHHp6jkF1zbPapUH/19Rx2RYsW3pVrHN5hQFAf9O U/PreqQqJT82zBSiuGWIqj+oAlOXXFaQFd8bZgAQ/8iMJWbGyclXcCXt2K6+aPsX gMR+KurP8ugdCvYGOZ6g5SJsEGPC4JqfItlTc1Bhlxn7BB25Pxkj5zgIR0OOGYmY qzI5hspt50S/Q5bvx98PQyY4nZ1jEmdqlklLMIFB5CnaaCOUwGBTqT147L974LHO wheP/Xfcr4rFB7fGiNzjcfeTQ3HEf8Xujrx2nuCjUZpA/CQOq8TtmlfqTyMSRhbq 5tWl/sURZCzeyI+1DexGL1DaDJlaHJg/VrFYERGOKkrub1gSLnLtFJld7wnYENY= =p1df -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
