This is a setup for future additions..
While mathematically correct, and syntactically correct, logically, the code is wrong. You want:
if ( UCL > Analog && Analog > LCL ) // There are no shortcuts
"Analog" is the variable I am using indicating the Analog Reading I am getting from my Conductivity Sensor (digitalpin 3, and analogpin 0)
As opposed to conductivity, or something more meaningful than Analog?
PaulS:
As opposed to conductivity, or something more meaningful than Analog?
Does it really matter what I name my variables?!?! I am taking a course with other people and this is how they label it!
Does it really matter what I name my variables?!?!
Depends. Do you want code that makes sense today, or forever? If you're happy with code that only makes sense today, then, by all means use generic, meaningless, names.
PaulS:
Depends. Do you want code that makes sense today, or forever? If you're happy with code that only makes sense today, then, by all means use generic, meaningless, names.
You know, I'm taking a class on this stuff only because I have to, to be honest.. So, I appreciate your concern, but I'd like my original question answered.. Not necessarily worried about what my variables are called unless it is related to my problem (which even I know it is not).
@PaulS
His pin which is named "Analog" I assume gives him the analog reading from the Arduino. An Arduino does not read salinity as I assume he would need. Therefore, the function for "Sal" gives him the analog reading in a percent which can be read with more ease. So, paden_sparks "Analog" is a decent name for what you are trying to do. Correct me if my assumptions are wrong paden_sparks, but if they are right, PaulS you are getting worked up and making yourself a fool for arguing something you do not understand.
paden_sparks what I think you should do is refer back to "Morris Dovey" like you just said. This will clear up a lot of the clutter and repeating equations.
dcd012:
"Analog" I assume gives him the analog reading from the Arduino. An Arduino does not read salinity as I assume he would need. Therefore, the function for "Sal" gives him the analog reading in a percent which can be read with more ease. So, paden_sparks "Analog" is a decent name for what you are trying to do.
Is this really your first post?! but, yeah.. thats right!.. maybe noobs just understand other noobs?
thanks
PaulS you are getting worked up and making yourself a fool for arguing something you do not understand.
I do understand that there is not an Analog connected to the pin. I have been making a living writing, and maintaining, and debugging, computer programs for 32 years. I KNOW the difference between maintainable code and code that works. OP has neither.
If one wants to come to the forum and ask for help, one should be prepared to take suggestions seriously. If not, one should not keep asking what is wrong with code that is hard to read, has duplicate variables of the same name, has no functions. is poorly indented, etc.
@PaulS
He came to the forum and asked about his code and you proceeded to make comments on his code that were of no help. You lectured him on the naming of his pins which is makes since to him and anybody who knows the reason behind the name. All of that aside, the fact still remains is that you offered no help just told him to redo what he did with two or three vague ideas as to what he did wrong with no explanation as how to fix it. He is apparently not as "experienced" as you so therefore he is learning and to help someone like that is to teach not overwhelm them with advanced ideas from your vast amount of experiences and endless computer knowledge. If you deem yourself too good to actually offer advice to less experienced person, then you should not post at all. It was a waste of your time, his time, and anybody's time who decided to read it.
In response to Reply#15:
Yes, sometimes it helps to make the intended code structure more clear (to humans) if discrete portions are moved into separate functions. This does not make the code more efficient, but does tend to make authoring, debugging, and maintaining code easier.
Once you have the code working, you can always squeeze out a tiny bit more efficiency by moving "called-once" subfunctions in-line, but my experience has been that there's seldom a need for that tiny improvement - while there's nearly always a need for clarity. 
Awesome! Thanks for the tips!!
dcd012:
@PaulSHe came to the forum and asked about his code and you proceeded to make comments on his code that were of no help.
There's an old saying: Give a man a fish and you feed him today. Teach him to fish and you feed him for the rest of his life.
PaulS is trying to teach you how to fish.
p_sparks:
PaulS:
As opposed to conductivity, or something more meaningful than Analog?Does it really matter what I name my variables?!?! I am taking a course with other people and this is how they label it!
Yes, it matters, since it enables you to avoid the types of mistake that you are making here. There are endless ways of writing code that will produce the right result - some good, some bad. Techniques such as putting your variables in the right scope, choosing meaningful names, abstracting your algorithm and structuring your code so that it is clear, will help you produce good working and maintainable code quicker and more consistently. This is what PaulS is trying to show you. If you are on a programming course and they are not teaching you these techniques, you are missing something important.