Flow Chart
So Rich and I were testing out a new flow chart to help us program. For some reason I don't think its helping. Maybe someone can help us out I think we are using the program properly
Signed,
-Ab
-Ab
Re: Flow Chart
time to post flow chart for review, 35sec....
lost time for dristin coding 35sec...
Time added to release of dristin Beta in 2015...
Yup....35sec
lost time for dristin coding 35sec...
Time added to release of dristin Beta in 2015...
Yup....35sec
"The Old Man"
Re: Flow Chart
i think the fish is tryin to cast a spell on him like a wizard or something o.o
The bluest part of the sky seems so far away. I suppose thats what keeps us striving for it.
Why do people fear what they don't understand?
Why do people fear what they don't understand?
-
- Posts:96
- Joined:Jan 19, 2008 7:29 am
Re: Flow Chart
its father has young chicken on the knee
Tell me right now, what have you got to lose?
What have you got to lose, except your soul?
Who's with us ?
HAIL FOUL SOULS !!!!!!
What have you got to lose, except your soul?
Who's with us ?
HAIL FOUL SOULS !!!!!!
Re: Flow Chart
A fish just above the head is a bad sign. The clock by the knee is fine though.
I'd recommend skipping dependency graphs; some of the best programmers I know write code that looks horrific on a dependency graph -- and, although they care, correcting the graph is ranked low on their list of "TODOs".
You guys can probably do much better by writing code that is designed to make sense to yourselves, rather than code to match a standard or paradigm that you don't fully understand or care for.
For example, here's how Frostwinds looks (see Figure #1). Each of the boxes are Visual Studio project files:
Everything looks fine in that diagram, but look what happens when I select FrostServer (see Figure #2):
FrostServer has a dependence on FrostForm, and that doesn't look proper; the server is a console application and FrostForm defines GUI properties such as mouse-clicks and rasterization. I could very easily change it, but it really doesn't matter. It won't make the code easier to understand, nor will it reduce the lines of code. It would just be for making it look pretty on a graph.
I'd recommend skipping dependency graphs; some of the best programmers I know write code that looks horrific on a dependency graph -- and, although they care, correcting the graph is ranked low on their list of "TODOs".
You guys can probably do much better by writing code that is designed to make sense to yourselves, rather than code to match a standard or paradigm that you don't fully understand or care for.
For example, here's how Frostwinds looks (see Figure #1). Each of the boxes are Visual Studio project files:
Everything looks fine in that diagram, but look what happens when I select FrostServer (see Figure #2):
FrostServer has a dependence on FrostForm, and that doesn't look proper; the server is a console application and FrostForm defines GUI properties such as mouse-clicks and rasterization. I could very easily change it, but it really doesn't matter. It won't make the code easier to understand, nor will it reduce the lines of code. It would just be for making it look pretty on a graph.
Re: Flow Chart
Looks fine to me...
"We do not want an expanding struggle with consequences that no one can foresee, nor will we bluster or bully or flaunt our power. But we will not surrender and we will not retreat."