[U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Detlev Zundel]

Hi Jagan,

[...]

> I don't think nothing much gone the readability with these updated:
> CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like easy to
> understand. and anyway I have added comments for full name as well.

Comments in a far away place cannot compensate for self-explaining
constructs at the location where they are used.  Stating that a
constants needs comments to explain it is actually a good sign that its
name is not chosen carefully enough.

Really, naming constants and variables for readable and maintainable
code is a much harder problem than it looks (cf. my signature) and
unfortunately not easily measurable.  But I assure you that good names
can make a world of a difference.  That's why Marek and me are so
passionate about this seemingly "trivial" change.

> Few of the flashes can be call this as array fast read and fewer call
> this as fast read and few more call this as high frequency
> read. CMD_RD_FAST will suits all these names.
>
> Comments please!

When we change code, we don't do this for the sake of changing it, but
in order to improve one aspect of it, i.e. the performance, the
maintainability or the features.  When everything "stays the same", we
are even _opposed_ to a change because there is nothing to outweigh the
effort to adjusting to the new things.

To summarize - we need proof that a change _improves_ something.
Showing that we "do not loose something" is clearly not enough.

Now in this specific case, we have multiple people voicing the concern
that the renaming looses vital information, thus effectively making
reading and maintining the code harder.  On the other hand even you
agree that "something" although "not much" will be gone after the
rename.  So taking this into account we have only "saving of a few
keystorkes" on the positive side and substantial degradation on
readability and maintainability on the negative side.

Best wishes
  Detlev

-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de