At here(1) we can see, bitResolution is into a function. Then the variable will be destroy at the end of the function. But will it have a conflict with this?
at here(2) we can see, it's a parameter and the value is used at line 448.
Same question, will it have a conflict with this?
Would it be not better to name the private bitResolution as the following _bitResolution to dissociate this, for example?
In (1) bitResolution is a local variable, within a function, which is fine. It is only for temporary use within the function, and there is no conflict.
In really comes down to variable scope. The variable has different scope depending on where you are in the program. There is not a conflict as such, but within a subroutine where the variable is redefined then the scope is not the same (and therefore the variable is not the same) as higher up in the program.
It's probably not a great idea to have a bunch of variables with the same name, as it can indeed be confusing for someone trying to understand which instance of a variable that are actually referring to at a given point.
In this simple example x is defined 3 times... but each of them has different scope.
int x = 10;
void setup()
{
Serial.begin(115200);
Serial.print("In setup 1 x = ");
Serial.println(x);
calculate(15);
Serial.print("In setup 2 x = ");
Serial.println(x);
}
void loop ()
{
}
void calculate(int x)
{
Serial.print("In calculate x = ");
Serial.println(x);
for (int x = 1; x < 5; x++)
{
Serial.print("In for loop x = ");
Serial.println(x);
}
}
12:39:34.869 -> In setup 1 x = 10
12:39:34.869 -> In calculate x = 15
12:39:34.869 -> In for loop x = 1
12:39:34.902 -> In for loop x = 2
12:39:34.902 -> In for loop x = 3
12:39:34.902 -> In for loop x = 4
12:39:34.902 -> In setup 2 x = 10
int iam_global = 10; // Global variable
void setup()
{
Serial.begin(115200);
Serial.print("It's a global = ");
Serial.println(iam_global ); //print 10
calculate(iam_global -2); // 8
Serial.print("I am global = ");
Serial.println(iam_global); // print10
cal(2);
}
void loop ()
{
}
void calculate(int iam_global )
{
Serial.print("I am local = ");
Serial.println(iam_global );
for (int iam_global = 1; iam_global < 5; iam_global ++) // Here iam_global IS NOT global but local
{
Serial.print("In for loop = ");
Serial.println(iam_global ); // print 1,2,3,4
}
}
void cal(int y)
{
Serial.print("I am local = ");
Serial.println(y);
int z-is-local =1;
Serial.println(z-is-local + iam_global + y); // Print 13
int iam_global=2; // I am not global
Serial.println(z-is-local + iam_global + y); // Print 14
Serial.println(iam_global); // DOES IT PRINT 2 OR 10???? I beleive 2 but why not 10
}
(I think it's not really a good way to code. I am used to give alwas a different name to a variable.)
Yes, I am fully agree with that! but it's problem I see with Arduino-Temperature-Control-Library and I am "rewriting" it and I would like to correct the naming
As the Library codes absolutely belong to those who made it, there is no need for the users to give them literate form. The users are supposed to know/understand the rules of passing/accepting parameters to/from the methods.
1. If I am writing/presenting codes for which I have readers, then I must present them in literate form. When I say "literate form" -- I mean the following Style-1 and not the Style-2 though both are functionally correct. Style-1:
2. Looking into the *.h and *.cpp files of a Library are the jobs of learned academicians and expert programmers and researchers. I don't feel comfort to see a general user digging into those files and manipulate its contents (renaming variables without understanding variable's scope) in order to ornamenting the file with so called "literacy".
3. Talking about painting the back of the drawer -- it is a taste for beauty.
Most Arduino libraries are under FLOSS licenses so saying they "absolutely belong to those who made it" is a bit of a stretch.
Anyway, I regularly end up looking into the code of libraries I use, e.g. when analyzing bugs / weird behavior. Documentation is often insufficient to really understand the assumptions that are built into a library's public interface. In the case of Arduino, reading a library's code may be necessary to figure out why the library fails on certain boards, along with other cases.
(I also hate working with closed-source libraries because troubleshooting things related to them can be a horrible mess.)
Due to this, I firmly believe that a library that is badly written is simply a bad library.
(Of course, code style is subjective and I disagree with the notion that "shadowing" variables is always bad. There are cases where I believe it makes code more readable, e.g. in the context of getters/setters, or constructors.)
