This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I've been studying some java books, and in every one of them they propagate pseudocode. The problem is I really don't like it!
Now I would like to hear your opinion on it? How do you actually prepare for coding (if you prepare at all), is pc good or bad for larger projects, what are the alternatives (I've only done flowcharts besides pc)...
If it's a huge mistake not to do pc, then why? And what's the best way to learn it? Can you suggest a good book about developing with pc?
"Pseudocode" please, not "pc": read this for an explanation.
And Fred is correct: if you can't work out an algorithm, pseudocode will help you no end.
Joined: May 13, 2009
Another thought... In some cases, depending on how you do it, pseudo code actually is, or is very close to, real code, in the sense that your high level steps become method calls for which the methods have not yet been written. Maybe you can can then write "dummy" method bodies with simple print statements that verifying that the arguments are being passed properly. This might even compile, then you can get to work on fleshing out your methods.
Joined: Jan 03, 2009
(sorry for the "pc", I tought that only leet is forbidden, won't do it again)
I guess I'll have to work with pseudocode...but what's with test driven development? Is anybody using it? As I get it you still have to do some pseudocode, but far less.
Here's a question for the professionals among you: what's about the percentage among your colleagues that use pseudocode or test driven development, and does your company actually demand one approach or you have your own freedom to chose?
Irmin Okic wrote:(but what's with test driven development? Is anybody using it? As I get it you still have to do some pseudocode, but far less.
Test driven development doesn't use pseudocode. It uses working compiling Java code that just doesn't implement much at the beginning.
Irmin Okic wrote:Here's a question for the professionals among you: what's about the percentage among your colleagues that use pseudocode or test driven development, and does your company actually demand one approach or you have your own freedom to chose?
I use both sometimes, but not always. My company doesn't dictate an approach.
pseudocode - I use this when communicating to others about a task/algorithm. I don't type it - it goes on paper or a whiteboard.
test driven development - Depends on the type of code I am writing. If it is library code, I always use Test Driven Development. If it's something that's basically calling another method (like an EJB), I tend to test last.
same here, a combination of both. Probably more test driven when I think about it. I guess it depends what you mean by pseudo code. Even if you don't actually write pseudo code, you still have to give some thought as to the high level steps of the application. And maybe make a few notes to help formulate your thoughts. I see pseudo code as a way of documenting your thoughts in a semi formal manner. Whether you document it or not, the thoughts about high level steps are still there.
Irmin, my approach to pseudo code is pretty informal, maybe you are thinking of something a little more rigorous, I don't know. If it helps you write programs, use it, if it doesn't help, don't use it.
Joined: Jan 03, 2009
I like to hear that! I too, realized that I have to put a plan on paper when I'm working with more complex problems, but it's more informal. The thing that got me confused is that, in the books i studied from, they did pseudocode until the level they just needed to translate it. Probably because they're aimed at beginners.
As I advance I hope that I'll find the way that suites me best...
Thank you for your replies...now my mind is at ease and I can continue studying.
Joined: May 13, 2009
cool! Programming really is, in one sense, a creative process. Sure there is good code and bad code, but the process that gets you there is very much open to individuality.
I just think it's very interesting the different design approaches that people might use for the same problem. As long as the design is robust and maintainable, and portable, and even scaleable if need be, then there is still a lot of room for individuality.