Debugging Tricks : Going Blank
in [Visual Basic]
|
Prev: Redirection
Next: Correct Way To Wait
From: Nobody on 9 Mar 2010 19:26 Off topic: These might be of interest: http://en.wikipedia.org/wiki/List_of_software_development_philosophies http://en.wikipedia.org/wiki/Unit_testing I found that code-as-you-go is not a good idea unless one does unit testing. Before incorporating a routine into a program, one needs to test it alone with sample data. In some cases with arrays or buffer manipulation or sorting for instance, the routine may not be doing what's it supposed to do in certain cases. It's common to not process the first or last element, or if there are only one or two elements in the array or buffer. This saved me a lot of time in introducing bugs into a larger program which would be hard to track later. Even though I have been using VB for 15+ years, I could make mistakes like that. In some cases I found that testing with 3 elements for example works fine, and many developers would be happy with that, including me, but I found issues mostly with the first or last element, so thorough testing of routines is essential if one wants to save debugging time later. In some cases you mentally approve of certain routines, so you don't question them, so if you are looking for a source of a bug, you don't find it, or it takes you longer to find it because your limited testing of the routine wasn't enough to detect all the bugs in the routine. Using flowcharts and careful designing is obviously better, but takes time, but it's worth it. Problems can be found at the design stage so there is no need to do find bug-fix-test-repeat. If there are N bugs, then you have to do this fix and test cycle N times, and the software takes longer to finish. With careful designing, this can be eliminated or reduced significantly.
From: Webbiz on 9 Mar 2010 20:14 On Tue, 9 Mar 2010 15:02:30 -0500, "Nobody" <nobody(a)nobody.com> wrote: >"Webbiz" <nospam(a)noway.com> wrote in message >news:ie9dp5ds1rc9viu084q77vibjt1b41hkg6(a)4ax.com... >> I don't suppose you know of a program (preferrably freeware) that >> allows you to enter (brainstorm) your application thoughts in order to >> generate some sort of procedural plan for app development? > >There is MS Visio, which is usually part of Visual Studio 2002+, and >sometimes Office. It's not free. It was developed by another company and MS >acquired it. > >http://en.wikipedia.org/wiki/Visio > > >> In the old days (very old days), I used to draw Flowcharts with all >> its decision diamonds and branches, etc. This was before the Event >> driven way of programming became norm. >> >> So what do professional programmers use these days to put their ideas >> into an actual development roadmap/plan? > >UML and flowcharts: > >http://en.wikipedia.org/wiki/Unified_Modeling_Language > > UML...hmmm. The study material never ceases to pile up. Thanks. Webbiz
From: Nobody on 9 Mar 2010 20:16 "ralph" <nt_consulting64(a)yahoo.net> wrote in message news:96ndp5546ejmhcoccqbtkifl1tq9sng1pv(a)4ax.com... > It used to be available as a free-download. > [http://msdn.microsoft.com/en-us/vbrun/ee410535.aspx] ??? It's still freely downloadable from the link you provided.
From: Webbiz on 9 Mar 2010 20:20 On Tue, 09 Mar 2010 18:09:56 -0600, ralph <nt_consulting64(a)yahoo.net> wrote: >On Tue, 09 Mar 2010 13:52:54 -0600, Webbiz <nospam(a)noway.com> wrote: > > >> >>I don't suppose you know of a program (preferrably freeware) that >>allows you to enter (brainstorm) your application thoughts in order to >>generate some sort of procedural plan for app development? >> >>In the old days (very old days), I used to draw Flowcharts with all >>its decision diamonds and branches, etc. This was before the Event >>driven way of programming became norm. >> >>So what do professional programmers use these days to put their ideas >>into an actual development roadmap/plan? >> > >If you are using VS or VB 5/6 Enterprise editions, you already have >one. It is called 'Microsoft Visual Modeler'. It works as an Addon. > >It allows you to use a Class Diagram (UML) graphical object modeling >designer to describe your application. You can then generate code from >your model. > >The tool also will 'Reverse Engineer' an existing application to >create a model. From there you can use 'Round-trip Engineering' to >expand your application and model side-by-side. > >The tool itself was developed and licensed from Rational (a limited >utility addon for its then Rational 2000 product). Microsoft included >the product to compete with Borland wrapping similar features in its >products at the time. A tad quirky at times it works surprisingly >well. You don't have to know all that much about UML or OOD/A going in >(though it helps) as it it pretty straightforward. In fact it makes a >good UML trainer. > >It used to be available as a free-download. >[http://msdn.microsoft.com/en-us/vbrun/ee410535.aspx] ??? > >-ralph Hey, thanks a bunch Ralph. Webbiz
From: ralph on 10 Mar 2010 01:43
On Tue, 09 Mar 2010 19:20:29 -0600, Webbiz <nospam(a)noway.com> wrote: >> >>It used to be available as a free-download. >>[http://msdn.microsoft.com/en-us/vbrun/ee410535.aspx] ??? >> >>-ralph > > >Hey, thanks a bunch Ralph. > >Webbiz Nobody reported it is still available which is great. Most of my microsoft links have been blown away of late. (Modeler is probably still around because it also works with VC++. <g>) A heads-up if you decide to check it out. The main problem you will run into (which is the same you will find with any tool even the $32k per seat products) is the designer instruments the code with identifiers and markers, and if given enough time and enough abuse Visual Modeler can get confused. When it does, don't panic, treat it the same as when a plain VB Project gets 'confused'. Close any open files, then close the project down. Re-open and back-track - run the modeler on small parts, etc. ie, most problems are self-repairing. After awhile, with enough practice, you'll be able to load the offending files in a text editor and make repairs manually. To avoid confusion in the first place do frequent full compiles and keep the total number of open files to a mininum. You don't have to go crazy, just close any source files you are aren't using or plan to use any time soon. While VB does incrimental compiles as files lose focus in the editor, actually closing them helps. -ralph |