Good programming practices - Pascal

ArchMan · 2010-06-04 23:05:06

In my county we have to learn pascal for the finals on the last year of high school. So I have an opportunity to sink my teeth to something I so wanted by haven't had the motivation. I would like to learn pascal and good programming practices by the end of summer and polish my skills on the year later on. I would like to learn ruby afterwards.

Having seen the first lecture from Stanford University I understood that it's easy to get bad practices on programming fairly easily. What book would you recommend to start with. I want to get the concept and understand the things behind and not learn the language superficially like most other students.

What are some tips? What will I need to develop on arch? and How do I achieve good practices from start to finish. I don't want to need to relearn so I can fix things I could have done right. Meaning how do I learn pascal the right way.

Ending, is my choice of going to ruby right? I don't like Python and I would like to learn C but maybe after Ruby. What about Perl? I heard the syntax is a bit unreadable after you write the code and that wouldn't be good for catching good practices.

What are some small projects - meaning really small - just to understand the concepts?

I am really motivated to go on like this and your suggestions will surely help both my motivation and also prevent some bad habits.

Last edited by ArchMan (2010-06-05 00:01:25)

lagagnon · 2010-06-04 23:08:41

I found this book to be an excellent way to learn good programming techniques: http://tinyurl.com/3ynqflv
I'll let others answer your other questions...

Trent · 2010-06-05 01:45:20

Good practices transcend languages and paradigms, and for the most part they have to be learned by experience. Working on a project with skilled programmers can accelerate the process, so I would advise you to share your code with a community (this one is good, but if you have any friends in RL who are programmers that works at least as well). The feedback and advice of real people will help to clarify in your mind what is good practice better than any book can tell you.

With that in mind, here are some things you should do: (1) use a consistent style (indentation and whatnot); (2) don't just comment -- document, systematically and consistently, and make sure you document parameters and return values of every function/subroutine/procedure as well as every global variable; (3) keep everything -- I mean everything -- under revision control; (4) be smart, not clever (by which I mean, clever solutions are often more troublesome to maintain than they are valuable -- keep it simple); (5) choose your sources carefully -- the Internet is an excellent source of bad advice; (6) read some real world code, not just academic examples; and (7) have fun!

Larry Wall wrote:

Real programmers can write assembly code in any language.

stqn · 2010-06-05 02:17:06

The first thing I thought of when reading your post is that, since you obviously care about writing good code, then you will write good code.

I can't really think of a lot of "bad habits" someone could have that would be hard to change.

Maybe copy-pasting is one of them. Copy-pasting is bad because each time you copy some block of code, you'll have one more block of code to modify when you find a bug in the original. It also means you might forget to change one or several of the copies, where the bug will not be fixed. And finally it makes the program bigger and less readable.

Making 1000-lines functions is also kinda bad. It's better if the whole function is readable on your screen and deals with only one precise thing. It makes it easier to understand what the function does, spot bugs, and modify it.

Don't write useless code. Just write what you need when you need it. If you need more later, then you'll write it later. Maybe you'll have to rewrite the original code, but that's ok because you'll probably write it faster and it will be better than the first time.

Also you should obviously check return values for errors (like after a memory allocation or opening a file).

I'm curious about this university lecture... any link?

SiC · 2010-06-05 09:59:09

Here are a few things I've learnt, some have been mentioned before, but are worth mentioning again.

1) Keep your coding style consistent, it doesn't matter what that style is, but keep it consistent - i.e. Always indent new code blocks in the same way. Always declare variable names in the same way - and make sure they are useful. A lot of books or academic examples often use the variable "i" as a loop variable, try counter instead, it means more. Also if you are nesting loops, be careful in naming, don't use counter1, counter2, make sure when you look at them in six months you will know what they mean without reading the code.

2) Try not to write functions more than 20-30 lines if possible, sometimes it's not possible to keep them that small, but try. If you are using loops, try to put the contents of the loop in a function, you can then test that function to death and know that the output will be correct.

3) Any code you repeat, even if only once, put in a function, the overhead of a function is small, the overhead of searching for every instance of a block of code when you make a change is high, and you are more likely to make a mistake.

4) Document, Document, Document. If you are writing something, document the inputs, outputs, processes etc. And I don't just mean in the code itself, get used to writing proper program documentation. At the end of every project you should have a reference document that contains details and design for all your functions, no matter how trivial, and how they fit together. Besides, it's also a good opportunity for you to learn LaTeX Documenting software is a skill, it's boring and tedious for programmers, but you need to learn it.

5) Test everything. When you write a function, consider all the possible inputs and outputs you could get from it. Don't just assume that everything going into it will be correct. Test bad input values against the function, and see what happens. It should never just crash or give an incorrect value, as this WILL cause problems, maybe not immediately, maybe not even in this project, but eventually you will.

6) If you are dealing with users NEVER assume anything. Validate and verify every input, check everything. Don't assume just because you know what it means, that someone else does too. Write user documentation for everything, even if it is only you who will be using it. It's a good skill to have, and it will help you crystalise in your own mind how things work.

7) Keep things simple. If you write something complex, take time breaking it down into simple tasks, simple is better. Don't try to be clever and use tricks, you will make mistakes, and then you won't remember why you did something, so you will try to fix it and then make more mistakes. If you can't understand code at a glance, it is too complicated.

8) Get some OLD books on C and Pascal. They were written when system constraints were higher, read them. Understand them. I remember when I learnt C I had to learn the difference between the different memory models available. They don't mean anything now, but they taught me more about how a computer system works, and understanding the how and the why is more important than knowing that something just works.

These are just a few off the top of my head. It won't help you write great code for the most part, but it will help you. It won't stop you making mistakes, but will help to minimise them.

Over time you will learn more, and will be able to appreciate when you can write more complex code, and when to ignore some of the advice you will be given here, but that is experience, and you need to get it first

Also, lastly, my advice to you would be to stick with Pascal for a while. Don't switch to Ruby after a short while. The reason is that you will learn more about programming and how to do it well by sticking with a single language for a while, and Pascal is a great language for learning. Switching programming languages frequently doesn't teach you much beyond how to do the same things in the different ways.

HTH

stqn · 2010-06-05 13:33:36

Oh and for a small project, you could rewrite wc, or write something to remove \r characters from text files...

Trent · 2010-06-05 14:53:09

SiC wrote:

1) Keep your coding style consistent, it doesn't matter what that style is, but keep it consistent - i.e. Always indent new code blocks in the same way. Always declare variable names in the same way - and make sure they are useful. A lot of books or academic examples often use the variable "i" as a loop variable, try counter instead, it means more. Also if you are nesting loops, be careful in naming, don't use counter1, counter2, make sure when you look at them in six months you will know what they mean without reading the code.

I mostly agree with you, but for two things: (1) it kind of does matter what style you use, especially if you ever seek peer review. Stick with a popular style like (for C) K&R, GNU, or Allman. If not, use a tool like GNU indent to format your code for review. (2) i is probably a good choice for a loop variable exactly because that's a typical name for a loop variable. Obviously if you can think of more descriptive names it's a good idea, but i,j,k are pretty standard and recognizable as loop controls. What you don't want to do is use i,j,k (or any single-variable name) for other purposes -- that's just confusing.

8) Get some OLD books on C and Pascal. They were written when system constraints were higher, read them. Understand them. I remember when I learnt C I had to learn the difference between the different memory models available. They don't mean anything now, but they taught me more about how a computer system works, and understanding the how and the why is more important than knowing that something just works.

Agreed that it's useful to know these things, because they help you debug and understand why languages are designed the way they are. But if you ever think you *need* to know this stuff in a higher level language, it's probably a good indication that you're going about it wrong. You should always code to the lowest common denominator. C was designed so that you could write programs that are independent of memory models and other "implementation details". Stick with what's guaranteed by the language standards.

Arch Linux

#1 2010-06-04 23:05:06

Good programming practices - Pascal

#2 2010-06-04 23:08:41

Re: Good programming practices - Pascal

#3 2010-06-05 01:45:20

Re: Good programming practices - Pascal

#4 2010-06-05 02:17:06

Re: Good programming practices - Pascal

#5 2010-06-05 09:59:09

Re: Good programming practices - Pascal

#6 2010-06-05 13:33:36

Re: Good programming practices - Pascal

#7 2010-06-05 14:53:09

Re: Good programming practices - Pascal

Board footer