Moses-support Digest, Vol 103, Issue 66

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 (Jeroen Vermeulen)


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

Message: 1
Date: Wed, 27 May 2015 08:16:04 +0700
From: Jeroen Vermeulen <jtv@precisiontranslationtools.com>
Subject: Re: [Moses-support] New source formatter & checker
To: ugermann@inf.ed.ac.uk, Ulrich Germann <ulrich.germann@gmail.com>,
Hieu Hoang <hieuhoang@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>
Message-ID:
<269D83B1-3ABC-49EB-AC1D-47C713DA12D3@precisiontranslationtools.com>
Content-Type: text/plain; charset="utf-8"

On May 27, 2015 2:47:02 AM GMT+07:00, Ulrich Germann <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