Do you guys use pseudocode? and other questions on the basics

Hey I am starting programming C again and I want to make sure I understand and do the basics when it comes to programming, one of which may be pseudocode. See I understand the syntax and the like of C and can program in it, but I want to make sure I know the basics of programming in general so I will be more efficient in writing programs. I guess my question is, do you guys use pseudocode before writing a program? Also, what basics should I know when it comes to programming, i.e. what general knowledge?

You can try it and then find out what fits your style ;)

Quote:

---

Originally Posted by Grell

I guess my question is, do you guys use pseudocode before writing a program?

---

Not before writing. That doesn't make a lot of sense for larger programs. But I use pseudocode frequently to think about small programming problems before actually coding that specific part or function. It's pretty common in my projects to find a function consisting only of commented pseudocode when I had a good idea about implementing it but not enough time to do it properly (for example lunch break approaching or boring management meeting ahead).

Quote:

---

Originally Posted by Grell

Do you guys use pseudocode?

---

I program in Python. Does that count? ;)

Unless it's something quite trivial, yes - I use pseudo code extensively.

If I don't know how to code up a program, I start out just thinking about how I would do it, without a computer. If run time is of no particular concern, I'll do the task (or a simple version of the task), a few times until I'm confident of the pattern I want. I write that out, but it's too general and "human" to be really useful for coding, so I take that "write up" and break it down into pseudo code. From the pseudo code, I break it down into C code.

If run time is critical, I'm always looking for algorithmic speed up tricks that work so well with computers: divide and conqueror, sorting and binary searching (instead of just searching all the way through a large amount of data, over and over), indexing, hashing, bit tricks, counting sort, etc. People are generally efficient in how they work, but computers have some specific tricks that just are stunningly faster, if they can be applied to the program you're coding up.

Although I want my programs to run fast, I have learned that it's best to temper that with real clarity in the design of the program. Simple is not crude, it's elegant; removing the dross, and leaving the work of art so it can be seen and appreciated. Code that is not intuitively clear, better have a damn good reason for it's creation. Fortunately, simplicity tends to make fast programs, but more importantly, they are easy to modify, and keep bugs down to the absolute minimum, as well.

laserlight is right. Python is so light and fluffy, that there's little reason to write (something like a small algorithm in) pseudocode, when you can just tweak what your writing a little, and watch it run.
Most of the time I see pseudocode, it's to over-simply parts of the code that cannot be realistically simplified in reality, which to me, mostly defeats the point.

I personally like to use simple flow charts to help develop my logic. When I'm writing a function that I know takes 'x' input and is supposed to produce 'y' output, and the logic is fairly complicated, I'll draw out a flow chart - often several times before I find the most efficient implementation of logic that fits my needs. This also helps reduce code redundancy and excess variables.

I use flow charts only for sections of code that are complex or confusing. Quite often the code changes more than the flow chart and I hate spending more time updating the stupid chart than updating the code. I also use sequence diagrams for complicated sections or complicated logic but again balance is the key. If you spend more time updating the sequence diagram than actually producing code then what is the sequence diagram doing for you other than negatively impacting your schedule? You can document as you go through a project which is a good practice as long as you realize none of it will be picture perfect until the product is feature complete and/or done. You usually have to go back through your documents and update them at project completion unless you are lucky enough to have a documentation person on staff. I've never had such luck.

Most modern UML programs can reverse engineer your code into sequence diagrams and structure diagrams which is very nice and makes it simple to keep your documentation up to date.

If you are using Agile or Scrumm I highly recommend creating a task for updating documentation in each sprint. Don't allocate a ton of time or make it an epic task but allocate some time to it. If you do this then updating the documents at the end of the project will not take nearly as long. The super Scrummers would scoff at the idea of doing documentation since they believe it is the antithesis of Scrumm. However, we live in a real world and almost every company out there is going to require some form of documentation for their cool new project.

At the very least I always require structure diagrams to be created along the way. This is not an option and I feel it is very important and key to maintaining and implementing the original design and plan.

I do not use pseudocode that often and certainly do not require it. I feel it is a useful tool for devs to communicate to one another but does not belong in the final documentation for the product.

I only use pseudo-code when trying to explain an algorithm to someone else.