July 1, 2002 at 11:40 am
I was wondering how many programmers actually use pseudocode before they go begin to program? and how many programmers just go staight to the program and do it "off-the-hat". I know that about 90% of the time I go straight to the program and start programming without doing any pre-programming coding.
RICHARD KIRMSS
RICHARD KIRMSS
July 2, 2002 at 5:11 am
Hi Richard,
I usualy write down comments first. So i create a empty main with all the required steps in comment. For the notation i use simple one liners what the purpose is of the function or object. This way i know exactly what to do and more important if i had to do an other project somebody else can easily finish.
Klaas-Jan
July 2, 2002 at 5:52 am
Depends on the scope. For situations that Im entirely comfortable (or pretty close) I'll just write the code. If its new, convoluted, etc, I'll work something out first, either by doing the comments as mentioned above or by diagramming on my flip chart so I have something to refer to while I work.
Andy
July 2, 2002 at 10:35 am
Similar to Andy. If it's something I've done, I'll probably just code.
If not, I'll probably outline some to be sure I won't forget anything and then fill in code. I might iterate a few times here and do more outlining (maybe break down steps) and then mode code.
Steve Jones
July 2, 2002 at 10:57 am
Do you (or anyone else) ever feel like they spend too much time outlining the code rather then actually coding. I feel that when I go and write a coded outline I spend way too much time actually writting psuedocode then writting the program itself. Is this bad?
RICHARD KIRMSS
RICHARD KIRMSS
July 2, 2002 at 11:37 am
Coding on the fly is generally a bad practice for any substantial effort. But I would see a good number of developers (including myself) do it for little bits of scripting and stuff like that. However, like Steve and Andy, I may generate a short list of steps or something that give some form to the program execution.
I don't think I ever feel I've spent too much time outlining code, but then again, I tend to write high level objectives and program flows, not psuedo-code, before starting to program. Here's an example for something I'm working on today:
1) Get domain groups from DB (enumerateGroups.pl has already run)
2) Retrieve global group membership from domain and write to staging table
3) Retieve local group membership from domain and write to staging table
4) write to history any membership additions
5) write to history any membership deletions
6) update state table with staging table contents
7) truncate staging table
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
July 2, 2002 at 12:28 pm
I agree with Brian in general. Coding on the fly leads you to forget things and make bad designs.
HOWEVER, I've been doing this a long time and a few things I've learned.
1. I learn as I go when working on a problem. Sometimes I spend a few days thinking on a problem or a design and then start working. However as I start to use the design, I will learn that I've incorrectly done something. OFten this is incomplete information at the beginning, but more and more I find the same thing with users. They do not know what they want, so they also tend to "learn" what they want after they see something.
2. Rapid iterations, small changes very often, has proven to be a more stable and effective solution for me than any other. Just my opinion, but delivering small chunks to a client or myself quickly speeds the learning process.
3. Most things I do are similar to other things. However, when and as I learn XSLT, I have to stop and really think about the steps I need to take, otherwise I waste time. So I spend more time thinking than coding in this area. The reverse in SQL.
Steve Jones
July 3, 2002 at 4:15 am
I agree with Brian. I've been coding numerous languages for the past 22 years, so if it's a small procedure or something I'm comfortable with, I'll usually dive straight into the code.
If it's something more complex, or I believe may mutate at a later date, then I'll design a breakdown of steps first to make sure that I've caught every eventuality.
What I can't get to grasp with is UML or flowcharting, it seems to make the taks even more complex.
For difficult tasks, I'll usually prototype the code, usually just with comments as to what I want to do anhd when. Then print it off and put it to one side for a day to give me time to think it over. This is where long woodland walks come in useful as I tend to argue out loud with myself (and my collegues think I'm sane! Ha!).
If I can't figure any changes, then I'll start the coding proper, elsewise I'll revise the design until I'm happy with it.
What I refuse to do, no matter the time constraints, is design a complex task straight off and code it knowing full well that something WILL go wrong with it at a later date, or it is going to be difficult to change when the time comes.
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
July 16, 2002 at 11:31 am
I guess I'm among the group that does this the wrong way. I almost always code first. I seldom write psuedo-code. I always have a list of specific things that someone wants me to develop and then I simply develop it. I comment as I go to help anyone who sees my code to read and understand it.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
July 16, 2002 at 8:53 pm
For me I walk the middle road. I tend to code right off on things I am comfortable with. Things I have not tried I will test until I understand what te effects are. It also helps to keep specific snippets available that can be reused quickly. And yes all this is done in a test environment, so mistakes are not a problem.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
July 20, 2002 at 10:10 am
Perhaps a personal bad habit, but I just dive in head first. I have never seen anything, regardless of the time spent on specs and prototyping, that didn't end up in at least 1 serious redesign, which, according to 'proper process' would initiate the entire cyle AGAIN. So I will slap together a working model with the expectation that the entire design is in question. I then present it back to the users instead of documents and pictures. Once everyone is in agreement, I go back and flesh it out into an actual application with error handling, comments, etc. It has served me well over the years and I outpace the 'method' developers but at least 25% and my aps end up closer to the users actual desires instead of some requirements document.
Feel free to yell at me as loud as you like. 🙂
WABALUBADUBDUB
July 22, 2002 at 10:33 am
The longer I've been doing this (only about 4 years now), the more I write and diagram before I code.
Simple stuff I still just write off the top of my head, but code with much complexity I spend a reasonable amount of time designing first. I think on a few occasions I have managed to over-design, but having something written in front of me can make it easier for me to pound out the code. Having something written also helps when I'm interrupted by something while I'm in the middle of coding; it helps me to pick up where I left off.
Having something written in my files also helps me to remember the reason I was coding something a particular way and what the design considerations were when I have to revise the program later. Often, I will have to make changes to something I wrote 6-9 months ago when I have no idea what my original justifications were for some pieces of the code. Having notes is like a cheat-sheet to get me back in the same train of thought I had when building the program originally.
Matthew Galbraith
ps: I used to be about 90% off the hat, and even when I did pre-coding work it was just comments to frame what I was going to do
July 23, 2002 at 1:57 pm
i find that writting psuedocode just takes a lot of time and hassel. Sometimes I get those projects where I only have a week or two to complete and taking time to write psuedocode is just a pain. i find that thinking the code through my head first and then going right into it is the best way for me. Yeah maybe i do make a few errors here and there but I always get it done on time.
RICHARD KIRMSS
RICHARD KIRMSS
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply