Jinx,

 You have some good arguments.  As far as 'EQU' and 'DEFINES' are
 concerned, I use them all the time.  I wouldn't write a program
 unless I did.  Unless it was very small, but then again?

 But concerning 'MACROS', I just haven't found them to help me in
 any constructive way.  So therefore, I just don't use them.

 As far as you using them, I have no problem with that.  If they help
 you out, then so be it.  But they just aren't for me.  And in case
 you're wondering, yes I have tried them many times, but to me they
 seem to be more bother than they're worth.

 I have written many program for PICs where I work.  Some as far
 back as 6 yesra ago. And there have been a few different people
 that need to maintain the code, but I have yet to have someone come
 to me and ask what the code does or how is it supposed to work.
 Because I document well throughout the code, and write in a straight
 forward way without using macros, I have achieved code that is readable,
 maintainable, and performs as it was designed to do, and everyone is happy.

 But I take your points seriously.   Maybe I'll try macros again, just
 to see if my writing style or attitudes have changed.   I'll keep you
 posted either way.

 TTYL,

                                             Thanks and Regards,

                                                    Jim


>>  I didn't say it was better.  But it is explicit.  And as far as
>> 'BANKSEL'  is concerned, I assumed it was a macro.  I
>> personally don't bother with macros.  To me, they tend to
>> complicate things.   If you want to use them and like them,
>> I have no problem with that.  I just like to write my code so
>> it is easy to follow.  To me, the best way to that end is to not use
>> macros, and write everything in a straight forward manner
>
> IMHO you would be in a small minority, and I strongly disagree.
> There's absolutely no reason why code written in any style can't
> be straight forward, but IMHO, again, there's a minimum standard.
> For one thing it makes code easier for other people to read and,
> just as importantly, for the author in a year's time. By using macros,
> defines and equs you are adding one more level of documentation
> and that is never a bad thing (because the name is a descriptor),
> apart from the fact that it saves one hell of a lot of typing, and
> macro usage eliminates many typos being complied. A macro can be as
>simple as putting an instruction into plain English, doesn't have to be
>complicated (or bloatware) at all
>
> The code posted in the last couple of days for accessing F877
> EEPROM is a perfect example of how using macros and register
> names improves readability (not having a dig at you Mr Gois,
> honest). I find it extremely fatiguing and tedious debugging code
> that's peppered with, for example, lines like BSF STATUS,RP0
> or MOVWF 0x05. Imagine mistyping RP1 or 0x15. How many
> hours would it take to find ? Hours that could have been spent
> doing something constructive and not getting all pissed off and
> frustrated. I really don't see how macros complicate things, I
> really don't. Obviously YMdoesV
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics