|
On April 11, 2016 at 9:34 PM Mitch Gallman <qtemp@xxxxxxx> wrote:Paul Therrien
1b2b
On Monday, April 11, 2016 5:24 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 4/11/2016 1:59 PM, Edmund Reinhardt wrote:
So far the sense I am getting (from the comments) is that people have the
following requirements
i) When they edit code with numeric indicators they would like to see
- all of the uses of the same indicator whether it is reference by number
or name
So for the following code
dcl-f file workstn indds(myinds);
dcl-ds myinds;
invokeHelp POS(1);
exitNow POS(3);
end-ds;
*in(01)=*off;
exfmt panel;
if (*in01)
showHelp(invokeHelp);
end-if
We could show the following in the indicators section - all pre-defined
indicators sorted alphabetically and all aliases shown on the line that is
referencing it
- Indicators
- 01
3 - invokeHelp
6 - *IN(01)
8 - *IN01
9 - invokeHelp
-03
4 - exitNow
This would be useful to me because I work in very long lived code :-)
Imagine a program written in 1980 or so, with typical left hand
indicators, work fields defined in calcs on the fly; the works. When I
work on one of these, I tend to define a named boolean in place of the
indicators this particular section uses. That is, I don't spend the
hours and days it would take to convert /all/ numbered indicators to
booleans, I only touch the ones I must. So, for example, I might be in
a section of code where I need to do some work:
C 01 DO
C MOVE ODIST ADIST 5
C ADIST SETLL MSTloc
*
C *IN80 DOUEQ *ON
C ADIST READE MSTloc 80
*
C *IN80 IFEQ *OFF
C MOVE LOCNO DISTO 5 0
And here, I want to use a reasonable name for indicator 80, something
like noMoreDistricts. So I create the indicator overlay structure, add
POS(80) and my code becomes free and more readable. But elsewhere, in
other subroutines, the hard indicator number 80 is still used. I'm not
needing to change any of those, so I'll leave them alone.
Time passes, and there's a glitch; something's resetting indicator 80
when it shouldn't. If the Outline View can show me all of the places
where that happens - numbered or named - then that will make my life
that much simpler.
ii) Other people would like to consider all declarations as 1 easily
searchable list, sorted by occurrence in the source (merge together data
structures, fields, constants, indicators, maybe even files)
I'm OK with this, because... well, because I don't understand why there
are Outline View sections in the first place. </red face> I never
browse the Outline View looking for something, and then from there click
to go to the editor. It's /always/ the other way round: I'm looking at
something in the editor and wonder where else this bit is twiddled.
What I'd like to see is a 'Link to Editor' in the Outline View similar
to the one in the Remote Systems View. So I can click on
noMoreDistricts and the Outline View will show me all the places
indicator 80 is used.
What I am understanding is that pre-defined indicators merit a different
section because they are provided by the compiler and can be aliased in
these ways (and are really hard to find lexically)
If I had access to the compiler's tokeniser, this is the very first
thing I'd be extracting from it. Left hand indicators are an
unfortunate part of my life; I could easily filter on 80 as a 'name' but
for one thing: the filter is really naïve. It finds 'entries' with a
line number of 280, it finds arrays which are DIM(80), it finds field
names with 80 anywhere in them like MSG80.
So... today, a separate section for indicators is sort of necessary
because there's no simple way to either search for them, nor filter them
- even in the Outline View.
Do people really want a lot of different preferences that they may never
discover and then have to figure out whether they are useful and might only
be there because of the historical evolution of the product? (Just doesn't
feel clean and easy to learn).
Well, as a novice-ish Excel user, I can tell you that mostly, I don't
look at, or try to figure out Excel's many preferences. Word, The Gimp,
and even Firefox all have many preferences that I never bother with and
I don't feel my learning is inhibited because of that. On the contrary;
I think that preferences are something the power user is interested in
and really wants to have in order to be... well, empowered.
It would be nice if we had options that helped people accomplish
certain tasks easier, so they measurably improve productivity.
For me, productivity is the ability to think without the editor loading
down my cognitive processes. Preferences are a one-time cognitive load.
Keyboard shortcuts are an 'every minute' load until they become muscle
memory, which is why so many programmers avoid using them.
Another thing I am wondering, is there a use for an I Specs and O Specs
entry in the outline view to take people to those sections of the code?
findText oqsy generally works for me :-) Although findText columns 6 6
O will work if I need to find program described file output, blech.
--
--buck
Visit wiki.midrange.com and register for an account. Edit a page that
helps you, and because it's public, you'll help someone else, too!
--
This is the Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
--
This is the Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
