Anyone else mess with life in miniature, when working on bigger projects?

[Pete]

I used to do this with things when I was a kid, build a small scale model, and then make something much larger. Now, maybe because I'm getting older, I find myself doing the exact same thing with programming. So this is a little demo of that. My find routine was separate from my WP, but now I need to make it scroll the screen to display the first find. So instead of working that into the 2000 line find and display routine, or the 5000 line WP routine, I built a small model of what I want it to do.

Anyone else here use this approach, or a similar approach, rather than trying to map ever detail out on paper, first, when working with a large project?

Code: QB64: [Select]

1. COLOR 0, 7: CLS
2. REDIM x$(20)
3. margin.t = 5
4. margin.l = 4
5. dwidth = 72
6. page.h = 6
7. row = 1
8. noe = 13
9.  
10. x$(1) = " 01 We the People of the United States, in Order to form a more perfect " + CHR$(10)
11. x$(2) = " 02 Union, establish Justice, insure domestic Tranquility, provide for " + CHR$(10)
12. x$(3) = " 03 the common defence, promote the general Welfare, and secure the " + CHR$(10)
13. x$(4) = " 04 Blessings of Liberty to ourselves and our Posterity, do ordain and " + CHR$(10)
14. x$(5) = " 05 establish this Constitution for the United States of America." + CHR$(10)
15. x$(6) = " 06 " + CHR$(255) + CHR$(10)
16. x$(7) = " 07 Article I" + CHR$(10)
17. x$(8) = " 08 " + CHR$(255) + CHR$(10)
18. x$(9) = " 09 Section 1: Congress" + CHR$(10)
19. x$(10) = " 10 " + CHR$(255) + CHR$(10)
20. x$(11) = " 11 All legislative Powers herein granted shall be vested in a Congress " + CHR$(10)
21. x$(12) = " 12 of the United States, which shall consist of a Senate and House of " + CHR$(10)
22. x$(13) = " 13 Representatives." + CHR$(10)
23. DO
24.     INPUT "Input the line number where a word you want found appears 1-13: "; first_find%
25.     IF first_find% > noe THEN BEEP ELSE EXIT DO
26. LOOP
27. COLOR 15, 1
28. GOSUB displaydoc
29. COLOR 0, 7
30. LOCATE 1, 1: PRINT "scr ="; scr, "first_find% ="; first_find%, "first_find_row% ="; first_find_row%
31. SLEEP
32. COLOR 0, 7: CLS
33. RUN
34.  
35. displaydoc:
36. ' Calculate page find.
37. ' first_find% is the entry number with the first find.
38. ' Put the first find in the second row, but only if the page can be filled.
39. ' If the page cannot be filled. Put the first find in the upper-most row possible.
40.  
41. IF noe - first_find% >= page.h THEN ' Plenty of page space remaining.
42.     IF first_find% = 1 THEN
43.         first_find_row% = 1
44.     ELSE
45.         first_find_row% = 2 ' Place first find on second row.
46.         scr = first_find% - 2
47.     END IF
48. ELSE ' Manipulate text to bottom of page.
49.     scr = noe - page.h ' Page will display to bottom.
50.     IF scr < 0 THEN
51.         scr = 0 ' Less than a page of text.
52.     END IF
53.     first_find_row% = first_find% - scr
54. END IF
55.  
56. FOR i% = 1 TO page.h
57.     a1$ = SPACE$(dwidth)
58.     MID$(a1$, 1) = MID$(x$(i% + scr), 1, INSTR(x$(i% + scr), CHR$(10)) - 1)
59.     LOCATE margin.t + i%, margin.l + 1
60.     PRINT a1$
61. NEXT
62. RETURN
63.  

So ideally I have the line with the word to be found in the second row. If it is in the first line, however, it appears in the first row. If the length of the text is less than the view port, or the find is near the end of the text, it accommodates to the page height and displays the line on the appropriate row, rather than row #2.

Another nice thing about this approach, is the ideas that come from it. For instance, that first_find% variable would be better served as an array, renamed, and the first instance would be used in this routine, and all the others would be used for a step-through find function. 

Pete

[FellippeHeitor]

I too tend to separate the parts when something starts becoming complex. Planning on paper is not a thing for me, but planning code by coding is definitely a thing.

[SMcNeill]

I tend to code in a modular approach, so when I need to do something, I tend to build/test my SUB/FUNCTIONs in a sandbox environment first.  Then, once it works, I import that part into my main program. 

[Pete]

@ Fell Well, nice to know a professional shares this method. If I had to plan it out on paper first, instead of just coding, I'd rather go buy a gun and shoot myself... Oh, and I wouldn't bother drawing a map to the gun store, either.  When I was in college, we traveled to a convention in Boston. I had some free time, and with no map, picked a direction, and started walking. I wanted to see the U.S.S. Constitution. No, not the U.S. Constitution, partly printed above, the ship. Anyway, I walked in one direction, for a little over an hour, and walked right up to the dock! It was closed!!! I went aboard, anyway. Cheap chain across two poles wasn't going to keep me out; however, what I didn't know, but found out after being on board for 5-minutes, was there was also a security guard. Nice guy, too. He ended up giving me a tour of the ship. I didn't even have to go all Clark Griswald on him, either. - True story.

Pete

[bplus]

I remember planning something on paper once, spent about a week. Within the hour of applying it had it bashed to bits!

[Pete]

@SMcNeill

You do what I started to do when I switched for a TI44A to an Atari. I liked making games back then, like Wheel of Fortune, Password, Card Sharks (It's actually Sharps, but I think the game show was spelled the former.) Oh, and Monopoly. I actually got one of those working on the 4K T.I. Anyway, I was more interested in productivity back then, so I started modularizing the parts that could be used from game to game. That all went to hell in a hand-basket, went I got QBasic to make my office programs. Productivity became slapping together working code, as fast as possible, to implement it for practical purposes.

I'd like to get back to the module building. I'd have to bite the bullet, and do some planning to do so. I did build the text scrolling, highlighting, and word wrap as three separate modules, but I still had considerable work merging them together. One difficulty is I've been moving from all global variables, to passed variables. That UBOUND thing, I came across, wouldn't have stung me if I had done things the way I used to and used global variables. Also, I'm starting to work with UDTs, to cut down of so many variables passed on a sub call line. What I need to ask myself is how many more like projects would I be interested in coding? A lot of the changes to my programming style, I've made for sake of aging. One, to simplify things, and two, to try new things like UDTs, to keep a sharper mind. In the old days, I could juggle 8,000 lines of code, but now 5000 appears to be a struggle. I don't want to see that diminish, anytime soon.

Pete

[Pete]

I remember planning something on paper once, spent about a week. Within the hour of applying it had it bashed to bits!

Bashed as in it didn't work, or you came up with different ideas, while you were trying to code it, or both? Those would be my concerns about project planning, too.

Pete

[STxAxTIC]

Sometimes I have to spend several hours or days on paper before one day on the program. This process is well-known, coined by Richard Feynman:

1) Write down the problem.
2) Think very hard.
3) Write down the answer.

There is another method though. This one comes from Socrates originally, but in today's terms on today's tools, it looks like:

1) Ready - prepare to power-type, a mythical activity programmers think they do
2) Fire    - press F5 no matter what
3) Aim    - back to step 1, but with changed confidence, for better or for worse

I'll bet both methods are familiar to everyone. If I asked you to print text on screen "centered" at 23% from the left, you might use a mixture of both.

All I really know is this:

Programs tend to grow like living beings. Have you ever saved a copy of a project in a different file for every edit you made, and then watch those files in fast motion like a flipbook? The process is amazing - parts of the program duplicate, become variant of each other, and then merge to be more general and robust. Some chunks are deleted outright. "I guess this air creature didn't need gills for swimming." Etc etc.

Did you guys know that you *had* to provide a correctness proof with your code on some older machines? The attitude was: "We don't want just your program, but also a mathematical proof that it's not wasting the machine's time." Talk about planning.

[Pete]

ROFL @ ...not wasting the machine's time.

Yeah, my CPU &^&$%$* hates me!!!!

Thanks Bill,

Pete :D

[OldMoses]

If I have a geometry/trig/vector problem, I sometimes will try to prove things on paper first to get my head wrapped around the issue. Otherwise, I tend to fling poo at the keyboard until something works. Then I use the paper to clean up the keyboard, but it still smells a bit funky.