Moses-support Digest, Vol 103, Issue 79

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 (Hieu Hoang)


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

Message: 1
Date: Sun, 31 May 2015 18:10:08 +0400
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] New source formatter & checker
To: Jeroen Vermeulen <jtv@precisiontranslationtools.com>, Ulrich
Germann <ugermann@inf.ed.ac.uk>, Ulrich Germann
<ulrich.germann@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<CAEKMkbgj_=nsABgD3AixO4Fm3tqXHzsw_ni3YZ0EYiw89rY-pA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Ladies and gentlemen,

Polls are now closed. There were 15 responses, 1 void result 'cos it didn't
have a name. This is the summary of the results:
Q1. 13-1 in favour of beautfiying. Given this overwhelming response, we
will look to running the beautifier regularly. Using the git hook and/or
daily cronjob, whatever is easiest to implement that works.
Q2. 8-3 in favour format (1), 3 don't care.
Q3. 6 people voted for the google style, a scattering for other formats.
The only problem is the astyle version we are using is rather old and
doesn't have this option! We have to set the aside until we update to
astyle. The current format is K&R, which is similar.

Detailed results are here:
https://www.surveymonkey.com/results/SM-3H2PH37D/

Thank you all for voting. Fun over, get back to work



Hieu Hoang
Researcher
New York University, Abu Dhabi
http://www.hoang.co.uk/hieu

On 27 May 2015 at 18:58, 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