On Sun, Jan 11, 2015 at 12:22:49 +0200, Eliad Peller wrote: > On Fri, Jan 9, 2015 at 7:03 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: >> Giel van Schijndel <me@xxxxxxxxx> writes: >>> This highlights the differences (e.g. the bug fixed in the previous >>> commit). >>> >>> Signed-off-by: Giel van Schijndel <me@xxxxxxxxx> >>> --- >>> drivers/net/wireless/ti/wlcore/acx.c | 22 +++++++++++----------- >>> 1 file changed, 11 insertions(+), 11 deletions(-) >>> >>> diff --git a/drivers/net/wireless/ti/wlcore/acx.c b/drivers/net/wireless/ti/wlcore/acx.c >>> index f28fa3b..93a2fa8 100644 >>> --- a/drivers/net/wireless/ti/wlcore/acx.c >>> +++ b/drivers/net/wireless/ti/wlcore/acx.c >>> @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl) >>> goto out; >>> } >>> >>> - acx->recover_time = cpu_to_le32(conf->recover_time); >>> - acx->hangover_period = conf->hangover_period; >>> - acx->dynamic_mode = conf->dynamic_mode; >>> - acx->early_termination_mode = conf->early_termination_mode; >>> - acx->max_period = conf->max_period; >>> - acx->min_period = conf->min_period; >>> - acx->increase_delta = conf->increase_delta; >>> - acx->decrease_delta = conf->decrease_delta; >>> - acx->quiet_time = conf->quiet_time; >>> - acx->increase_time = conf->increase_time; >>> - acx->window_size = conf->window_size; >>> + acx->recover_time = cpu_to_le32(conf->recover_time); >>> + acx->hangover_period = conf->hangover_period; >>> + acx->dynamic_mode = conf->dynamic_mode; >>> + acx->early_termination_mode = conf->early_termination_mode; >>> + acx->max_period = conf->max_period; >>> + acx->min_period = conf->min_period; >>> + acx->increase_delta = conf->increase_delta; >>> + acx->decrease_delta = conf->decrease_delta; >>> + acx->quiet_time = conf->quiet_time; >>> + acx->increase_time = conf->increase_time; >>> + acx->window_size = conf->window_size; >> >> I would like to get an ACK from one of the wlcore developers if I should >> apply this (or not). >> > I don't have a strong opinion here. > However, it looks pretty much redundant to take a random blob (which > was just fixed by a correct patch) and re-indent it. > The rest of the file doesn't follow this style, so i don't see a good > reason to apply it here. > > I agree such indentation have some benefit, but it won't help with the > more common use case (of copy-paste error) of copying the wrong field > (i.e. D->a = S->b instead of D->a = S->a). > For these cases the macros suggested by Arend and Johannes will do the > trick. However i usually dislike such macros, as they tend to break > some IDE features (e.g. auto completion). > Maybe we can come up with some nice spatch to catch these cases. What I dislike about those macros is just that they're not as familiar to any C programmer as the assignment operator, so they make the code less readable (even if just a little bit). As for the IDE thing: I try not to use them, but have been told (by colleagues) that Eclipse is reasonably smart about macros in C. I use VIM with the clang_complete plugin and that does do proper completion with expressions containing macros, but not inside macros based on what the macro expansion would be, like the one above. That's why I believe this kind of alignment is at least *an* improvement even if it doesn't solve all possible problems. -- Met vriendelijke groet, With kind regards, Giel van Schijndel -- "Question: what do you call your programming methodology? Answer: Faith based development. You code and then pray that it works." -- John Spelner
Attachment:
signature.asc
Description: Digital signature
