In either case you work outside in, creating the most abstract things before the most concrete things. |
L B wrote: |
---|
Now let's look at the guy who does it the wrong way [...] First, he starts by writing the general headers of the classes |
"I wrote declarations and interfaces before I wrote any declarations and interfaces." |
Is it easier to erase lines and text on paper than it is to delete methods in text files? |
What he ends up with is a thing that has been through a lot of changes and revisions, complete redos, maybe just a mess that happens to work. |
Cubbi wrote: |
---|
That's where your picture breaks down: if he didn't have a design, how does he know what classes to write? |
rapidcoder wrote: |
---|
In that case you are doing it wrong. You should start with concrete stuff and get the damn thing working as fast as possible. Then build abstractions on top of that. I have never, ever seen a coder or designer, who got the abstract design right without first creating some concrete stuff. Working outside in works fine only on paper. Real coders work inside out. |
chrisname wrote: |
---|
I don't plan or design my programs, I just write and refactor as I go along. I mostly program for personal enjoyment and I enjoy the actual coding. I do brainstorm, but I rarely write anything down, and when I do, I usually delete it afterwards. |
Duoas wrote: |
---|
When you are working on large and complex systems, you absolutely must do some planning first. Part of planning is a discovery stage, where you do write small programs to poke around the system and test some ideas. |
Cubbi wrote: |
---|
That's where your picture breaks down: if he didn't have a design, how does he know what classes to write? |
ibbuC wrote: |
---|
That's where your picture breaks down: if he didn't have a design, how does he know what shapes to draw? |
Cubbi wrote: |
---|
Ah, I see, you equate the expressiveness of "declarations and interfaces" written in terms of some programming language (e.g. C++) in a text file with expressiveness of "lines on paper" |
Cubbi wrote: |
---|
Yes! A line on a diagram may mean days, weeks, months of work to put together as "methods in text files" - even if you're not writing any executable code. I can erase and redraw dozens of those lines on the whiteboard while going through an early design meeting. |
Cubbi wrote: |
---|
Sounds like open source software :) |
chrisname wrote: |
---|
When I come up with an idea for a project I kind of know straight away what I absolutely need (e.g. for a game or emulator the first thing I write is the main loop), and then I start writing code straight away. If I need something, e.g. a structure or class, or a function or set of functions, I switch to writing that and then go back to where I was. |
L B wrote: |
---|
Cubbi wrote: That's where your picture breaks down: if he didn't have a design, how does he know what classes to write? ibbuC wrote: That's where your picture breaks down: if he didn't have a design, how does he know what shapes to draw? |
I'd like to know why Doxygen does it |
L B wrote: |
---|
When I come up with an idea for a project I kind of know straight away what I absolutely need (e.g. for a game or emulator the first thing I write is the main loop), and then I start writing code straight away. If I need something, e.g. a structure or class, or a function or set of functions, I switch to writing that and then go back to where I was. Pretty similar what I do, except I usually get side-tracked. |
DeXecipher wrote: |
---|
listing all the shit i wanted to do. |
Stewbond wrote: |
---|
It seems like a good way to work from the top down which eventually turns into code. |