I like B because it helps me to easily reach the actual body when if or
for conditions span multiple lines.
Also there are other ambiguities in the code mainly with the use of
whitespaces and conciseness, it would be cool if we could have a consensus
on them. Please pardon me for trying to make everybody's life worse. :\
Some examples that I observed:
1. Number of characters in a line. This seems to be a subjective decision
right now.
2. Some files have semicolons at the end of lines.
3. Newline or no newline after the try block.
4. Whitespace between a keyword/identifier and { or no whitespace, this is
different sometimes within the same method.
5. If (Š) one-linear() OR
If (Š)
One-liner()
6. Naming standard for class instance members vs method local variables.
Well, this is not an ambiguity but being a new guy, I would definitely
appreciate having different standards here for easier reading of code.
7. /*Š*/ or //...
8. Some instances of function parameter indentation.
9. Rare placement of { in the next line after if or for.
10. def method(): contents.get or def method: contents.get
11. This happens in unit tests.
Val config = new KafkaConfig(props) {
(Number of whitespaces?) override val logFileSize = 1000
}
Thanks,
Swapnil
On 9/18/12 3:01 PM, "Prashanth Menon" <prashanth.men...@gmail.com> wrote:
>I prefer A, but go with C only when iterating over certain collections
>(maps/tuples etc) to take advantage of Scala's destructuring capabilities;
>in these case the spaced brackets make it easier to read.
>
>- Prashanth
>
>On Tue, Sep 18, 2012 at 5:42 PM, Neha Narkhede
><neha.narkh...@gmail.com>wrote:
>
>> Prefer A, but ok with B.
>>
>> Thanks,
>> Neha
>>
>> On Tue, Sep 18, 2012 at 2:35 PM, Jay Kreps <jay.kr...@gmail.com> wrote:
>> > The original code was in the style
>> > for(x <- lst) {..}
>> > A lot of newer code looks like
>> > for (x <- lst) {...}
>> > Some code also occasionally does
>> > for ( x <- lst ) {...}
>> >
>> > This is not a big deal but because I am obsessive compulsive I must
>>make
>> > all whitespace in a given file consistent. This results in big patches
>> with
>> > mostly trivial changes. Can we standardize on one of the above and
>> > opportunistically convert towards it?
>> >
>> > Let's call the above A, B, and C respectively. I vote for A, but am
>> pretty
>> > cool with B too.
>> >
>> > -Jay
>>
