Particularly for medium-sized (10,000 ~ 20,000 lines) programs, what
are useful strategies to design them before coding?

My strategies are:


1. Imagine what the final program would look like. Write down
options.

2. Write down many structures, such as

struct s1 {
/* contents */
};

struct s2 {
/* contents */
};

, and so on.

3. Write down many function prototypes, and classify them to different
..h files.


4. Write many macro definitions, such as "#define MAX_SIZE 100"

But having to change the original design during coding really troubles
me. Do you have any suggestions to avoid doing this?

<istillshine@gmail.com> wrote in message
news:45d39ffb-0311-4650-8844-fea0b089f397@u36g2000prf.googlegroups.com...
> Particularly for medium-sized (10,000 ~ 20,000 lines) programs, what
> are useful strategies to design them before coding?
>
> My strategies are:

> 1. Imagine what the final program would look like. Write down
> options.
>
> 2. Write down many structures, such as
>
> struct s1 {
> /* contents */
> };
>
....
> 3. Write down many function prototypes, and classify them to different
> .h files.
>
>
> 4. Write many macro definitions, such as "#define MAX_SIZE 100"
>
> But having to change the original design during coding really troubles
> me. Do you have any suggestions to avoid doing this?

This is all stuff you learn as you attempt bigger projects.

Revising/refining projects is quite normal (they get easier 3rd or 4th time
round..).

In my case, as I'm not quite au fait with C, I might write in a more
familiar and less fussy language (especially rapid development) then port
the result to C. Then you don't have to dot the i's and cross the t's on
code which might change a dozen times more.

Other people will suggest some very formal methodologies, but I think an
informal approach can still lead to reasonable quality code.

--
Bart

On Sun, 13 Apr 2008 16:07:21 -0700, istillshine wrote:

> But having to change the original design during coding really troubles
> me.

It shouldn't.

> Do you have any suggestions to avoid doing this?

Don't avoid it. Embrace it. Changes to designs happen, and not just in
software.

istillshine@gmail.com said:

> Particularly for medium-sized (10,000 ~ 20,000 lines) programs,

Er, those are iddy-biddy little programs.

LOC Range Category
0 Vapourware
1-9 IOCCC
10-99 Exercise/Example
100-999 Library update
1000-9999 Utility
10000-99999 Small program
100000-999999 Medium-sized program
1000000-9999999 Large program
10000000+ Very large program

(Source: BSI, 2008 [1])

> what
> are useful strategies to design them before coding?

Identify the requirements. If you know how to implement these requirements,
write down how to do that. Otherwise, break the requirements down into
simpler sub-problems, and recurse. Look for commonalities between various
parts of the problem, and use those to factor out functionality. Look for
aspects of the problem that are general computer problems rather than
aspects of this particular problem, and see whether you have existing
library solutions for those parts. If not, consider creating them this
time round, to make life easier next time round.


> My strategies are:
>
> 1. Imagine what the final program would look like. Write down
> options.
>
> 2. Write down many structures, [...] many function prototypes, [...]
> many macro definitions [...]

I hope I'm wrong, but this almost sounds like you're inventing these things
at random! I would suggest that you think in terms of modules. "I will
need a module for dealing with customers, a module for dealing with
suppliers, a module for managing transactions..." and so on.

> But having to change the original design during coding really troubles
> me. Do you have any suggestions to avoid doing this?

Even if you get the design right (which you probably won't because hardly
anyone does, and this is normally *not* their fault because normally they
haven't been told correctly which problem they're supposed to be solving),
by the time it's finished the requirements will have changed, which
necessarily means a change in design. Welcome to the ever-changing world.

That's why the "Cathedral" design process doesn't work very well - it can't
respond quickly to changing requirements. Write well-modularised code,
usefully solve *one* problem, and release the code, asking for review
comments and telling your users when, roughly, to expect the next release
(tomorrow? day after? next week?) and what problem it intends to solve,
and so on round all the problems. That way, your users become involved
iteratively in your design process, and you can satisfy their needs much
more quickly, effectively, and flexibly.


[1] Those who are wondering whether I mean the British Standards Institute
need wonder no longer. I don't.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:Q9WdnYKJxaY-aZ_VnZ2dnUVZ8vqdnZ2d@bt.com...
> istillshine@gmail.com said:
>
>> Particularly for medium-sized (10,000 ~ 20,000 lines) programs,
>
> Er, those are iddy-biddy little programs.
>
> LOC Range Category
> 0 Vapourware
> 1-9 IOCCC
> 10-99 Exercise/Example
> 100-999 Library update
> 1000-9999 Utility
> 10000-99999 Small program
> 100000-999999 Medium-sized program
> 1000000-9999999 Large program
> 10000000+ Very large program

The figures are more reasonable with Small programs starting at 1000-9999.
There are plenty of useful programs that can be written in 10K lines that
are more than utilities.

The 10M+ figure is better called 'bloatware'.

LOC is a fairly nebulous figure (as discussed in c.l.c last week I think).
But is useful for visualisation (every 15,000 lines is a 1" tall printout,
or divide by 200,000 to get that in feet; 10M lines is a ludicrous 50'
stack).

A lot depends on language and style. And, perhaps, how many of those LOC are
original and not just created by the developement environment.

And I think individuals should have their own scale; they can often create
similar applications to a team effort, with (necessarily) a smaller line
count.

So 10-20K LOC is plenty to qualify as medium-sized for an
individual.

--
Bart

>The figures are more reasonable with Small programs starting at 1000-9999.
>There are plenty of useful programs that can be written in 10K lines that
>are more than utilities.
>
>The 10M+ figure is better called 'bloatware'.

This, I suppose, depends on what it's supposed to do.
If it's the Windows Vista driver for the second mouse button, it's bloatware.
If it's a planetary air traffic control system, it might not be.

>LOC is a fairly nebulous figure (as discussed in c.l.c last week I think).

The ease with which a programmer can greatly magnify LOC (and maybe
billable $$$) using an automated program indicates it's much more
nebulous than that.

>But is useful for visualisation (every 15,000 lines is a 1" tall printout,
>or divide by 200,000 to get that in feet; 10M lines is a ludicrous 50'
>stack).

Yes, and by providing the outside of a 50' stack of paper with the inside
filled with manure, you can make something look complicated when it's not.

>A lot depends on language and style.

Applying LOC to a program alters the style to maximize LOC.

>And, perhaps, how many of those LOC are
>original and not just created by the developement environment.