I fundamentally disagree with pseudocode and all the arguments made out on this um, paper? It is written by a educator who has seen lots of shitty unreadable student code which is about the only time pseudocode makes sense to write. But even then, if they cannot form what they want in code what makes making them form what they want in words any better?
But spending ten minutes to think out carefully the pros and cons of different approaches to the goal can save you hours of time debugging and refactoring your code later on.
I find the opposite. Spending time writing pseudocode leads to far more time wasting on things that don’t work. One of the biggest problems with pseudocode is YOU CANNOT RUN THE CODE. Not until you have fully finished thinking about it and then converted it to actual code. Only then can you tell if the code even does what you want. No, far better to write a small segment of code and then incrementally build and test it little by little. Then I can verify my ideas are taking me in the right direction and not resulting in some weird behavior due to some broken assumption I made early on.
Incremental development is the way to go. Just test things as you write them. Don’t write the whole program (and then rewrite it again in an actual language) before you ever even run it. Write a small bit, test it, refactor and continue. You cannot do that with pseudocode and it is vastly harder to debug something that is complete rather than incrementally checking it at every stage as you progress.
Pseudocode makes low-level design reviews easier and reduces the need to review the code itself.
No, no it does not. You NEED to review the source code to see if it does what the person thought it would do. This step cannot be skipped. So what value does pseudocode add then? The code should be readable enough on its own without basically doubling the amount of lines you need to read. Plus NO ONE READS COMMENTS. This comes from 15+ years in the industry. More often then not I see comments that are out of date and no longer describe the code they are talking about. It is a lot of effort to keep comments in sync with code and not worth the effort. There should be no pseudocode comments in your code at the review stage.
Pseudocode supports the idea of iterative refinement
Iterative refinement is vastly better when you get feedback on what you have written. The best place to get that is to run the code and see what it does (either manually or via testing). You cannot do that with pseudocode. Only hope that you can spot a problem, which more often then not you will not. If you write actual code you can run it and see if it fails and how it fails.
Pseudocode makes changes easier. A few lines of pseudocode are easier to change than a page of code
That is a false comparison, why would you only have a few lines of pseudocode and a whole page of code? Surely your psudocode will roughly match the number of lines of actual code? Otherwise what is the point in it and how will it help you spot any problems? You can always write real code as a series of function calls to hide away the implementations if you want a similar approach.
Pseudocode minimizes commenting effort
Not writing comments minimizes commenting effort. Comments should be used sparingly to describe things that cannot be describe in code. IMO the only comments worth while (at least ones that are not doc blocks) are ones that describe external factors. Like “this is to work around this bug <link to bug report>”. Or “we tried the more obvious solution here X but found it caused problems Y” or “this is actually required due to this weird undocumented behavior”. Comments that just describe the code are a waste of time and effort as you now have your code defined twice. Once where people will read in the actual code and once where people will ignore and will slowly rot and worst start to lie. The number of times I have seen a comment contradict the code and have no clue if the code or the comment is right… More often it is the code that is write and the comment is hideously out of date. That just becomes wasted effort trying to figure things out.
With other approaches, design is separated from the code, and when one changes, the two fall out of agreement… As long as the inline comments are maintained, the pseudocode’s documentation of the design will be accurate.
That is a big if there, IF they get maintained. Which they wont. It is far too much effort to edit the code twice. No one wants to do that and so no one does do that. Just read the code if you want to know what the code is doing and reject PRs for code the is unreadable.
The only people I ever see arguing for psudocode are professors that have never worked in the industry and spend far more time reading crappy students code than anything else. I have never seen anyone actually do this in production systems.
The only time pseudo code might make sense is in academic papers, where there might be strict page limits. Even then, the paper should link to the actual code. It’s quite often the pseudo code gloss over or even misses important implementation details.
I fundamentally disagree with pseudocode and all the arguments made out on this um, paper? It is written by a educator who has seen lots of shitty unreadable student code which is about the only time pseudocode makes sense to write. But even then, if they cannot form what they want in code what makes making them form what they want in words any better?
I find the opposite. Spending time writing pseudocode leads to far more time wasting on things that don’t work. One of the biggest problems with pseudocode is YOU CANNOT RUN THE CODE. Not until you have fully finished thinking about it and then converted it to actual code. Only then can you tell if the code even does what you want. No, far better to write a small segment of code and then incrementally build and test it little by little. Then I can verify my ideas are taking me in the right direction and not resulting in some weird behavior due to some broken assumption I made early on.
Incremental development is the way to go. Just test things as you write them. Don’t write the whole program (and then rewrite it again in an actual language) before you ever even run it. Write a small bit, test it, refactor and continue. You cannot do that with pseudocode and it is vastly harder to debug something that is complete rather than incrementally checking it at every stage as you progress.
No, no it does not. You NEED to review the source code to see if it does what the person thought it would do. This step cannot be skipped. So what value does pseudocode add then? The code should be readable enough on its own without basically doubling the amount of lines you need to read. Plus NO ONE READS COMMENTS. This comes from 15+ years in the industry. More often then not I see comments that are out of date and no longer describe the code they are talking about. It is a lot of effort to keep comments in sync with code and not worth the effort. There should be no pseudocode comments in your code at the review stage.
Iterative refinement is vastly better when you get feedback on what you have written. The best place to get that is to run the code and see what it does (either manually or via testing). You cannot do that with pseudocode. Only hope that you can spot a problem, which more often then not you will not. If you write actual code you can run it and see if it fails and how it fails.
That is a false comparison, why would you only have a few lines of pseudocode and a whole page of code? Surely your psudocode will roughly match the number of lines of actual code? Otherwise what is the point in it and how will it help you spot any problems? You can always write real code as a series of function calls to hide away the implementations if you want a similar approach.
Not writing comments minimizes commenting effort. Comments should be used sparingly to describe things that cannot be describe in code. IMO the only comments worth while (at least ones that are not doc blocks) are ones that describe external factors. Like “this is to work around this bug <link to bug report>”. Or “we tried the more obvious solution here X but found it caused problems Y” or “this is actually required due to this weird undocumented behavior”. Comments that just describe the code are a waste of time and effort as you now have your code defined twice. Once where people will read in the actual code and once where people will ignore and will slowly rot and worst start to lie. The number of times I have seen a comment contradict the code and have no clue if the code or the comment is right… More often it is the code that is write and the comment is hideously out of date. That just becomes wasted effort trying to figure things out.
That is a big if there, IF they get maintained. Which they wont. It is far too much effort to edit the code twice. No one wants to do that and so no one does do that. Just read the code if you want to know what the code is doing and reject PRs for code the is unreadable.
The only people I ever see arguing for psudocode are professors that have never worked in the industry and spend far more time reading crappy students code than anything else. I have never seen anyone actually do this in production systems.
Agree.
The only time pseudo code might make sense is in academic papers, where there might be strict page limits. Even then, the paper should link to the actual code. It’s quite often the pseudo code gloss over or even misses important implementation details.