macOS Does Pseudocode Teach Bad Habits?

[bobber205]

I know I'll get flamed for this.

After taking a term of C++ at my tech-oriented school in Oregon, I've reached a opinion. Pseuodocode, much of the time, teaches bad habits. Here's why.

I came to this opinion after the 10th time helping yet another student trying to finish their lab. While helping, I noticed several papers of just text. I asked what that was. He said pseudocode. WTF? 3 pages? I checked it out and aside from being all in english and no actual code, the damn thing sure looked like code. It was that detailed.

However, the connection between knowing what to do and actually implementing it was far from him and his lab partner. They had written the pseudocode together, not a bad thing. However, they decided since they knew the pseudocode was spot on, the wrote all the code in one sitting, then debugged!



I was shocked. My coding style has always been this: implement a small feature, test it throughouly and make sure it works before continuing. They had not done this. There were about 50 compiler errors, not to mention logic errors they were obviously going to show up. After about only a hour of actual code typing, they had at least 6 hours of debugging ahead of them. This relatively simply project took me about 4 hours to complete.

This is not the first time I have seen this. I would say at least 1/2 of my friends and peers write a crapload of code, then try to run it and get the correct results. While I do think pseuodocode has its merits, I wish my school would teach careful coding and thinking ahead instead of concerntrating on pseuodocode. One professor is specifically known for emphasising good pseuodocode over everything else.

My pseudocode for the project they were working on was this:

Read Data From File 
Put Data Into Appropriate Arrays

Sort Arrays Based On Last Name
Sort Using The Bubble Sort Method

Print Menu
Have User Enter Choice
Process Choice

When Closing Save Data To Textfile

I know it's fairly basic, but that's exactly what my program did. Fortunately for me, my professor clalims this is sufficient. His views are that pseudocode should be short and that any non coding person could read it and know what your code should be doing.

What's your thoughts?

 

[robbieduncan]

Most people who are in your programming class (if it's anything like mine were at Uni) will never use what they learn professionally. Most of them are not good programmers. Most of them are not even competent, most of them are rubbish. Around 40% of you are probably OK, maybe 10% or less actually really good.

The 60% who are not good don't really know what they are doing. And just like anything else in life if you don't know what you are doing you will tend to use the tools badly.

Pseudocode, UML, flow charts and other design tools are just that: tools. If used well they are great. Used by those who don't know what they are doing the results are terrible. Good Pseudocode should enforce good habits, bad coders will write bad Pseudocode, and then terrible code based on it.

My personal take would be that I would include key loops in my Pseuodcode, but for a short (standard class assignment sized piece of code) it should be half a side of paper or less. I would always go with your style of programming. Write a little, compile and test then write some more (but save Optimisation till later)...

 

[bobber205]

It's weird, programming.

I've been programming since I was 12.

(It was called Learn To Program BASIC, a pp that ran on OS 7.)

Some people seem just to not "get it". There's about 6 of us in our class who are naturally doing well. The few others are working their asses off, the rest are barely passing/failing.

 

[robbieduncan]

It's weird, programming.

I've been programming since I was 12.

(It was called Learn To Program BASIC, a pp that ran on OS 7.)

Some people seem just to not "get it". There's about 6 of us in our class who are naturally doing well. The few others are working their asses off, the rest are barely passing/failing.

That's basically what I was getting at. Some people get it, some people don't. If you don't get it you'll never be that good at it and it will always be hard work. The same is pretty much true of maths, languages....

I was probably being kind with my percentages. The 6 of you are probably the only ones actually enjoying the class and the only ones I'd say will go on to a job programming (if they/you want to). The others might try but they'll not last a year...

 

[SMM]

This question should generate some interesting views. My first comment would be, what you learn to do in school, may be the last time you ever do it. There are so many variables that come into to play, once you get into the real world.

Large companies are generally very structured. In fact, they can be so focused on the development process, it is a miracle when they actually accomplish anything. I actually know of projects which were scrapped because they were antiquated before they were completed.

On the opposite side, there are those who support 'extreme' development. There is little structure and the idea is to get the application completed as fast as possible. You launch it and fix problems as they arise.

You never know which world you may end up in. Our department develops business software for a single company. We have programming standards, but each developer is allowed to work in a style they like. I use pseudo-code, but it is mainly to organize my structure and the functions the program will require. Or, in other words, it is how I think through the problem. Beyond that, I want to spend my time coding and testing.

 

[ChrisA]

I've worked on a number of large projects. "Large" means there is no one who knows how the thing works. Just as an example one of them was a radar. If you knew anything abut digital signal processing and control of the RF equipment you almost certainly don't even know the names of the programmers working on the graphical displays at the other end of the hallway. That was in about 1980. Today I'm working with rocket telemetry and for the last 3 years been developing a kind of compiler for a specialized type of parallel computer. Again there are guys working on display and analysis software. It's fun to watch the displays during a launch but I don't know much about the software that runs in the computers in that room. This is just the way it is in the real world. Projects can have a million lines of code. No body reads a million lines. 50,000 is about all I can keep in my head. I've heard of the names of some of the modules in the other 950,000 lines but thats about it.

OK so what? If all this is to work TOGETHER then we spend a lot, yes a LOT of time writing design documents. presenting out design documents to review committees. re-working our design documents. Working down the list of "action items" associated with our design documents. Then typically after blowing through 1/3rd to 1/2 to project budget we write some code. This takes about 1/10th of the project budget. The remainder goes into test and integration. In the real world writing code takes only a small part of the time. The hard parts are (1) deciding what _exactly_ to write and (2) making sure it work AND works with what everyone else is doing.

So Pseudo code, charts, block diagrams, get put into endless Power Point charts. are the major product of a software engineering group.

School projects are really a non-typical case. They tend to be very well defined and small in scope. but in the real world this is never the case and you would need a way to express the proposed design at a high level so it can be critiqued.

It's a wonder large projects ever work.

 

[ChrisA]

On the opposite side, there are those who support 'extreme' development. There is little structure and the idea is to get the application completed as fast as possible. You launch it and fix problems as they arise.

The method or "process" really has to be tuned to the product you are building. Over-structuring a process can kill a project but in some case under-structuring can kill people. Balance is the key.

If some one's life is depending on your software working correctly for years on end I'd bet no one would conceder "extreme' development" that is something best suited to making web pages, on-line pet food stores and the like If the software is controlling a display that is in turn controlling a laser guided bomb or if the software is controlling a torpedo or air to ground missile you don't "just start coding and then improve it little by little and see where it takes you." In those cases you feel more like a mathematician defending a new proof at a whiteboard to a room of skeptics. You spend most of the time answering questions like "what happens if the frame checksum does fail?"

 

[weg]

I was shocked. My coding style has always been this: implement a small feature, test it throughouly and make sure it works before continuing.

In general, I think it's a good idea to have a plan of what you want to program before you start (rather than starting to implement the program and keep changing it until you think you've reached what you initially intended to achieve).

Pseudocode (as a specification) can help you to detect some problems that you'd only find way later in the project (things like: "Oh f***, module X needs to write to these parameters? Then I shouldn't have made them const everywhere else").

In your first job (from what you've written I assume that you're an assistant or tutor at your university) you'll see that, in a real project, a lot of paper is produced before the first line is coded. It's annoying, but necessary. What your students did wasn't all that wrong (even though they lacked enough experience to implement it). I've seen people that start coding before they even understand the algorithms they want to implement way too often.

 

[Catfish_Man]

In your first job (from what you've written I assume that you're an assistant or tutor at your university) you'll see that, in a real project, a lot of paper is produced before the first line is coded. It's annoying, but necessary. What your students did wasn't all that wrong (even though they lacked enough experience to implement it). I've seen people that start coding before they even understand the algorithms they want to implement way too often.

Depends very much on the job, and the project at that job. I've definitely seen "dive-in-and-go" projects in the real world... and not always as a result of poor planning; iterative design can be quite functional if you get the rough outline right at first (and/or are prepared to do a lot of refactoring along the way).

 

[mags631]

I don't agree that pseudo-code teaches poor coding habits. However, I would think that a programming class should require actual code to prove that the student can actually program.

Even if we agree with the professor's approach, I think that example presented does not meet the bar for clarity or completeness. Loops and recursive calls should be explicit and specify what action is being looped. If we forgive the student from writing code, I think the onus is on him/her to be clear and concise in the pseudo-code and to still document arbitrary decisions with a comment.

Here would be my concerns:
1. Where does "File" come from -- is it a known name, then specify it. Is it provided by the user? How?
2. What "Data"?
3. Why multiple Arrays? How does the program select the APPROPRIATE array?
4. Sort in which direction? Missing ascending or descending specification.
5. Why Bubble Sort? Do they have library call to use, if not, then they need to specify how the bubble sort works.
6. Menu of what?
7. Process how?
8. Is Textfile different from File, how is it known?

 

[gnasher729]

Depends very much on the job, and the project at that job. I've definitely seen "dive-in-and-go" projects in the real world... and not always as a result of poor planning; iterative design can be quite functional if you get the rough outline right at first (and/or are prepared to do a lot of refactoring along the way).

Another situation: There is a problem. I don't understand the problem fully yet, and I know that I don't understand it fully. And I'm not quite sure yet how to solve it. That's when you should start thinking and investigating. How do you go about this? One method that helps is writing prototypes to help you understand the problem. One method that can help is writing code, figuring out what works, what doesn't work, and by doing that you can figure out how to do it properly. The important thing is: Once you have done that, you write down what exactly the problem is, how exactly to handle it, and you _throw away_ all that code that you have written. (That approach is not for everyone. Different people's minds work in different ways. )

 

[balamw]

My coding style has always been this: implement a small feature, test it throughouly and make sure it works before continuing.

It depends on the person, problem and situation, but for me the big value of pseudocode is to help you identify the blocks of code that need the most attention up front.

What are the things you already have in your bag of tricks, e.g. the bubble sort, and what are the things you need to work on, key loops, etc... For example I might already have code to get a filename and read it in, so reuse thaat for now, until it needs to be rewritten. What's unique about this problem?

B

 

[jhande]

I used to use pseudocode extensively, but over the years have switched more and more to prototyping.

These days I use pseudocode either when communicating to others (proj. members, mgrs, clients), or when I'm not really clear on the algorithm yet. Also, when the language itself is crufty (like fx. C), and I've ended up in a blind alley.

However, when programming in Python, Ada or Haskell (still learning the latter, and pseudocode doesn't make much sense here anyway), I find that prototyping is much faster.

The border between pseudocode and prototyping is diffuse, and it also depends on the programming languade, development environment, and communication needs that you have.

Put it another way wrt to communication: if it is too complex in code, use pseudocode. If that is too complex, use the necessary tools (UML etc.) to get your point across. IOW use what works in that particular situation.

My .02

 

[lazydog]

Read Data From File 
Put Data Into Appropriate Arrays

Sort Arrays Based On Last Name
Sort Using The Bubble Sort Method

Print Menu
Have User Enter Choice
Process Choice

When Closing Save Data To Textfile

Perhaps one day computers will be smart enough to understand pseudocode and… well … will just get on with it. I can just see the headline news… Mac programmer inadvertently brings on Judgement Day by the ambiguous use of the word 'execute'.

Sorry for going off topic!

b e n

 

[i_am_a_cow]

Perhaps one day computers will be smart enough to understand pseudocode and… well … will just get on with it.
b e n

haha they already are, it's called ruby