[Nut-upsdev] [nut-commits] svn commit r1578 - in trunk: . drivers

[Arnaud Quette]

2008/11/26 Arjen de Korte <nut+devel at de-korte.org>:
> Citeren Arnaud Quette <aquette.dev at gmail.com>:
>
>>> The reason why I removed this here, is the fact that over-use of defines
>>> makes code more difficult, instead easier to understand.
>>
>> I strongly disagree there. VENDOR_NAME is always more informative than
>> 0x????
>
> In what way? I fully agree that having a USB_DEVICE macro helps in
> extracting the VID:PID information (and makes clear these are used
> together), but a VENDOR_NAME define is adding nothing at all here. People
> wishing to add additional supported devices are helped more by a listing of
> existing VID:PID combinations to see if theirs is already supported, than by
> an arbitrary define chosen by a developer VENDOR_NAME (which is not related
> to anything reported by tools to get to the VID:PID combination). In fact,
> since it is a developer who chose this name, there is no hope of ever
> matching it to VID's found in the field.

you got me wrong: the VENDOR_NAME example was not good there, and led
to confusion.
I simply meant that, apart from the current USB info extraction,
defines tends to make code more readable
(ex: isn't "SUPPORTED" more clear than "2"?!)

> Overuse of defines is a pet-peeve of me. With all the good intentions that
> may be behind these, if you use a define only once in your code, chances are
> that it would have been clearer not to use it. For instance in the SNMP
> MIBs, the use of defines means that if I'm looking for a certain OID I found
> in a manual, I need two steps to get to the NUT variable that uses it. One
> to get the from the OID to the define and a second one to get to the NUT
> variable that uses it. Not using defines here, would have led me straight to
> the NUT variable, so this is just complicating matters. The problem here is
> that these names are made up by humans, so there is no direct reference to
> something found in a reference manual anymore. So in case of the MIBs, I'd
> rather lose the defines.

we're ok on that one. I've made myself exactly the same remark on
snmp-ups and OIDs definition when working on PDU preliminary support.
Gotta fix that. Right about the counter productivity induced there,
but I still think that defines are otherwise useful (possibly with
enums)

now, let's postpone this kind of discussion to a later time, if
possible in front of a beer, and get back to what matters... code and
2.4 ;-)

btw, still interested in work on sub devices? that would help a lot...

cheers,
-- Arnaud