jan-erik, Maybe. But just because it isn't what you like to do, or more precisely, because it isn't the generally accepted form of programming doesn't make it wrong. Also, it may not be the most elegant or efficient, but it still isn't wrong. You give 5 different people a problem to solve with programming, and you'll come up with 5 different programs that all do the same thing. Some of each of the programs may have routines nearly identical to someone elses program, but they will not be exactly alike. Why, because each individual has his or her preferences or choices of how to do something. As long as a program does what it is intended to do, and if it satisfies the specification, if there is one, then it is okay. With all of that said, there is something to be said about the generally accepted form of programming. One point is that if all programmers follow a generally accepted form, then a person that wrote a particular program could go to a different program and be able to follow the other program with less difficulty. Another is that the generally accepted form may be more efficient than a given person personal preference or style. (This is the point that most applies in my case). However, just because someone chooses to do something in a way other than the generally accepted form doesn't make it wrong or doesn't mean the program is less useful. It just means it was done differently, and in a way that deviates from the generally accepted form. Which brings us back to your comment of "it should, not could" If I am being gauged by the defacto standard or the generally accepted form, then you are correct.=20 However, if I am being gauged on the functionality and performance of a program I write to see if it satisfies a specification given, then I too am right. So, it all boils down to my preference. That being do I want to follow the general form, or my own form for whatever reason. I have chosen the latter. Why,? Because it is easier for me to make sure things are doing what I think they should be doing by doing it my way. Am I saying my way is better? No. Not necessarily better, just different. Am I trying to get anyone else to use my form? No. It is my form. I like using my form to troubleshoot problems. But that doesn't mean anyone else has to use it. If they want to they can, but they don't have to. Would you hire me to work on a project knowing that I use a programming style that you may not like or approve of? Probably not. But that's okay too as I am not looking for collaborative projects. I get several programming requests a year from several different sources.=20 Some I take. Some I turn down. But in all that I take, the requestor is asking for a working program.=20 Most are relatively simple. Some are complex. But when I deliver a work product, I have excellent documentation to explain my work, and I comment my source code liberally to explain the flow and function of a program. So the fact that I don't necessarily follow the established and accepted form doesn't matter to my customer. They are seeking my expertise and experience in programming a microcontroller to solve their problem at the time. A long as I do that, they are satisfied. Anyway, my point is that my original comment that it "Could be done that way, but doesn't have to be" is correct. If that violates some defacto rule, then I guess it violates some defacto rule. But if it works, then it make very little difference. If someone hires me to write a program and they specifically ask me to use standard practices, then I will try to abide by that condition.=20 But generally, it doesn't matter that much if I don't follow the standard practices. Regards, Jim > -------- Original Message -------- > Subject: Re: [FWD: [PIC]: PIC16F1827 PORTB Problem.] *** RESEND *** > From: Jan-Erik Soderholm > Date: Tue, June 21, 2011 11:54 am > To: "Microcontroller discussion list - Public." > > > jim@jpes.com wrote 2011-06-21 15:45: > > > > jan-erik, > > > > The code could be written the way you show, but it doesn't have to be= .. > > > > Not could, should. There is absolutely no reason at all to > write it as you did. Yes, maybe it does "work", but... :-) > > > I agree that normally you should use symbols for addresses, but in th= is > > case, I chose addresses because I was troubleshooting a problem. > > The wrong way to troubleshoot. If you really have to verify an > address, check the processor INC file or the list/map files. > Using hardcoded addresses actually makes the troubleshooting *harder*. > > And yes, I know that it was all solved before I posted... :-) > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .