Tweet
** This thread discusses the article: TechTip: Overloading Indicators **
** This thread discusses the Content article: TechTip: Overloading Indicators **
0
** This thread discusses the Content article: TechTip: Overloading Indicators **
0
-
-
TechTip: Overloading Indicators
** This thread discusses the article: TechTip: Overloading Indicators **
Reducing the number of variables, in this case, indicator variables, in a program is not necessarily a benefit in itself. Reducing the number of variables can make a program more readable, but this is not true in every case. I don't refer to numeric indicators in my programs, I prefer to use named boolean variables that map to indicators in the display file because it makes the program easier to understand. In your example, the boolean variable actually serves 2 purposes, so naming these variables so that it is clear what their purpose is becomes more of a challenge. I think trying to get as much functionality as possible out of each variable as you are doing in your examples does not improve program readability and one could make the argument it reduces readability to some degree. Jim Suiter -
TechTip: Overloading Indicators
** This thread discusses the article: TechTip: Overloading Indicators **
I believe that indicators have been given a bad rap. Indicators are easy to use. I do not see the value in re-using the same indicator for different functions. In my subfile programs, I always use 40 to clear and 41 to display the control and 42 to display the detail (if there is any--a lot of my programs will not have detail). By adhering to this standard, my programs are easy to follow and easy to change. I do not turn on an idicator or fill a field because of a situation (unless it is to display a screen atribute) in my programs. I use the actual situation to cause code to be executed. Indicators are our friends. Yes, indicators can be over-used; but so can anything else.Comment
Comment