I do sometimes. My thoughts come all at once when I grasp a solution, and if I start implementation immediately I might lose something. But what I find much more interesting are all of the new ruby testing libraries like shoulda, bdd, cucumber, rspec, etc.
They are really innovating over there in rubyland.
You end up with comments that are USEFUL and do something.
to clarify, imagine if someone was reading your comments or spec of your project and could tap you on the shoulder, saying This code doesnāt do what you say it does.
Years ago I had a programming assignment, and while waiting for a new PC and software to arrive I chose to pseudo code while riding the local subway, and hour in the morning and an hour in the evening.
The process forced me to do several things:
think without typing (and without all the influences of a UI, language, etc.)
iterate
resolve
Needless to day, when I did sit down to code, many of the pieces almost coded themselves.
It is almost impossible for most people to code with pencil and paper when they have a computer on the desk!
On reviewā¦ What Jeremy said.
Nobody has mentioned Steve Yās take on this yet:
If you look back at the comments in my hypothetical code from 20 years ago, youāll see that I wasā¦making up a temporal narrative in an attempt to carve out a mental picture of the computation for myself. These stories I told myself were a critical part of my mental development as a programmer. I was a child trying to make sense of a big, scary new world.
Most programmers go through this phase. Itās perfectly normal.
Sorry, letās try that link again:
http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
I occasionally use pseudocode to help me get my head around a particularly complex sequence of code. Or as sort of TODO: placeholder for code that I still need to write.
If Iām in C# or some other high-level language then the pseudo-code comments generally get transmogrified into objects and method names.
If Iām writing bit-bashing C or assembler then I leave them as comments.
I find that if I try writing pseudo-code - I refine it and refine it and end up with - guess what? Code!
@Charasan: same thing with my professor. In my Introdution to Informatics class I have to write pseudocode using a structure, just like I would if I were writing code. In fact, instead of writing a program in a computer, we have to program in pseudocode exclusively, writing it in paper (mayor PITA). Also, they donāt even teach us C most of the time, they just tell you you see this statement in pseudocode? well, this is how you write it in C, and give us a C introduction book.
I donāt use pseudocode per se, but I definitely strive to drop in comments before hand. It helps to organize and structure your design and thought process before you jump in and start spewing code. Writers do this all the time, they create an OUTLINE before hand.
Although Iām a strong believer in the concept that comments should describe the WHY not the WHAT. People can read the code to understand most of the WHAT, but having the WHY is important to people reviewing and working in your code base.
I do not use pseudo code, Iām much more in favor of semantic code. I like many others in this thread was taught pseudo code in University, and quickly discarded it as impractical.
I find that the biggest problem with pseudo code and excessive comments in general is that they act like a crutch to allow you to write poorly written code. If I have a whole bunch of comments explaining what Iām doing than the importance of writing clean semantic code is lowered, because you can simply read the comment to see what my poorly written code is doing.
The problem is that programming is a mindset, once you are thinking about the variables, objects, and syntax of a program it is jarring to have to refer to some string of english to attempt to incorporate that knowledge into the knowledge your brain is building about that code. Itās like reading some beautiful python or ruby and then all of a sudden some inline FORTRAN is in there, sure you might know how to read FORTRAN just fine, but switching gears in your head takes some time and is an uncomfortable thing to do.
The other problem is that then you have to keep 2 models in sync, the code model of your program and the comment model of your program, it is very for these to become decoupled, compound that with writing inferior code because you believe that your comments make up for it, and wham, your code ends up on thedailywtf.com
just my $.02
For those of us who arenāt killer-code wranglers, this is an invaluable approach. Iām just a lowly sys-admin but I sometimes need to write some code and this gets me thinking in that vein, plus it comments my code. I find it really useful. YMMV.
I find it easier to think about code in code.
Then youāve entirely missed the point of PPP. The goal of writing pseudocode first is to think about your detailed design before you think about the code needed to implement it. PPP helps to clarify what you want to do before you actually implement it. Itās a tool that supports a particular process of thinking.
Now, different people use different thinking processes for different problems. Iām a big fan of PPP for much of my own work - it helps a lot when Iām writing business logic, to make sure I really understand the logic before itās implemented (the comments are a nice side-effect, not the goal) - but I donāt always use it.
Certain problems are easier to think about if I follow the plan to throw one away model instead. I write code as a way of thinking about design; then I write fresh code that implements that design.
I think the comment above about C# is a pretty fair one. Pseudocode is probably a really good idea next time Iām using x86 assembler or C++/ATL but in a good langugage suited to the domain Iām working in, like C#, or Python, or Ruby, or even Java, the level of the natural-language sentence is similar to the level of the actual code.
If I needed to, for example, call IUnknown, then call into ATL to make a COM call, then put the result into some data structure, then decompose the structure into the variables I want the results in, then Iād definitely want to put some pseudocode in to make sure I remember what Iām doing. Given thatās the equivalent of one ordinary call into the System or Windows namespace in .NET, Iād just write the function call in C#.
I guess I never really thought of it as Pseudocode. But I use it all the time when Iām thinking about other things at work, home, or other. It helps me work out what I want to do, when and if I ever get to do it when Iām at home.
But I do not actually use it in my code itās more of just a large mental note in an email.
I do this on occasion, though I didnāt know it had a formal name. For me, the value is not in the end result (which is, admittedly, code that is littered with comments of questionable value).
The value in it is that it allows you to design and plan your algorithm / block of code at a higher level, without getting caught up in the nitty-gritty syntactic details.
For example, it would be perfectly acceptable to say something like this in your pseudocode:
append array A to B, eliminating null values on the way
In pseudocode, thatās a one-liner, single step. Understandable. But if you try to do that in code, you suddenly get lost in the details: I have to extend the length of array B, possibly by creating a new array and copying all of B over, then reassigning B, then going through each element of A to see if itās null andā¦ Wait, why am I doing this again?
I like to compare this technique to the XP pair programming technique: in pair programming, the driver is in the details, the navigator is looking at the slightly bigger picture. By pseudocoding first, I perform both roles serially.
Iām about like ANaimiā¦ I donāt always use it, but often itās a helpful abstraction when Iām tackling a particularly complicated task, because it helps me to identify discrete subtasks that can be modularized, the precise order of those subtasks, that sort of thing.
But even my pseudocode tends to look more like actual code (usually C-like) than it does English prose.
Your example shows the basic problem of pseudocode: if it goes to any detail, it is actually longer than the code it describes: your example is 814 characters pseudocode to 378 characters code (without the comments).
Te idea of pseudocode originates from a time when coding involved a lot more bookkeeping and copy+paste code (Code Complete is from 1993; in the early 1990s, I was still sometimes writing assembler, and usually C).
I find it easier for myself to do Block diagrams of code, at least larger functions, before hand on paper. I find it more efficient, and you have something in front of you that you can always refer to or revise on the go (If done in pencil, I mean is that how everyone does it?)
Iāve used pseudocode lots of times, itās very valuable when the sequence is complex or involves a lot of things. You start mentally drawing what you have to do without worrying whether each line will be a function call, a statement or just any other line of code.
Some complex algorithms require this mental image. If you later delete the comments that is ok, but it can help a LOT in many circumstances.
At least it did (and does) for me.