Name of variables: an issue - Printable Version +- QB64 Phoenix Edition (https://staging.qb64phoenix.com) +-- Forum: Official Links (https://staging.qb64phoenix.com/forumdisplay.php?fid=16) +--- Forum: QB64 Phoenix Edition Wiki and Repo (https://staging.qb64phoenix.com/forumdisplay.php?fid=41) +---- Forum: Repo Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=42) +---- Thread: Name of variables: an issue (/showthread.php?tid=830) Pages:
1
2
|
RE: Name of variables: an issue - SpriggsySpriggs - 09-26-2022 There's really more of an issue of overusing temp variables in your programs if you're concerned with multiple variables named "x" or "a". Also, I doubt it would be a common issue to have a variable declared as a UDT also having the same name as another variable declared as a regular type, considering they would serve two entirely different purposes in your code. "Option _Explicit" should help you immensely with your code as it forces you to declare each variable. RE: Name of variables: an issue - Pete - 09-26-2022 I name all my variables Pete or Peter. Pete$ is my favorite. For your xxx condition, I would use Peter&. Pete - There goes our family friendly rating. RE: Name of variables: an issue - Petr - 10-01-2022 The Peter variable should always be of type _Float. I was thinking about how the IDE would probably be structured. I came to the opinion that each variable in the program contains (for the IDE) the index number of an internal field, where this field will contain the name of the variable, its type, the number of the SUB/Function where it is used and the value. Based on this, the C code and EXE file are then generated. It is so? So - for QB64 notation: C = 64 after rewriting from C to QB64 it will look like: Type Variable Value as _Float VName as String VUse as Byte VType as Byte End Type ReDIM InternalVariable(0) as Variable U = Ubound(InternalVariable) InternalVariable(U).Value = C InternalVariable(U).VName = Str$(C) InternalVariable(U).VUse = InternalUse InternalVariable(U).VUse = number for type SINGLE. Where the variable InternalUse will be the number of the internal field of the IDE, which indicates zero for the main stream, or the number according to the order in which the functions and Subs are written (they should be written similarly in the next field) for C. In this way, it would be possible (at the cost of significantly slowing down the IDE) to check if the given variable is already used, even where it is used and what data types it uses in individual uses. But it seems that the QB64 developers have gone a few steps further. It's just pure theory, just an idea when I was thinking about how to write my own IDE... |