Re Climbing:
A similar problem occurs under 2000sp4. The second problem is actually also an fc incompatibility problem. When it displays by line
number, there are 8 byte positions before each line of text, rather than the 9 under dos6 and win9x, so solving it is also
very simple: change e 100 'set file=' in the debug script to e 100 'set fil='.
However, this is just dealing with the matter as it stands. The three batch files mentioned above were only experimental prototypes I used for practice
under dos6.22, and they were made very roughly. Since I officially switched to win98 in March this year, I encountered many
new problems in use, such as the problem of filenames containing spaces, the problem of system/hidden attribute directories; when used under nt,
I also encountered the problem of Chinese filenames; moreover, because too much text stream control was used in the loop body, it led to
seriously low efficiency; in addition, the three programs do not differ much in function or implementation, so there is no need to split them up.
For all the reasons above, rewriting the above code became necessary. Merging the code, making up for loopholes, improving performance, and writing
documentation produced the so-called V2 edition; actually, not much effort was spent in the process.
However, one accidental afternoon, on a sudden whim, I thought, why not enhance visit's command-line functions a bit,
such as supporting multiple paths, multiple filters, and multiple file lists. At first I thought it would only require adding a command-line parameter
analysis loop, but when I actually implemented it, I once again experienced the complexity of the command line: redirection output conflicts when if for are nested,
the difference between root directories and subdirectories when determining directories, for's low-grade substitution of filters (win9x/dos), and
one new problem after another came crowding in endlessly. It actually took me a good half a workday before I barely implemented
a rough version. This is the so-called V2CE edition. I do not have much confidence in strict testing.
Now, looking back at my work, that V2CE edition actually does not have much application value. Multiple
paths and filters can be completely implemented by calling visit multiple times, and in fact, in most cases we only
use one path and one filter; moreover, multi-parameter control brings a decline in ease of use. Users always have a certain psychological barrier toward
programs with many parameters. My personal preference for DOS compression software, from high to low, is rar,zip,arj,
and ease of use is the first consideration; in addition, most importantly, multi-parameter control caused a large increase in code size
and complexity. This program once made me burrow into a ghostly maze built from if for and lose all sense of direction. The readability of the program became
worse and worse, and debugging became more and more difficult, while compatibility pulled in even more tripwires.
These are the price paid for feature enhancement. Although this is only a relatively extreme example, the importance of the balance between function and
simplicity in program design is obvious from this. An interface with affinity does not mean code with affinity,
and user-friendly requirements do not mean user-friendly implementation. Blindly shifting the complexity on the user's side to the designer (for example
Windows) is not a very smart idea, and the reverse is also true (for example Linux). This is not even considering the dual pressure on both the designer and the user caused by
code feature enhancement.
“complex makes simple”, indeed!
[ Last edited by willsort on 2005-8-14 at 22:53 ]
※ Batchinger 致 Bat Fans：请访问
批处理编程的异类 ，欢迎交流与共享批处理编程心得！
DigestI
irMake