Moses-support Digest, Vol 103, Issue 72

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:25:53 -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=Vb=uTO3KQqBQ++m3TbeLbPWirK4E4SjLTbCo-w7Bi-g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Never mind - I see the difference reading down farther. In that case,
please change my vote from Java to Google.

On Wed, May 27, 2015 at 12:24 PM, Lane Schwartz <dowobeha@gmail.com> wrote:

> 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