I often have serious concentration issues so I use pseudocode a lot. It is much easier for me to keep on coding without forgetting what I am doing when there’s high level pseudocode to look at. But I never leave pseudocode itself there as comments.
We were forced to write PC in high school. I really hated it and found it non practical.
I usually don’t write pseudocode before coding, but sometimes when I’m working on complex code, I do just that.
I don’t know what TDD/BDD tools exist for C/Java-family languages, but we use RSpec and Cucumber for writing tests on our Ruby projects.
Cucumber is great because it is similar to writing business logic statements that can then be translated into code. I used to write pseudo code, because thats what I was taught in College, but now I write Cucumber feature tests instead.
Yes, when the problem is larger than what I can code straight off.
Many of the pseudocode lines are statements of what the code should do, and they become title comments which state what the following section is supposed to accomplish… not the how, that’s what the code is for. For a maintenance programmer, having a clue about what the original programmer was trying to accomplish is a first step to understanding how the code works.
Other pseudocode lines are shorthand how, and they don’t survive as comments; they morph into actual code.
Sometimes, pseudocode lines become procedure/function/module names that are called… another example of morphing into actual code.
Self-documenting code is always the goal, but… we work with 3rd generation languages mostly, where the code is an expression of how, not what, so comments about intent/purpose/desired results are often valuable.
And yes, it has worked for me for decades.
You should re-read the portion about programming in a language vs. programming into a language… Of course pseudocode is of no value with trivial methods… and this is could be a good chunk of your code.
The interesting thing about my job is I am often trying to solve problems I have not already solved 100 times before…
When switching between languages, using a new API, or implementing a complex algorithm, you should be thinking about what you are going to do before you think about how you are going to do it. If you are thinking in code, you are still programming in a language…
-
Silly comments replicating the code nearby (or its names) are silly.
-
Pseudocode comments aren’t synonymous, although the former may be transformed or incorporated into the latter.
-
Totally agree with Andy Roublev on
if you only think about problems in terms of code I suspect the problems you’re trying to solve are not very complicated. (Either that, or you’re a super genius–but smart as you clearly are, you’re probably not a super genius).
Any complex matter I need to work on (product code, test code and even debugging of product/test failures) begins from figuring out:
- what is actually wanted/needed
- the knowns
- the unknowns (things to investigate further)
The above gets expressed in whatever way is appropriate for the problem:
- lists of items to take care in various places at various times in the design and implementation
- pseudo code
- flow charts/block diagrams (state machines naturally need these)
- math or whatever other domain specific language (DSL) is necessary or useful
I admit it to myself and I’m not embarrassed to tell it to others: I don’t have superpowers and I accept my natural limitations as a human:
- how many things I can keep in my mind at once
- how deep/far I can go into something, how many steps ahead
- where I am likely to make a mistake
- that it’s easy to fall for wrongful and unquestioned assumptions
- that I don’t know something
And I find ways around these limitations, which makes me a better programmer.
I try to:
- familiarize myself with the problem at the high level
- get as much of the necessary info/details upfront as possible
- ask questions or seek for other forms of clarification, where things are ambiguous
- plan figuring the remaining unknowns
- organize the acquired knowledge in a structured and logical way permitting me to:
- quickly navigate in it
- understand the prob from top to bottom or bottom-up
- have the details handy and reduce distraction
- keep track of the progress
- implement the damn thing
Trivial and simple things don’t need much of the above. But when you go nontrivial or the problem becomes intractable due to its size (I think 30KLOC would be it already), you clearly need to be more serious and organized. Else you miserably fail.
Do you write pseudo-code before writing code?
On a never-ending re-brand and redevelopment project, I have found myself taking business rules from paper to pseudo-code and from pseudo-code to flow charts before actually rewriting the process.
I have found the logic in the actual coded process to be horribly inefficient, and not worth the time to code to that then fix it.
It has helped me immensely in understanding how the website currently functions and how to improve upon what it has under the hood.
I tend to code first, comment later. When it comes to anything conceptually hard to code, I puzzle it out in iterative pseudocode first, coding what I am certain to be correct at each stage.
I use this method for the hard things, the things where I have to think about how the problem is to be solved. I start a method, and then jot down notes in it, as comments. Then I just leave them in place and code to them. And yes - a lot of the time, it will suggest what I’m working on needs to be further broken up into more routines.
I agree on having your code be as self-explanatory as possible, and ‘commenting to the exceptions’. Definitely a good practice.
More helpful than pseudocode to me is a simple English description of exactly WHAT a procedure does. I like to keep that separate from HOW it does it, for which I use code + comments. If you think about it, we designed programming languages specifically to express the HOW better than English does.
Never used pseudocode - it just seems like a wasted step, when it is so close to real code anyway! I’ve never seen a colleague use it either. People feel (right or wrongly) that it’s babyish!
I do use pseudocode for complicated algorithms.
BUT
I remove comments after it’s done. Such comments aren’t just useless, they’re dangerous when code gets modified.
I think you misunderstood Steve McConnell. He never said to intersperse your code with code. What’s would be point of that? He advocates writing the function first in plain English. Plain English is not pseudocode. Also, I’m pretty sure he advises to remove comments later if they turn out to be to close to the final code. There’s no use in repeating yourself.
And yes, I use this technique for difficult code, and find it invaluable. I’m not a fan of the it was difficult to write, it should be difficult to read-motto, I think someone who has to read my code later should at least know what I was thinking when I wrote it.
Languages are means to express your intent.
When I am writing this comment, for example, I think in English and I write in English.
Thinking in my native language and then trying to translate it to English would make both my thought process and the English boring.
Similarly, when you code, you “think” in the language you code.
Thinking in English and then trying to convert it to C# is lame. It makes both your thought process and the c# code that comes our boring.
It also makes the process of writting code much more time consuming.
I never see myself using pseudo code except when I interview candidates and there is a language mismatch. For example, when I am interviewing someone who knows only Java.
Other than that, I use it once in a while on white board to explain something to team members.
In that case however the code I scribble on the white board is more of C# in short hand rather than being true pseudo code or plain english.
Pseudo code is overrated. I think we should stop teaching it and start encouraging our programmers to think in the language of their choice.
Languages are means to express your intent.
When I am writing this comment, for example, I think in English and I write in English.
Thinking in my native language and then trying to translate it to English would make both my thought process and the English boring.
Similarly, when you code, you “think” in the language you code.
Thinking in English and then trying to convert it to C# is lame. It makes both your thought process and the c# code that comes our boring.
It also makes the process of writting code much more time consuming.
I never see myself using pseudo code except when I interview candidates and there is a language mismatch. For example, when I am interviewing someone who knows only Java.
Other than that, I use it once in a while on white board to explain something to team members.
In that case however the code I scribble on the white board is more of C# in short hand rather than being true pseudo code or plain english.
Pseudo code is overrated. I think we should stop teaching it and start encouraging our programmers to think in the programming language of their choice.
Languages are means to express your intent.
When I am writing this comment, for example, I think in English and I write in English.
Thinking in my native language and then trying to translate it to English would make both my thought process and the English boring.
Similarly, when you code, you “think” in the language you code.
Thinking in English and then trying to convert it to C# is lame. It makes both your thought process and the c# code that comes our boring.
It also makes the process of writting code much more time consuming.
I never see myself using pseudo code except when I interview candidates and there is a language mismatch. For example, when I am interviewing someone who knows only Java.
Other than that, I use it once in a while on white board to explain something to team members.
In that case however the code I scribble on the white board is more of C# in short hand rather than being true pseudo code or plain english.
Pseudo code is overrated. I think we should stop teaching it and start encouraging our programmers to think in the programming language of their choice.
I don’t write pseudocode in my own programming, but I use it extensively when teaching.
I encourage beginner programmers to use pseudocode to break code into manageable chunks, then write the code. The idea is that as you gain more experience, the chinks get bigger and the pseudocode reduces accordingly. I can plan and structure an entire method, or sometimes even an entire class, in my head. Beginners need to write it down and pseudocode is a good tool for this.
I also use pseudocode when guiding junior programmers. When assisting a junior programmer I could just write the code - it would be just as quick as writing the pseudocode. But if I write pseudocode and leave the junior to convert it to real code after our discussion then they are more likely to remember and learn from what I said.
With agile, TDD and refactoring as more of a refined method of coding - instead of writing pseudocode, I write tests and descriptive code.
McConnell wasn’t wrong, it’s just that for the most part nobody writes monolithic C programs with mostly 1-letter variable names, so the notion of writing pseudocode has been superseded. The industry as a whole appears to have progressed, so pseudocode is of limited use now in this process.
Pseudocode however is still very useful when describing how code is supposed to work to a non-technical audience, or when describing algorithms in a language agnostic manner.
+1 for Both at once. 
I both read and write c# faster than any kind of pseudo code.