As the developer of a system that mixes a lot of technology, pseudo-code provides me a perfect starting point. I can drop all the pseudo-code into my .cs file, and then extract the required portions to SSIS/TSQL/SSRS as needed.
I generally just code the design as needed. But occasionally I run into a logically difficult section that I pseudocode parts of first so that I can make sure I understand what the designer wanted before I code it. Not often but useful at times.
Code Complete has always seemed to me the most overrated programming book. I picked it up and saw only a collection of obvious trivialities.
The strange thing is that I agree with most of your recommended reading (especially the pragmatic programmer, the mythical man month and peopleware) but I just donāt get this one. The pseudocode thing is a great example. I have not seen that since high school.
Pseudo code is thinking about implementation before you start writing code. As you said, if you are thinking about implementation you may as well do it in code. I prefer the BDD/TDD approach which is think about what it should do (expressed as a test or specification) before thinking about the implementation. Otherwise the implementation inevitable influences the design.
Wow, I couldnāt disagree with this post more. Stop thinking of the Psuedocode as commentsā¦ think of how you would be describing the logic to someone as if you werenāt even in front of a computer. And, you need to stay OUT of the details (code) when youāre designingā¦ even if just a stand-alone method.
(But most of your stuff is great Jeff!)
For significant pieces of work I think whiteboard, design docs, TDD or pairing works best - pick your favourite - but I like to take the following approach with small tasks, like writing a single routine or a new feature:
- Pseudocode
- Write the real code
- Improve code until it expresses my intent as clearly as the comment does
- Delete the comment
Thinking in code is all well and good, but isnāt there a risk you tie yourself to a particular implementation before youāve had a chance to think it through?
I write out the pseudocode, write out the python code, and then once the code is written I delete the pseudocode since the python code looks just like it.
Your pseudocode looks like python
Although its a matter of preference jeff but i think we cant underestimate the power of pseudocode (keep in mind english is not my native language). I still beleive that this is one of the power full and natural tool to think towards programming problems.
Programming is another name of solving problems, when we try to solve problem how it should be solved pseudoprograming come as native citizine to it.
I admit that we usually sit directly down to the keyboard but i often find myself scribbling on the paper after a while to confirm or clear my complex logic. so i think this is like unit testing which is rather tedious to use but fruitefull at the end.
Pseudocode has its place. I find it useful only when developing complex algorithms that would be difficult to simply straight-up code (i.e. algorithms whose polynomial-time efficient solution is not directly obvious).
Writing pseudocode for anything else seems silly and IMHO a waste of time.
I use pseudocode because I donāt have the intricacies of the syntax memorized, just the logic of the language.
I leave the pseudocode in because Iām better at reading English.
I have used pseudo-code, but not often.
Mainly when Iām figuring out a tricky algorithm or complex interaction, to clarify my thinking.
I hardly ever use it when Iām doing development where I have a good general idea of what the architecture is going to be, and where the majority of the code is going to be wiring things up.
What would be the point?
On certain complicated new implementations, Iāll regularly write comments before any code, right in the editor or IDE. If the process that needs to be followed is somewhat difficult, Iāll explain each major step with a comment and move on.
This helps me to be certain that Iāve got the flow right before beginning a lengthy coding session. Once all my comments are written, Iāll add the code under each comment and any methods that are required by that one block. Maintaining a flow of work without having to think too hard about the specifics of what comes next before itās time to tackle it.
So I reject psuedocode, but Iām all for comments before code when tackling a difficult problem.
Explaining what the code does is completely redundant. Actually, the boss gets upset if heās paying to have the same code written twiceā¦
// set the default status to fail
Status errorMessageStatus = Status_Failure;
DUH! This comment should state WHY the errorMessageStatus is defaulted to fail:
// default to fail in case we fall through the if logic below
Status errorMessageStatus = Status_Failure;
// look up the message based on the error code
Message errorMessage = LookupErrorMessage( errorToReport );
No Kidding? Really? Is that what that line of code does? (The authors self-documenting code skills are really showing through!) Still, how about something helpful here:
// Notes: All undefined errors return Undefined error.
// LookupErrorMessage() will EndProcess() in test case #4.23
Message errorMessage = LookupErrorMessage( errorToReport );
// if the error code is valid
if ( errorMessage.ValidCode() ) {
Is that comment helpful at all to anyone? How about:
// Invalid error codes are RARE! If you find one, please
// build a new test case and reference that case here.
if ( errorMessage.ValidCode() ) {
// determine the processing method
ProcessingMethod errorProcessingMethod = CurrentProcessingMethod();
Uh, not too helpful. How about:
// Error handling is different for GUI, CLI and library mode
ProcessingMethod errorProcessingMethod = CurrentProcessingMethod();
Iād actually prefer to see most of this code without the comments - it would be much easier for me to read since itās very self-documenting. But, and I know this is just an example, as far as Iām concerned, the only really important block of code here that warrants a comment is:
if ( errorProcessingMethod == ProcessingMethod_Interactive ) {
DisplayInteractiveMessage( errorMessage.Text() );
errorMessageStatus = Status_Success;
}
If I was maintaining this code, Iād sure like to know the technical/business rule behind this oneā¦
Comments should explain, to the greatest extent possible, why the code is implemented in the first place. Every development effort should be justified in some form.
I really loved reading and re-reading CC - but I never embraced pseudo code. Thanks for this discussion, now I know why!
I never read Code Complete, but yes, sometimes I write pseudocode.
One of my lecturer in college teach basic programming with pseudocode. She call it āmy languageā. We wrote algorithm (in a paper, not computer) using a set of predefined words, so itās not too pseudo after all. But it make a good programmint teaching tools, because we can understand what this code do.
When I write code for work, I put comment in pseudocode for function or section that I will implement later, but I have the idea now, how the code will work. For the function I implement right away, I donāt always put comment, but when I put a comment, it in pseudocode form.
first
Thereās something fundamentallyā¦ unrealisticā¦ about attempting to using precise English to describe the nuts and bolts of code.
Donāt mean to nitpick, but isnāt there a grammar error here? Shouldnāt it be use and not using?
Figured Iād point it out. ahem [/nitpicking][content type=useful]
I donāt usually write Pseudo code in that style. Rarely do I ever write it in anything other than C. However, I do typically find it useful when dealing with corporate-level projects with lots of classes and object oriented programming and things. Mainly, it lets me examine the logic of what the functions are supposed to do, in order, and think properly about restructuring the whole thing to either make it faster, or more maintainable.
Iāve recently had the pleasure of starting a giant project (an OS kernel) and one thing Iām making sure to do is document the entire process before writing a single line of functioning code. Sure, Iāve got a basic bootdisk running right now with some barebones stuff, but my teammates and I have agreed to document what the big picture needs to do (and discuss logic) before getting involved in the mess of code that this project is sure to become.
For small projects or simple routines? No way would I use Pseudo code. I donāt even really like to use it on larger projects unless I really donāt quite understand what the routines needs to accomplish. If itās a concept that Iām just re-iterating again in the language of the hour, thereās no point really.
Pseudo code (and other high-level design concepts like flowcharts, ugh, donāt even mention flowcharts in the same city as me or Iāll shudder) has always come across to me as a big corporation of business men trying very hard to end up with code from their developers that they might be able to either (a) understand themselves, or (b) pass on to other developers with minimal friction. From one good coder to another, that level of deep, intimate commenting isnāt necessary, since good developers should be able to quickly make sense out of even poorly commented or written code, TheDailyWTF notwithstanding. Again though, just because I havenāt used it and donāt prefer to use it (Iām very much a straight to the code sort of guy) doesnāt make it bad practice, this is all just my personal opinion from my experience.
I kind of dismissed it as a way of adding a lot of totally redundant comments to code when I first read CC.
Why not focus your efforts on making the comments you do need really good rather than adding comments for stuff that should be self-explanatory in code?
If you like to document your methods I think maybe writing up the Javadoc ( or whatever the .net equivalent is called ) comments before you create the method may offer similar benefits ( and indeed greater ones in terms of IDE discoverability ) and avoid the unnecessary redundancy. I would be more likely to do that than to dabble in pseudocode.
Do you write pseudocode before writing code?
Both. At onceā¦ Python \o/
At my first job, when we were working through new functionality, weād go up on the whiteboard and everyone would be talking about what was necessary before we sat down to write the code. It was a pretty good way to get everyone on the same page, and make sure we didnāt forget anything.
I still do the same thing now - the other day I was designing new SQL tables, and I went to the whiteboard to draw each table, elaborate on its purpose (to myself), and define the relations between them. It also helped me be more certain about all the fields the tables would need. And then it was easy to look at the board as Iām working in Management Studio actually building the tables.
I use it very sparingly, usually when iām having trouble previewing the code Iām about to write in my head.
I guess that means Iām still better at thinking in my native language than in code.