Should one use pseudocode before actual coding?

Question

Pseudocode helps us understand tasks in a language-agnostic manner. Is it best practice or suggested approach to have pseudocode creation as part of the development lifecycle? For instance:

• Identify and split the coding tasks
• Write pseudocode
• Get it approved [by PL or TL]
• Start Coding based on Pseudocode

Is this a suggested approach? Is it practiced in the industry?

Answer 1

Writing pseudocode before coding is certainly better than just coding without planning, but it's far from being a best practice. Test-driven development is an improvement.

Even better is to analyze the problem domain and design solutions using techniques like user stories, use cases, CRC cards, diagramming, as espoused by methodologies such as Cleanroom, RUP, Lean, Kanban, Agile, etc.

Thoroughly understanding the nature of the problem and the components you use to implement the solution is the principle behind best practices.

Answer 2

I use comments as a kind of very high-level pseudo code, in that I write the comments before I write the code. I find that thinking through the entire problem, even at a high level, improves my code considerably.

Answer 3

No, do not pseudo-code first

This is too much overhead. You're doing the work of writing the logic with none of the benefits. I'd suggest any of the following instead:

1. Prototype in the language you're going to ship with (AKA Write one to throw away)
2. Architecture diagrams w/ code snippets to test assumptions / key designs
3. Test Driven Development where you write your interfaces/code structure first, followed by tests, followed by implementing the code.

All three of these move you directly towards your solution, unlike pseudo-code. Personally I tend to use techniques 1 or 2 depending upon team size. For smaller (e.g. 5 people or less) teams, prototyping works very well. For larger teams that have multiple groups of developers working in parallel, I've found that documentation produced early by technique 2 works well because it gives you something to discuss early and helps you define component boundaries better. I'm sure TDD would work very well too, but I have yet to work on a team which had committed to this process.

Answer 4

In my opinion, pseudo-code has only two valid purposes:

(1) For programming students who need to learn the concepts of modularity and algorithms, but aren't yet fluent in a programming language.

(2) To communicate how something will work to a non-technical person, or just for the sake of expediency in a white-board type meeting.

Answer 5

Is pseudo-code a suggested approach? For beginning programmers, I say yes. It helps the new programmer learn how to translate a problem into code without worrying about the exact syntax of the language. This shapes the thought process and can help ingrain useful habits (and I suppose bad habits too). This is why it is used in schools so much.

Is it practiced in industry? In my experience, no. No one has the time to rough out the project between the documentation (requirements, specifications, story boards, use cases or whatever else they use) and the actual code. It is generally assumed that sufficient thought has already been put into the problem prior to the green-light to code. At that point, coding the project is more important than adding one more layer of design preparation.

Answer 6

I would definitely recommend pseudocode. It helps you clarify what you are going to do and identify items you may have forgotten or potential problems. Its far easier/faster to fix your code when it's still in the planning stages rather then waiting until you've already coded a large portion of it.

Answer 7

Pseudocode can be useful if you're unfamiliar with the language, or if you need to change mental contexts. On the rare occasion that I write pseudocode, it's on paper. Sometimes just taking your hands off the keyboard and scribbling on paper can help get around a mental block.

But as a formalised part of the development process? No way. It's a sporadically helpful tool for individuals. There are better ways to "know what you're writing before you write it", like:

1. defining the contract (pre/post/invariant conditions) of the method before you start
2. TDD
3. 1 and 2 combined (writing tests to execute the contract)

I'd also suggest that getting any sort of approval before you start writing code is likely to cause much more hassle than it's worth. Design reviews (pre-implementation) can be useful, but they need to be at a higher level than individual algorithms.

Answer 8

I'm going to disagree with the previous answers and say no, but with a caveat: you can get rid of psuedocode only if you're feverishly devoted to refactoring your code to deal with issues that crop up. Psuedocode is, at its essence, a way of defining your code before you define your code; it's an unnecessary abstraction in many circumstances, and since your code will never be perfect the first time (and likely, not follow the psuedocode's design to completion), it seems extraneous to me.

Answer 9

If you're writing COBOL or C, pseudocode may be helpful because writing the actual code will take much longer, and if you can verify your algorithm/requirements from the pseudocode, you can save some time.

In more modern languages, pseudocode doesn't make as much sense. What would work better is writing method stubs, and filling out the top level logic, and as much detail as necessary to verify the algorithm and requirements, all of this in actual code. You can then show that code to the Team Lead for approval, and have your real code already started.

Answer 10

The only times I've used pseudocode in the last 10 years are on interview when we're working on a whiteboard and the particular language doesn't matter.

It's certainly helpful for talking through a process/algorithm in loose terms without getting bogged down with syntax. E.g. writing a C++ class which has C# properties, just to illustrate the point.

It has its' place, but should only be used where needed (it's work that you'll throw away) and certainly not part of a formal process, unless you have ISO-type standards that insist on it.

Answer 11

For myself and the people I have worked with for the last few years pseudocode has pretty much turned into not entirely perfect real code. unless you work with many languages at the same time, most people seem to start thinking in the general pattern of their main language. I have worked in .net shops for a while so most people's whiteboard scribbles around the office tend to look like vb or c# with some of the punctuation missing.

The exercise is still valuable when debating options and such, but the language agnostic bit tends to drift away as you spend more time with a few languages.

Answer 12

More and more, pseudocode is written graphically with tools like UML. For instance, try out yUML.

an online tool for creating and publishing simple UML diagrams. It's makes it really easy for you to:

• Embed UML diagrams in blogs, emails and wikis.
• Post UML diagrams in forums and blog comments.
• Use directly within your web based bug tracking tool.
• Copy and paste UML diagrams into MS Word documents and Powerpoint presentations...

...yUML saves you time. It's designed to for those that like to create small UML diagrams and sketches.

Without yUML, creating a UML diagram might involve loading up a UML tool, creating a diagram, giving it a name, fiddling with layout, exporting it to bitmap, and then uploading it online somewhere. yUML doesn't make you do any of that...

Answer 13

Great work. You started a good discussion. As of me, I used to write pseudo codes when I was learning programming to understand the various loops and algorithms. This was more then one and half decades ago. That days, even programming languages were not much powerful... and event driven programming was future. Now with 4GLs and 5GLs, we think in the language itself rather then in plain English. When we think of a problem, we think in terms of objects and operations. And until it is a complex algo, writing pseudo codes (or P-S-E-U-DO-Codes, just kidding) does not make any sense. Better, represent the solution in a graphic way.

Answer 14

Depends on the language used, and your familiarity with it.

Many modern languages such as Python or Java are already so close to pseudocode that writing some ad hoc pseudocode first is wasteful, IMHO. Better just do it right away using the tracer bullet approach.

It's a different deal if you're making some low-level, close to metal things, or aren't yet comfortable with the language you're using. Then pseudocode can definitely be useful.

Answer 15

There tend to be a couple circumstances where pseudocode tends to get broken out in my work, which is in academia where programming tends to get used as a tool or the "and now we solve it" filling in the middle of a project:

1. When the code is going to be more counter-productive to an actual understanding of what's going to happen than pseudo-code will be. SAS for example, will take up half the whiteboard doing some fairly basic programming tasks. See also C, which some other posters have discussed.
2. With a lot of data analysis and statistics coding, there tends to be a lot of tinkering with the code as results are generated. Pseudocode is somewhat easier to use for "herein lies a back-and-forth process, if the diagnostic plot doesn't look right, try X".
3. Students learn lots of different programming languages. For example, among people I know, a statistics problem might be analyzed in SAS, R or Stata. Something that requires something closer to traditional programming might be done in R, Matlab, C, C++, Java, Python... it really depends on what particular student is implementing the program, and for what purpose. But it's still useful for the Java people and the Python people and the Matlab people to have a joint idea of what the others are doing, and how the approach, rather than the code itself, works.

Answer 16

This is not a yes/no kind of question. Rather, one should wonder when to use pseudo-code. It is important to understand the problem before designing a solution, and it is important to have a clear view of the solution before you implement it. Pseudo-code can be used in any of these steps:

1. When defining the problem, it's common to write down use cases, sometimes using sequences of actions.
2. When designing a solution. Class diagrams are nice, but they only describe the "static" part, i.e. the data. For the dynamic part, as soon as you need to deal with a loop and non-trivial data, I find pseudo-code to be the best method available. Graphical alternatives include state machines (good for complex control flow with little data) and dataflow diagrams (good for simple flows with complex data).
3. When implementing the solution (or just before). Some programming languages are hard to read (think, assembly). An alternative representation can be valuable in this case. If you are unfamiliar with the languages, it's also worth doing.

Pseudo-code that's actually proper code in a high-level language is also used, it's usually called prototyping.

In addition to achieving understanding, pseudo-code is also good for communication.

If you are wondering if you should use pseudo-code on a regular basis, I am personally against all kinds of rigid rules. This can easily turn into a boring waste of time if used for trivial problems everybody in the team understands. Using pseudo-code for specifications that you maintain throughout the project's life can also be costly and offer little value.