On 2021-07-08 23:19:11+0800, Hu Jialun <hujialun@xxxxxxxxxxxxxxx> wrote:
> Junio C Hamano wrote:
> > char *hint_cleanup_all =
> > _("Please enter the ... , and an empty message aborts the commit.\n");
> > char *hint_cleanup_space =
> > _("Please enter the ... if you want to.\n"
> > "An empty message aborts the commit.\n");
> >
> > if (allow_empty_message) {
> > hint_cleanup_all = _("...");
> > hint_cleanup_space = _("...");
> > }
> >
> > ... the if/elseif cascade in which calls to status_printf() are made
> > ... using these variables
>
> Would it be better this way or just using the ternary operator in-line
> instead? If the latter, should it still be separated into another
> variable or just embedded in the status_printf call? Using the ternary
> operator does require to separate checks of allow_empty_message, but
> might as well save us an `if` construct to reassign the variable.
>
> In other words, which of the following 3 is the most acceptable?
>
> 1. As Junio suggested, quoted above.
I think this approach is the most expensive one, _() needs to query
the gettext infrastructure, which is usually costly.
However, I think that cost doesn't matter much since we're about to
open an editor soon.
> 2.
> status_printf(s, GIT_COLOR_NORMAL, allow_empty_message ?
> _("...") :
> _("...."), comment_line_char);
install_branch_config() uses this style.
>
> 3.
> const char *hint_foo = allow_empty_message ?
> _("...") :
> _("....");
builtin/remote.c:show_local_info_item() writes:
const char *msg;
if (condition)
msg = _("some message");
else
msg = _("other message");
So, I guess it's fine either way. And people will need to see the
patch to see which one is better.
> ......
> status_printf(s, GIT_COLOR_NORMAL, hint_foo, comment_line_char);
>
> --------------------------------------------------------------------
>
> Felipe Contreras wrote:
> > In git the style is to avoid braces if the content of the condition is a
> > single line.
>
> Đoàn Trần Công Danh wrote:
> > In Git project, it's enforced to have -Wdeclaration-after-statement,
> > IOW, move all declaration before statement.
>
> Noted with thanks!
>
> > After changing those texts, the tests should be updated, too.
> > It's a customary service for the next developer, who needs to bisect
> > this project to have all test-cases pass on each changes.
> >
> > With this change, t7500.50 and t7502.37 runs into failures.
> > Please fix them here, instead of next change.
>
> I did change test cases accordingly in the second patch (excerpt below), and
> both tests did pass afterwards. Was there something wrong with it?
Yes, when apply both 2 patches, the test passed, however, the test
doesn't pass with only 1/2 applied. Let's imagine in a near future,
some developers need to bisect some problems with Git with automation
scripts, and git-bisect stops at 1/2, since the tests report failure,
"git bisect run" will mark this change as "bad commit", thus render
git-bisect hard to use. We should make sure all tests pass on all
commit.
> And some perhaps rather noob questions below, as an (overly) curious
> newcomer,
>
> - Why is the "lego" style breakdown of translation strings unrecommended?
> I suppose it might be in consideration of possibly different linguistic
> sequences across languages but I'm not so sure.
Let's imagine an artificial language which have 2 words "linos" and
"linas" which is both translated to English as "lines", translators
need full context to decide which word should be chosen. Things maybe
complicated with language with gender, word-cases, etc...
There're some problems reported on and off this list [1]
> - What is the rationale behind prohibiting braces around single line
> constructs? It seems somewhat error-prone since somebody else could
> later be adding statements into the body without putting the curly
> braces.
Documentation/CodingGuidelines said so ;)
I don't think somebody adding random statements is a valid concern for
brace, I think it's expected to analyse the code context before doing
real-work on project. Furthermore, -Wmisleading-indentation is your
friends.
1: https://lore.kernel.org/git/20210509215250.33215-1-alexhenrie24@xxxxxxxxx/
--
Danh
