2008/11/26 Arjen de Korte <[EMAIL PROTECTED]>: > Citeren Arnaud Quette <[EMAIL PROTECTED]>: > >>> 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 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
