Arch Linux

Mandor

Member

Registered: 2006-06-06

Posts: 154

Re: programming tips

It may be a bit offtopic, but I find it somewhat relevant. It is also amusing:

http://www.ariel.com.au/jokes/The_Evolu … ammer.html

---

If everything else fails, read the manual.

Aganoth

Member

Registered: 2006-11-07

Posts: 5

Re: programming tips

From what I've picked up (And that hasn't been 'commented' on already...

Always use descriptive variable names.  Avoid abrevations and x.  It may take forever to type reallyLongVariableName, but it defiantly make more sence than rlvn.

This goes with the above, but I've found habits to be good (Good habits, that is).  A perfect example is a loop variable.  When you encounter that loops, don't use i or n.  I've always used loopX and loopY.  And whenever I make a loop, no matter how deep in I am, I know, loopX is the root nest, loopY follows, etc... 

And for god sakes man, use the whitespace!  I may be a little too OCD about it, but lining up your equals (=) signs make code 10 times easier to read.  Indention is superbly important, whatever your style may be.

And always strive for encapsulation perfection.

Finally, this goes without saying, but before you release any kind of program, turn on all your warnings (Except for those that you've already worked out to be compiler barking) and work them out.

---

Loose Lips do Sink Ships.

iphitus

Forum Fellow

From: Melbourne, Australia

Registered: 2004-10-09

Posts: 4,927

Re: programming tips

The greatest tip of all: learn how to "read code".  No, it's not as simple as knowing the syntax.  Code reading is very very difficult.

When I can give you something in a language you don't know, and you can tell me the section of code something happens in, you have it down.... hurry, find me the section in ejabberd that handles the iq protocol (without grep, fool!)

i must have missed this thread......

on top of reading code, printing it helps. I struggle to read all but the most basic code from the screen, but puttin it on paper, grabbing a pencil and annotating makes things a lot easier to understand.

maybe i learn more visually, but im a lot more confident working with a bit of code when i've gone through it quickly on paper and it helps give me a pretty solid idea of how the program works.

kate does a great job of printing code out, light syntax colouring and well formatted, clearly titled pages. vim apparently does a good job too.

also, dont hesitate to rewrite something, so long as you aren't trying to rewrite it and be really clever.

for example, I've almost completed the third generation of the python script i use to generate my website. The first version was just crap. I know one or two people here saw it, but were polite enough to not tell me that .
Second was slightly better and the third is much cleaner, and shares squat with the first. It's far easier to modify and extend, and unlike the first generation, it's fairly self explanatory and broken down a bit better.

A lot of work for a tiny little html generator, but it's a learning excercise - programming is a thing of continual learning - so getting it right is worth it, and I'll release it when I think I have got it right.

James

bboozzoo

Member

From: Poland

Registered: 2006-08-01

Posts: 125

Re: programming tips

1. Do produce at least something like design document for larger project. May it be a IM client, use some mind mapping tool, do some notes. It is fscking hard to get things right after some time and comments are no good at all. Just think of how much time you would save by reading the designa a browing through the code rather than readin the code and recreating the design.
2. Do not abuse operator overloading/inheritance. Seen thousands of lines of code where people overload any operator they can just for the sake of doing so + multiple inheritance everywhere. Then imagine project having literally several million LOC and try to fix something.
3. Use some code formatting standard. Something sane, not one the used in binutils
4. Use static for file local functions in C, no one likes symbol table pollution
5. Do not tag every possible method in C++ as virtual
6. Do not abuse exceptions...
7. Do comment the code:

...
if ((que->conf.flags & 0x03) != 0) {
...
}
...

is not verbose enough
8. Prefer POSIX calls to legacy interfaces, why use semget/semop when sem_* is available? why msgrcv/msgsend when mq_* is available?