On Mon, Jun 1, 2009 at 5:31 AM, Zach Welch <z...@superlucidity.net> wrote: > On Mon, 2009-06-01 at 05:16 +0200, Michael Bruck wrote: >> On Mon, Jun 1, 2009 at 4:41 AM, David Brownell <davi...@pacbell.net> wrote: >> > On Sunday 31 May 2009, Michael Bruck wrote: >> >> The 'struct foo_s' syntax is code bloat that obscures the actual >> >> algorithms. 'foo_t' is shorter. >> > >> > Disagree about obscuring. And "shorter" doesn't matter here. >> > >> > If I see "foo_t" I have no idea what kind of thing it is. >> > If I see a "struct foo" there's no such confusion. >> > >> > Ergo, "foo_t" has obscured. >> >> Yes, I read that argument on this list before. By this logic most C++ >> code in existence is doomed. > > Doomed to a different style of code, yes. That's not subjective, it is > a simple fact that derives from the very essence of each language.
Sounds quite dramatic. I guess the essence of C is then to put redundant keywords everywhere. Your question was: "How do these changes look in the community's eyes?". My answer was that they obscure the code (in my eyes). As you may have noticed from my absence on the u32 thread I am not really interested in these style debates as they cost too much of my time. I merely commented on this one because I was recently particularly annoyed when editing clusters of impenetrable gibberish like this here: /* This version of jtag_add_dr_scan() uses the check_value/mask fields */ extern void jtag_add_dr_scan_check(int num_fields, scan_field_t* fields, tap_state_t endstate); extern int interface_jtag_add_dr_scan(int num_fields, const scan_field_t* fields, tap_state_t endstate); extern void jtag_add_plain_ir_scan(int num_fields, const scan_field_t* fields, tap_state_t endstate); extern int interface_jtag_add_plain_ir_scan(int num_fields, const scan_field_t* fields, tap_state_t endstate); extern void jtag_add_plain_dr_scan(int num_fields, const scan_field_t* fields, tap_state_t endstate); extern int interface_jtag_add_plain_dr_scan(int num_fields, const scan_field_t* fields, tap_state_t endstate); and I imagined how much worse that that would get once we mix in struct and enum. Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
