Re: Formal methods
- Posted by Jerry_Story Jun 12, 2009
- 1243 views
This isn't specific to euphoria, but I'm wondering what techniques people use to design programs. I'm thinking about doing a course in formal methods, because I'm tired of hunting bugs in my programs, and formal techniques seem like a good approach to constructing programs systematically. I know they haven't caught on much except in academia and safety critical code, and for most programs it may be like using a sledgehammer to crack a nut, but maybe once you've learned the methods they wouldn't be so time-consuming or difficult. At the moment I use a "top-down" approach with successive refinement, it works well much of the time, but I still get those annoying bugs which for me take the fun out of programming, although some people seem to enjoy tracking them down. Does anyone use formal methods? what are effective techniques for program design?
I have no formal background in programming and no degrees. I'm only an amateur. But here are a few random points that may be relevant to formal methods.
There is a difference between a large project (100 programmers 5 years) and a small project (1 programmer). This difference is comparable with the difference between constructing a 30 storey building and constructing a dog house. Constructing the large building involves cranes and a bunch of trades and a bunch of professions and much planning and organizing. Constructing the dog house involves only simple tools and simple skills and few materials and can be done by 1 person in only a few minutes to a few hours.
Question: To what extent do "formal methods" apply to one-programmer projects?
My favorite book about programming is 'Code Complete'. Perhaps elementary by the standard of the gurus around here, but I like it.
http://www.cc2e.com/
I picked up a naming system from Visual Basic and tried to apply it to programs based on wxEuphoria etc. Perhaps I have not yet made it consistent. Here are some examples:
btnFave btn indicates a wxButton txt indicates a wxTextCtrl
btnCrap
txtFilter1
txtFilter2
txtFilter3
chkLimit chk indicates a wxCheckBox lbl indicates a wxStaticText (or label)
chkWater
lblSelectedFood
lblSelectedNutrient
lstFoods lst indicates a wxListCtrl box indicates a wxBoxSizer
lstDiet
boxLeft
boxRight
etc.
You can tell at a glance what widget it is by the 3-letter prefix.
The prefix 'color' for colors:
colorProtein = create(wxColour,{255,0,0}),
colorCarb = create(wxColour,{255,255,0}),
colorFat = create(wxColour,{255,255,255}),
colorFiber = create(wxColour,{0,255,0}),
colorAsh = create(wxColour,{0,0,0}),
colorWater = create(wxColour,{75,75,255})
I usually put constants in upper case, variable in lower case.
Naming of files (as opposed to variables and constants) is another subject. In the following examples, the prefix 'fcr' indicates what project the file is part of and removes any possibility of a filename clash.
fcr.exw
fcr-data.e
fcr-game1.e
fcr-game2.e
fcr-game3.e
fcr-general.e
fcr-internet.e
About planning a program. In large projects (100 programmers 5 years), that is called 'specifications' and it's a big deal. In small projects (one-programmer projects), planning (of point and click projects) seems to be:
Assuming you have an idea for a project:
What widgets will it use and what will be their placement? (What will it look like?)
What will happen on each event on each widget? (What will it do?)
When you have answers to these questions, you have a plan. The details probably can be winged.
Planning a large project (100 programmers 5 years) is not so simple; I know next to nothing about that.
This is the end of my lecture. Now I will let one of the gurus get on the soap box.
