programming tips

user · 2006-08-17 22:16:58

Hi,

let us know about your found.

TIA(that's all)

T-Dawg · 2006-08-17 22:29:44

my biggest tip would be to write several small and rather generic functions that you can later call on in your main(). Think of them as building blocks that you can use and reuse over and over again. Its a little hard to build a castle out of a house.

user · 2006-08-17 22:34:25

Penguin wrote:

Its a little hard to build a castle out of a house.

It will well fit in gedit's code snippets plugin.
http://live.gnome.org/Gedit/SnippetPlugin

pauldonnelly · 2006-08-18 08:46:36

Write small functions like Penguin says, then test them thoroughly before you use them together. With luck, you can catch bugs before they find a place to hide.

Dusty · 2006-08-18 09:50:15

Comment profusely.

Unit test.

Design for a) extensibility and b) maintainability.

Dusty

arooaroo · 2006-08-18 11:16:25

Dusty wrote:

Unit test.
Design for a) extensibility and b) maintainability.
Dusty

Using an OO language makes this much simpler, IMHO.

I wouldn't "Comment profusely." I've marked undergrad programming exercises where commenting was necessary. However, some people went overboard and it just made the code unreadable.

I would comment "where necessary", especially where you've just coded something that you think is "cool", because it probably means you've just done something new and fancy that won't make sense to you or any one else later on.

cactus · 2006-08-18 15:18:41

arooaroo wrote:

However, some people went overboard and it just made the code unreadable.

# The following call will wash your dog,
# fetch your morning paper, make you coffee,
# and do everything you ever wanted to do...
# if that involves adding two numbers that is,
# because that is what happens here. We add two numbers
# wewt! Shout out to arooaroo, phrakture, and monkeys.
a = add(1,2)

# a should be 3 now! zomg!

i would have to say though, that I prefer more commenting, then no commenting, but I agree.... a happy medium should be struck. I think poeple generalize and say 'do more commenting', because it is often held that most people do too little.

Dusty · 2006-08-18 15:30:38

arooaroo wrote:

Using an OO language makes this much simpler, IMHO.

That's pretty much a given nowadays, although I'm on the "object oriented is useful sometimes, but shouldn't be required all the time" team.

I wouldn't "Comment profusely." I've marked undergrad programming exercises where commenting was necessary. However, some people went overboard and it just made the code unreadable.

Yeah, same here -- I actually took marks off one assignment for over-commenting just this week. By "profusely", I mean, a hell of a lot more than most people do, or at least than most grad students do. Or than most kernel developers do. I'd say a good threshold is "1/3 to 1/2 of the total lines of code should be comment lines". 1/3 for Python, 1/2 for Java.... ;-) I'm guessing you will argue that is a bit much, but I don't mean commenting each line, I mean having a GOOD description of every class, method, and function. Something pydoc or javadoc or doxygen will find useful.

Having said that, I actually think having inline comments that are not at the method or function level is an indication that the method is getting too big and complex and should be divided in half.

I would comment "where necessary", especially where you've just coded something that you think is "cool", because it probably means you've just done something new and fancy that won't make sense to you or any one else later on.

Everything I write is cool. ;-) (I always find some python module or another that has done the boring stuff already.)

one and a half more tips:
Spend more time refactoring than coding.

Focus on elegant code.

Dusty

phrakture · 2006-08-18 15:40:07

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!)

soloport · 2006-08-18 16:27:07

Tip (call this the "poor man's goto"):

do {
    if (do_something() == SOME_RUDE_ERROR) break;

    ok_cool_we_survived_that();
    if (do_something_more_crazy() == SOME_ERROR) break;

    do_some_final_thing();
} while (FALSE);

If you compile this and examine the Assembly code, you will find nothing but branch statements -- equivalent to goto statements. The compiler intelligently throws out the pointless 'while (FALSE);' conditional.

phrakture · 2006-08-18 16:50:28

soloport wrote:

while (FALSE);

Programming tip #2: C99 is your friend 8)

while(false);

Kopsis · 2006-08-18 17:04:33

arooaroo wrote:

Dusty wrote:
Unit test.
Design for a) extensibility and b) maintainability.
Dusty
Using an OO language makes this much simpler, IMHO.

There are certain classes of problems that lend themselves nicely to OO but there are plenty of others where OO actually complicates the design. In some cases, designing for a functional language can produce vastly superior results. In other cases good old fashioned low-level bit bashing is the cleanest solution.

The real key is understanding all these different design techniques so you can find the right match for the problem at hand. Learn as many languages and as many design techniques as you possibly can. Then chose a design that fits the problem and a language that fits the design and you maximize your chances of ending up with nice clean elegant code.

And remember that different parts of the problem may lend themselves to completely different design techniques. An OO GUI framework bound to a dynamic scripting language using functional programming for algorithm designs and a collection of libraries providing low-level implementations of hardware specific or speed critical primitive functions may be the right solution. Don't be afraid to mix and match different languages in a single application. C, C++, and Java programmers seem most likely to suffer the one language fits all afliction.

phrakture · 2006-08-18 17:28:31

Quoted for truth!

Kopsis wrote:

There are certain classes of problems that lend themselves nicely to OO but there are plenty of others where OO actually complicates the design. In some cases, designing for a functional language can produce vastly superior results. In other cases good old fashioned low-level bit bashing is the cleanest solution.
The real key is understanding all these different design techniques so you can find the right match for the problem at hand. Learn as many languages and as many design techniques as you possibly can. Then chose a design that fits the problem and a language that fits the design and you maximize your chances of ending up with nice clean elegant code.
And remember that different parts of the problem may lend themselves to completely different design techniques. An OO GUI framework bound to a dynamic scripting language using functional programming for algorithm designs and a collection of libraries providing low-level implementations of hardware specific or speed critical primitive functions may be the right solution. Don't be afraid to mix and match different languages in a single application. C, C++, and Java programmers seem most likely to suffer the one language fits all afliction.

soloport · 2006-08-18 18:06:40

Tip: When you're stuck, grab the janitor.

I found that explaining a problem is usually the key to solving it. Ever post a question to a list only to find the solution yourself before anyone has a chance to reply? Me too, and far too often. Feels like you're wasting people's time when that happens. But it works!

In fact, years ago I discovered anyone, technical or not, will do. Explain a problem to someone and even though the subject may be unfamiliar to them (even way over their head) the result is the same. Mid sentence, "Oh! That's it!".

Late at night, on those long code marathons, the janitors would learn to empty my trash last... or not at all. :evil:
.

Dusty · 2006-08-18 20:32:59

phrakture wrote:

Quoted for truth!
Kopsis wrote:
<but>

Very well said, friend Kopsis!

tranquility · 2006-08-18 21:52:45

Dusty wrote:

Comment profusely.

Code in such a way that comments are not necessary.

arooaroo · 2006-08-18 21:58:01

tranquility wrote:

Dusty wrote:
Comment profusely.
Code in such a way that comments are not necessary.

That's just simply not possible for 100% of the time, and besides, it's all relative. An experienced programmer may believe they are writing the most lucid code ever witnessed by mankind, yet a less experienced programmer may have difficulty comprehending.

syd · 2006-08-18 22:02:04

tranquility wrote:

Dusty wrote:
Comment profusely.
Code in such a way that comments are not necessary.

Use Python .

tranquility · 2006-08-18 22:35:00

arooaroo wrote:

tranquility wrote:
Dusty wrote:
Comment profusely.
Code in such a way that comments are not necessary.
That's just simply not possible for 100% of the time, and besides, it's all relative. An experienced programmer may believe they are writing the most lucid code ever witnessed by mankind, yet a less experienced programmer may have difficulty comprehending.

I understand what you're saying, but there are several ways to accomplish something. Granted, sometimes it has to be hard to get and ugly, but one should always opt, when possible, for the simplest and cleanest sollution without all that 1337 kung-fu that you might find. Several times, upon re-reading my code that I haven't worked on for a while, I find myself trying to understand something with some degree of effort because it isn't well thought and well planned

phrakture · 2006-08-19 06:02:57

tranquility wrote:

I understand what you're saying, but there are several ways to accomplish something. Granted, sometimes it has to be hard to get and ugly, but one should always opt, when possible, for the simplest and cleanest sollution without all that 1337 kung-fu that you might find. Several times, upon re-reading my code that I haven't worked on for a while, I find myself trying to understand something with some degree of effort because it isn't well thought and well planned

Self-documenting code is an urban legend. Regardless of how simplistic your code is, there is *always* a need to comment.

Take this for instance:

int rgLevel = 17;

what? I see no kung-fu, but I do not know what "rgLevel" means, and why 17 is significant as an initialization value.

How about a real example (using Windows Media Encoder in C#, as I just did this like 5 hours ago):

WMEncoder encoder = new WMEncoder();
encoder.PrepareEncoding(false);
encoder.File.LocalFileName = "C:foo.wmv";
encoder.Start();

Sure this is clean and neat and makes perfect sense, but look at the PrepareEncoding call.... why does it take a "false" parameter. What does that do? For anyone who's read the docs, why is it explicitly called when Start() calls PrepareEncoding(true) anyway?

Anyone who claims "self-documenting" code can truely exists needs to show me an example...

pauldonnelly · 2006-08-19 09:26:42

The only real rule for commenting is "Explain what needs it." That's pretty vague, and requires good judgement. I like to think what would be necessary to explain what the program is doing in a general way as long as it doesn't duplicate the code's exact meaning. For example, this code from one of my projects doesn't need any explanation. Anything I write would be almost exactly the same.

void init_all () {
  init_ncurses();
  init_openal();
  init_vals();
}

On the other hand, these #defines would be meaningless without the attached note.

// directions the player can travel in, for storing the same
#define PLAYER_U 0
#define PLAYER_R 1
#define PLAYER_D 2
#define PLAYER_L 3
#define PLAYER_S 4 // standing still

In general, if you can make a statement more meaningful with a comment, add that comment, but leave out anything completely obvious. Don't make a comment saying "add foo to bar" (for "bar += foo"), say why you do it.

Also, never mention variable names in a comment unless you're explaining what that name means, because then you have to update the comment too when it changes. And you *will* forget to do that, meaning that eventually you can't trust your comments and have to audit them all. Being more specific than you have to be is a bigger pain than being vague.

Dusty · 2006-08-19 09:40:18

phrakture wrote:

but look at the PrepareEncoding call.... why does it take a "false" parameter. What does that do?

Don't mean to get nit-picky here, since I agree with you, but... I don't know what this call does, but good self-documenting code wouldn't have that value there; its the equivalent of a magic number. It would be replaced with a constant defined somewhere else in a file, and the name of this constant should lend some information about the vaule and purpose of the call.

Bison · 2006-08-21 19:24:17

Write tiny abstract methods. When I use common lisp, I always try to keep my functions as close to one line as possible.

Always start with low-level functions, and then build higher-level functions that implement the lower-level functions, and so on.

And as everyone else is saying: write good comments.

JulesJacobs · 2006-08-22 10:22:11

phrakture wrote:

How about a real example (using Windows Media Encoder in C#, as I just did this like 5 hours ago):
WMEncoder encoder = new WMEncoder();
encoder.PrepareEncoding(false);
encoder.File.LocalFileName = "C:foo.wmv";
encoder.Start();
Sure this is clean and neat and makes perfect sense, but look at the PrepareEncoding call.... why does it take a "false" parameter. What does that do? For anyone who's read the docs, why is it explicitly called when Start() calls PrepareEncoding(true) anyway?
Anyone who claims "self-documenting" code can truely exists needs to show me an example...

You can't write self-documenting code if you use a bad library.

Self documenting code can exist but you'll need to use descriptive names, the right level of abstraction and some comments to explain clever algoritms.

For example:

function make_rational(numerator, denominator){
  divisor = gcd(numerator, denominator);
  return [numerator / divisor, denominator / divisor];
}

function numerator(rational){
  return rational[0];
}

function denominator(rational){
  return rational[1];
}

Is this code self-documenting, or should you add a comment "reduce to lowest terms":

function make_rational(numerator, denominator){
  // reduce to lowest terms
  divisor = gcd(numerator, denominator);
  return [numerator / divisor, denominator / divisor];
}

You also need the right level of abstraction: we don't need to know how gcd() is implemented.

function gcd(a,b){
  if(b == 0){
    return a;
  }else{
    return gcd(b, a % b);
  }
}

This code needs a comment if you want to understand how it works, but if you just believe that it computers the greatest common divisor it's ok.

phrakture · 2006-08-23 15:23:00

JulesJacobs wrote:

You can't write self-documenting code if you use a bad library.

And you have stumbled upon the point. Dusty almost got it too, but you hit it on the nose. Many many times you _must_ use a "bad library". Now, I am not saying "omg this library sucks", I am saying that the library may be the greatest thing since sliced bread, just not up to the individual programmer's "high standadards" - it's al subjective.

Take a look at ffmpeg's libavcodec - it has to be, hands down, the de-facto a/v codec library. Problem is, the public interface sucks. That's my opinion. The point is, if you want to write "100% self documenting code", you either need to rewrite libavcodec before you do so, or use it and add a few comments.

Everyone has different standards, everyone has different styles. Hell, everyone uses different verbs (or nouns, if you're a java fan) and abbreviations. The point is, code that is self-documenting to _YOU_ will never ever ever ever ever be self-documenting as a whole.

Don't ever assume everyone thinks like you. Add comments. Assume people looking at your code are the biggest idiots ever and explain everything even quasi-complex. It helps, believe me.

Case in point:

JulesJacobs wrote:

Is this code self-documenting, or should you add a comment "reduce to lowest terms"

Lets assume I know nothing about math. Pretend I took "business math" in school and barely know how to "do fractions" (I know people like this). Your code is now officially the farthest thing from "self documenting" - it actually requires me to go and find *MORE* documentation about a topic I don't understand.

Arch Linux

#1 2006-08-17 22:16:58

programming tips

#2 2006-08-17 22:29:44

Re: programming tips

#3 2006-08-17 22:34:25

Re: programming tips

#4 2006-08-18 08:46:36

Re: programming tips

#5 2006-08-18 09:50:15

Re: programming tips

#6 2006-08-18 11:16:25

Re: programming tips

#7 2006-08-18 15:18:41

Re: programming tips

#8 2006-08-18 15:30:38

Re: programming tips

#9 2006-08-18 15:40:07

Re: programming tips

#10 2006-08-18 16:27:07

Re: programming tips

#11 2006-08-18 16:50:28

Re: programming tips

#12 2006-08-18 17:04:33

Re: programming tips

#13 2006-08-18 17:28:31

Re: programming tips

#14 2006-08-18 18:06:40

Re: programming tips

#15 2006-08-18 20:32:59

Re: programming tips

#16 2006-08-18 21:52:45

Re: programming tips

#17 2006-08-18 21:58:01

Re: programming tips

#18 2006-08-18 22:02:04

Re: programming tips

#19 2006-08-18 22:35:00

Re: programming tips

#20 2006-08-19 06:02:57

Re: programming tips

#21 2006-08-19 09:26:42

Re: programming tips

#22 2006-08-19 09:40:18

Re: programming tips

#23 2006-08-21 19:24:17

Re: programming tips

#24 2006-08-22 10:22:11

Re: programming tips

#25 2006-08-23 15:23:00

Re: programming tips

Board footer