Moses-support Digest, Vol 103, Issue 71

Send Moses-support mailing list submissions to
moses-support@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu

You can reach the person managing the list at
moses-support-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."


Today's Topics:

1. Re: New source formatter & checker (Lane Schwartz)


----------------------------------------------------------------------

Message: 1
Date: Wed, 27 May 2015 12:24:06 -0500
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] New source formatter & checker
To: Hieu Hoang <hieuhoang@gmail.com>
Cc: Ulrich Germann <ulrich.germann@gmail.com>, "moses-support@mit.edu"
<moses-support@mit.edu>
Message-ID:
<CABv3vZ=WV2uK2q_=PFMNEaJHY-hBqZbj30mYh3zHHQWyTFPotg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hieu,

What's the difference between Java and Google styles? They look the same to
me in the examples. I voted Java, but I'd be fine with Google, since it
looks basically the same.

Lane


On Wed, May 27, 2015 at 9:58 AM, Hieu Hoang <hieuhoang@gmail.com> wrote:

> seems like referendums are all the rage at the moment so we're gonna
> have 1 to decide coding style.
> https://www.surveymonkey.com/s/BN38LBQ
> If you work with the Moses code, please vote. This will give us a clear
> mandate for future development.
>
> Polls will open until Sunday evening. All results are public
>
> On 27/05/2015 05:16, Jeroen Vermeulen wrote:
>
> On May 27, 2015 2:47:02 AM GMT+07:00, Ulrich Germann
> <ulrich.germann@gmail.com> <ulrich.germann@gmail.com> wrote:
>>
>> Well, the second document does indeed give some darn good arguments for
>> trailing braces: 1. "
>> as shown to us by the prophets Kernighan and Ritchie
>> "; 2. "
>> K&R are _right_ and [...] K&R are right
>> "; 3. "
>> think 25-line terminal screens here
>> "
>>
>> The document also has other great suggestions that we may want to
>> adopt."
>> Tabs are 8 characters, and thus indentations are also 8 characters
>> "
>>
>> The fact is: with trailing braces and steadfast refusal to use vertical
>> space to improve
>> code readibility, you do need a tab width of 8 or so to be able to
>> recognize code blocks.
>>
>> Incidentally, there's actually one recommendation in that document that
>> IS worth
>> adopting *(and in which pretty much all style guides agree plus-minus 5
>> characters or so):*
>>
>> The limit on the length of lines is 80 columns and this is a
>> strongly preferred limit.
>>
>> Let me repeat that:
>>
>> The limit on the length of lines is 80 columns and this is a
>> strongly preferred limit.
>>
>> And again:
>>
>> The limit on the length of lines is 80 columns and this is a
>> strongly preferred limit.
>>
>> That is the only thing worth really considering from that document.
>>
>> We can safely consider the 25-line limit a thing of the past unless you
>> program on
>> your mobile phone. However, there is a good justification for the
>> 80-column
>> limit: merging code, where it's useful to see the code side by side. When
>> resolving merge conflicts in git, we are usually dealing with 3 versions
>> that need
>> to be compared. Those three columns won't fit on my screen when lines are
>> 120+
>> characters long.
>>
>> I digress. Back to the braces issue. Unlike the arguments for trailing
>> braces
>> (K&R did it in a printed book to save paper; I'm a retro programmer who
>> likes to
>> do things old school; it obscures my code so people will think I'm really
>> awesome
>> because they can't really understand what I'm doing without lots of
>> effort, just like
>> Derrida and Piaget didn't write to be understood --- they wrote NOT to be
>> understood),
>> so unlike these arguments, there are very good arguments for having
>> opening braces
>> on a new line and vertically aligned with the closing bracket.
>>
>> 1. It's much easier to recognize logical code blocks. It is. Try it
>> out. Read code that you
>> haven't written and be honest with yourself. It may seem unfamiliar
>> at first, but once
>> you are used to it, there's no turning back.
>>
>> 2. If you want to temporarily disable a condition (e.g. in debugging),
>> you just comment
>> out the if statement. You do not have to THEN put an opening brace at
>> the beginning
>> of the line (extra editing) and remove it later (extra editing again)
>> --- which also
>> FORCES you to be inconsistent. (You can't always remove the braces
>> because
>> of variable scoping). You have the same issue when you want to use
>> preprocessor
>> commands to have conditions only under certain circumstances, so
>> instead of
>> #ifdef ENABLE_CONDITION
>> if (condition)
>>

Tweet