A poll for professional developers (non professionals can also answer)

While in college I was talking to a (for now) Pascal coder. I am not really familiar with this language, basically what I understand he uses Delphi which I don't if it's the graphics developing environment or what. From what I understood from him, he uses Delphi to code in pascal.....so I don't really understand this point, please explain further. He told me that most developers (or the way it should be done) it's that you write your whole code on a piece of paper, before compiling it. Note: I do not mean just he design part of it, not a pseudo code, nor a flow chart, but the whole program. Do you do this?

I think that is ridiculous...

I write out my classes, function names and variables within the functions down - this is so I know what im doing and the general design i have, it's hard for me to think on the fly especially about naming my functions and variables - if I don't, i always get hang ups about the names of my functions and variables since i don't think they're clear enough and it's a whole waste of time i spend readjusting the names and then deleting variables and never get down to a real working product.

You absolutely don't need to hand write code down but it's such a wonderful time saver to have all your classes and functions and most of your variables mapped out before you begin... Also, i aint no super human and i rely alot on the code libraries and MSDN out there to help me do the meatball stuff so i don't really memorize much... I can't imagine coding on paper without any help - most books won't have everything you need - you'd have to become a roving library.

I do get maybe his motivation - I to don't enjoy spending a long time on the keyboard typing and looking at the screen - it's much more comfortable to sit outside or even laydown and design on paper than a laptop and especially a desktop.

Wait who answered that he/she does this occacionally, I'd like to know more. You mean you actually type a whole say 4000 lines program before you actually compile it? [hippie voice] (whoa far out) [/hippie voice]

I just sit down and program. putting thoughts down on paper may help, but even that i think is really just a waste of time. any outlines you can do on paper you can do just as easily (if not, easier) on the computer in the form of class definitions, etc. It's a quick and an easy way to lay out your thoughts before you begin to implement and in the end you're left with code that you can actually use during further development.

I chose "sort of" because sometimes, when I'm away from the computer (yes, that actually does happen sometimes, shocking, i know), i write code out on paper, though the only reason I do that is because I'm not by a computer.

Sometimes I don't even really do the UMLs (Class diagrams) until AFTER I've started. It's wierd. I think better on the fly while coding then before, so once my programs are done, they look nothing like the plan I had originally, because the plan missed so much. I guess I just can't plan ahead :P

Drives my instructors crazy, because my classmates have started imitating this method of just hacking code, but they can't do it. At least, not as quickly as I have.

Quote:

---

Originally posted by Polymorphic OOP
I just sit down and program. putting thoughts down on paper may help, but even that i think is really just a waste of time. any outlines you can do on paper you can do just as easily (if not, easier) on the computer in the form of class definitions, etc. It's a quick and an easy way to lay out your thoughts before you begin to implement and in the end you're left with code that you can actually use during further development.

I chose "sort of" because sometimes, when I'm away from the computer (yes, that actually does happen sometimes, shocking, i know), i write code out on paper, though the only reason I do that is because I'm not by a computer.

---

Oh ok, but not the whole program without the code on a compiler to see if you have any errors. The guy told me that once in class project as a group the teacher made the whole group do a 3000 line program on a piece of paper.

With the size of the code base that I maintain/upgrade at work I'd never get anything done if I wrote everything out like that.

If I'm stuck with a new unique problem that's got me stumped I'll psuedo code the logic out to get the idea of how I'm going to work it out.

At most sometimes I'll write a small app to test it out before I introduce it to the actual code of the actual program.

I jot down quick notes of mixed psudo code and algorithm. I tend to type my entire program before i ever attempt to compile it.

there are a lot of benefits from writing actual code on paper without a compiler when you're starting out, but certainly not when you know the language, at least IMO. I used to write code on paper during school when i first started learning c++ and it helped me a lot. it makes you really look at the code and analyze it without relying on the compiler to tell you when you did something wrong. it makes you think like a compiler and you learn to understand a lot of the reasons why certain things are the way they are in the language. I also noticed that when I wrote code out on paper it also decreased my runtime errors.

However, if you know the language, most of that you can do just as well directly on the computer. if you're starting off, it my help you to write code out and analyze it as though you were a compiler and linker, though i never recommend you do this for a lot of code, and generally, just keep it to class definitions, etc. and not so much direct implementation.

Good poll but result is predictable.

I always motivate myself to do it all the time. But I cannot keep my position.

But always I try. Specially pseudo code.

I haven't done that since the mid 70's. Back then, when entering your program meant making a deck of punched cards, you tended to do that because the cards cost money, so you wanted to be reasonably sure you got it right first time. You could buy pads of "coding sheets" which had 80 columns for you to fill in, I've still got some somewhere.

Do I still do it, hell no! Type in a bit, compile it debug it, type in a bit more...

Delphi is great by the way, I use it often, much easier than VC++ for database work.

Quote:

---

Delphi is great by the way, I use it often, much easier than VC++ for database work.

---

Right, my friend when develop's Delphi Db's based App, he uses Etv Library, and he says it's pretty easy, for more info ETV

>He told me that most developers (or the way it should be done)
>it's that you write your whole code on a piece of paper, before
>compiling it. Note: I do not mean just he design part of it, not a
>pseudo code, nor a flow chart, but the whole program. Do you
>do this?

I usually use UML to describe software before implementing, just as my collegues do. The advantage of using such a modelling language to describe the software is that you can discuss designs with your collegues in an easy way. This is an iterative process, usually you go several times through your designs, to make them matching the general architecture and the specifications. When a design is ready to implement, which doesn't imply the design is perfect, you start implementing.

To make a design more perfect, it is also usefull to think about testcases during the design phase. Every part of the specification must be covered by a testcase. This makes that you develop a good overview of how the software should function.

I do a lot of paperwork before actual coding, but I have never written a whole program text on a piece of paper, I don't see the advantage of doing that instead of immediately coding the same program text in your editor. When I have typed in a part of the program text, I usually print it out and read it. Reading from paper is, in my opinion, much easier then reading from screen. It makes you find errors more easily.

>>>
Reading from paper is, in my opinion, much easier then reading from screen. It makes you find errors more easily.
<<<

I used to do that when we used proper line printers on continuous fan-fold paper. Today, everything is a laser and individual sheets, not as good. Besides, I tend to debug with a realtime debugger now.

For most of my projects, I usually spend a lot of time thinking and planning them since most of them are large. I'd write out pages after pages of documentation (of course on the computer!) and how things work before I get coding. I'd also write out the class/function prototypes and whatever else I need to start the real coding like getting tools, testing algorithms, and such. This may seem like a lot of work but it helps you catch incompatabilities before you actually code them. It's helped me out a lot especially when you're working with other people. That way we're all on the same page when we start programming.

As for the programming part, it flys by when you have a plan ready. You know exactly what that class/function does in the whole scheme of things. The actual implementation and coding is up to you (on the fly thinking).

But, if I'm just something small like some class programming assignment, I don't document it before. I just write the prototypes and start.

I may do some notes sometimes, but then it's the general design or layouts. NEVER code nor pseudo code.

I talk to a professional electronic engineer who does most of his coding in Assembly and C. Alot of the time the companies that he works for say things like "I want pre-written source"; So since he is the head of his development team he tells them to finish their job, then at the end they print off their source code and say "Heres my pseudo", really what can a company do? Nothing. You did your job, you get paid, all is well. Although he did say that during the beginning of his career he wrote out a sort of schematic/hierarchy on paper on how things should work, but to ask experienced programmers to do pseudo code is rediculous.

Edit: Plus, in a consumer-driven market, there is no time to fiddle around with pseudo...let alone write the entire program on paper(Argueably, there would be hundreds of compile errors). It's okay to write out how things should work, but to write the entire source...

>Edit: Plus, in a consumer-driven market, there is no time to
>fiddle around with pseudo...let alone write the entire program
>on paper(Argueably, there would be hundreds of compile
>errors). It's okay to write out how things should work, but to
>write the entire source...

Especially in a consumer driven market where the time-to-market is very little, it is extremely important to have a good specification and design process. Our company does a lot of work for manufacturers of mobile phones, such projects are very short and have a deadline. When a product is finished after that deadline, the whole project is cancelled and a new project is started. So to be able to deliver high quality software in a short time it is very important to do paperwork.

Just a question, why would a company have pre-written source on paper? I have never seen that.

I chose the sort off thing because when im in school and im bored i start writing down some code (that are only small functions not entire programs)...+ sometimes im just watching the tele or reading something and then i think hey it would be great if i added that thing to my app or this..(right now its all about commands with down here: /stat /help /info /quit /hint /edit etc...).

Yeah, but small functions, or a little code is understandable, but I mean the WHOLE program.......by sort of, I meant sometimes, I guess I didn't specify well enough.