On Thu, Dec 05, 2019 at 05:04:12PM +0100, Jakub Jelinek wrote: > On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote: > > On 2019-12-05T16:15:15+0100, Jakub Jelinek <ja...@redhat.com> wrote: > > > [...] much more indented though, but you could > > > use a temporary, like: > > > tree nullarg = null_pointer_node; > > > > I object to cluttering the code by introducing temporary variables/names > > just for the sake of a few characters of screen width. Even if located > > close lexically, when reading the following code you still have to trace > > back from the 'nullarg' usage to its 'null_pointer_node' definition in > > order to figure out what a 'nullarg' might be: > > > > > if (present) > > > ptr > > > = gfc_build_conditional_assign_expr (block, present, > > > ptr, nullarg); > > > > > Another option would be shorten the name of the function, say > > > s/conditional/cond/. > > > > Likewise I object to "crippling" identifier names like that just for the > > sake of a few characters of screen width. (Here of course, "cond", or > > the existing "expr" might be fine abbreviations, but my point is about > > the general case.) > > The point about temporaries is general, and I believe they actually make > code much more readable. Mostly about coding style like: > t = fold_build2_loc (loc, code, fold_build2_loc (loc, code2, > something1, > something2), > fold_build2_loc (loc, code3, something3, > something4)); > vs. > tree op1 = fold_build2_loc (loc, code2, something1, something2); > tree op2 = fold_build2_loc (loc, code3, something3, something4); > t = fold_build2_loc (loc, code, op1, op2);
Yes. And the names, even if they do not say much, *do* say enough to help comprehending the code. They help structure it. > The above case is extreme in both being indented quite a lot (general rule > is to consider outlining something into a function then) I hope you mean actual factoring, not just outlining :-) If you pick good factors you can give them good names, too. Good names help reading the code. And on the other hand, when it is hard to come up with a good name for a piece of code, it is probably not chosen as a good factor anyway! > and using > way too long function names. If you look at the earlier suggestion where > the code is indented reasonably, using the temporary there makes the code more > readable and shorter. Yup. Segher
