The cosmetic cleanups should IMO just merge.
On Tuesday 19 May 2009, Michael Bruck wrote:
> patch 01 is a rather large one that renames the function arguments
> 'num_fields' and 'fields' into 'in_num_fields' and 'in_fields'
> The rationale here is that almost all of these functions take some
> input fields and produce from that a new set of output fields. The
> patch sets the stage to later be able to use a local variable 'field'
> or 'fields' to refer to fields rather then the current endless
> repetitions of cmd->cmd.scan->fields[...] while at the same time
> making it clear which one is the input argument and which is the
> output data.
Seems like it can hardly break anything, yes? That does seem
to be useful clarity.
> patch 02 renames a local variable 'x' into 'num_taps' to describe what it
> means
Except I don't like seeing declaration blocks split into
sections with whitespace:
> {
> jtag_tap_t *tap;
> - int x;
> int nth_tap;
> int scan_size = 0;
>
> + int num_taps = jtag_NumEnabledTaps();
Just put the "int num_taps..." up where "int x" was.
> +
> /* allocate memory for a new list member */
> jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t));
Or what you did in a few other places, "type * ptrvar" should
be just "type *ptrvar"; those are IMO neither simplifications
nor cleanups. Ditto using the (IMO annoying) C99 feature where
declarations don't necessarily live at the beginning of a block.
> Again none of these patches change any algorithm.
Making them all coding style fixes, not simplifications.
And at one point some new comments.
I liked #5 (other than the "type * ptrvar" issue), that does
make the code more clear: p->q->r ==> q->r is mostly better.
I'd kind of like to see a standard "indent" ruleset agreed on,
so that at least the things that tool handles well could be
somewhat automated.
(By the way, suggestion: only one patch per mail. It's painful
enough to try reviewing attachments, especially text/plain ones
that won't get the syntax highlighting that diffs do.)
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
