Frederik Ramm wrote:
Would you be able to supply such a style sheet that approximately
matches the current formatting (as far as this is at all discernible)?
Of course they are not all discernible - I would be surprised if not. I
checked a small randomly chosen file set and compared the
Hi,
1. Indentation: space vs. tab
I'd go for spaces always.
2. Maximum line length:
A large number of files do contain very lengthy lines, mostly for
defining strings with display messages. Other files use a maximum line
length of ap. 100-140 characters (which is my favorite setting,
Frederik Ramm wrote:
Generally I'd avoid long lines but we must take care not to make life
difficult for translators. Does it pose a problem for translation if
one says
tr(some + long + message)
instead of
tr(some long message)
As tr() is a static function that is called at
Hi,
As tr() is a static function that is called at runtime this should not
make any difference.
I am unsure how the process that extracts the string constants to be
translated works. It can't possibly *execute* every branch of code that
contains a tr()? But as I said, not my core competency
On Wed, 27 Aug 2008, Frederik Ramm wrote:
As tr() is a static function that is called at runtime this should not
make any difference.
No. The translations are extracted from the sources, so the source design
is important. You can't use whatever methods to join a string, as these
will not be
Hi,
That would be avoidable if we could agree to a common source code
formatting standard (in form of an style sheet file as it it used e.g.
by Eclipse). Then every body would only have to apply the common source
code formatter on the source before checking in /creating a patch.
Would you
Petr Nejedly wrote:
It would be fine if Jörg cold separate the real functional patch
from all the unrelated formatting changes. It is quite hard to follow
the semantics of the change in all the noise...
That would be avoidable if we could agree to a common source code
formatting standard (in
