LinuxQuestions.org - how to write code with the better quality

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - how to write code with the better quality (https://www.linuxquestions.org/questions/programming-9/how-to-write-code-with-the-better-quality-377194/)

lordofring

10-26-2005 03:55 PM

how to write code with the better quality

I'm a linux C/C++ programmer. I feel my code's quality is not good. I like to improve it. I work hard on it. I double check the code after I finish and I do some testing on the code.

What do you guys do for the quality purpose? Is there any other thing I can do to get bug less code?

gabebster

10-26-2005 10:49 PM

I would be extremely impressed if someone can write perfect bug less code all of the time. This what I like to do when I am debugging and testing my code. I like to print a hard copy of my code and I just read through it and go step by step of what it is supposed to do in my head, you would be surprise how much stuff you can catch just by reading through it. I'll write changes on the paper and then go make the changes. Use case structures instead of elseif as much as you can. When I am about done with a program or if I get stuck on something I show my code to other people(that I consider good programmers) and get input from them. In some cases I will just start over with a class or the whole program(only if I have been really messy).

primo

10-27-2005 01:24 AM

There's an art to it when it becomes intuitive. There are sources in the net that document specific issues, but the most obvious ones are checking error codes and the less obvious are integer overflows like this:

Code:

char *strndup(const char *str, size_t n)

{

    size_t len;

    char *s;



    if (str == NULL)

        return NULL;



    len = strlen(str);

    if (n > len)

        n = len;



    if (n > n+1) {

        errno = EOVERFLOW;

        return NULL;

    }



    s = (char *) malloc(n+1);

    if (s == NULL) {

        errno = ENOMEM;

        return NULL;

    }



    memcpy(s, str, n);

    s[n] = '\0';



    return s;

}

There's a bug in the following piece of code when len equals zero:

Code:

    fgets(str, 256, stdin);

    len = strlen(str);

    if (str[len-1] == '\n')

        str[len-1] = '\0';

len - 1 would be ULONG_MAX or a negative value whether it is size_t or int

alagenchev

10-27-2005 02:18 PM

Lord of ring, as gabebster suggested the best way to learn how to program good is doing code revisions with a buddy of yours. Just don't get frustrated when someone finds your bugs. Also make sure you test your code, test it with different inputs. Test your boundary cases and what you may consider weak spots, like what primo showed. The rest just comes with practice.

rsheridan6

10-27-2005 02:30 PM

There's no magic to it. Just write a lot of code, and read a lot of code written by good coders, which is easy to do with all the open source projects out there.

nx5000

10-28-2005 07:29 AM

Hi,
you can have a look at /usr/src/linux/Documentation/CodingStyle. This is for kernel code but some rules still apply. It's very good to read this, to my mind.

for c++ , you can have a look at this:
http://www.chris-lott.org/resources/...gStandard.html

There are some free tools that can automate check the code against a coding standard, I don't remember them.
Here's one:
http://pst.web.cern.ch/PST/HandBookW...bTutorial.html

And as noted by someone else, its very important to define errorcodes and catching methods.
When you have a problem, you know whats happening!! Rule number 1!

lordofring

10-28-2005 08:16 AM

Thanks everyone for the great suggestions. Here is what I'm going to do
1) write down the design on the paper before typing the code.
2) double check the code after it finish. (printing and reading, ask senior people to check ...)
3) read more materials and try some tools
4) The most important one: write and read more code

Thanks again. And I like to hear more about this topic.

Ygrex

10-28-2005 05:07 PM

I do not like to read documentation very much:)
The only file I read on this topic is codingstyle.
I found it is useful indeed. It contains a great
thing, never change a length of the tabchar. It is
8 spaces by default and there is no need to modify
it. Also I follow some rules else from it.

Secondly, I surprised that noone mentioned the
great program for debuging - valgrind. I found so
many bugs with it! It is really what any programmer
should use for one's programm. The most undesired
bugs concern memory allocation (and incorrect
freeing). They are most difficult to find. But
valgrind helps in this case too! It is really great
utility!

alagenchev

10-28-2005 05:59 PM

When it comes to segmentation fault errors, I have found that simple cout or printf statements, that output the values of the variables in question work the best. Once you are certain that a certain variable works correctly go on to next one. This combined with commenting out blocks of code is the best technique that I have found. Works flawlessly in any language, C/C++ assembly, etc. After some experience you will notice that there are 4 main points where you will get seg fault: Allocating space in a sub function and addressing in another/main(). not allocating space correctly, accesssing space that you are not supposed to access(going out of the boundaries). And also writing something in the effect of scanf("%d",x); rather than scanf("%d",&x); which still goes to writing to a space you're not supposed to.

rsheridan6

10-28-2005 08:26 PM

Not to say that printf + commenting blocks of code isn't useful, but often Valgrind can tell you exactly where your memory allocation error is in the time it takes to reproduce the segfault. That can save you serious time. Also, particularly nasty memory management bugs happen seemingly at random (until you figure out what's going on) and they're hard to reproduce. If you just run your program under Valgrind, you can get valuable information when it does happen.

eddiebaby1023

10-29-2005 03:22 PM

The one issue with using printf() to locate SEGVs is that the inclusion of the debugging statements often make the reason for the SEGV move elsewhere and possibly not manifest itself at all.

alagenchev

10-29-2005 05:22 PM

I am not saying it's an easy method to use, and true it may move sometimes, but it will not disapppear. If you practice this method and you master it, you will be able to program on any machine using any tool. This can help you learn more about programming, and it is a tremendoes help on programming competitions where you do not have any other tools available. I recommend this method to anyone who is new to programming, this way they will lwarn more about the flow of programs and the way computers work. I think it is one of the basics, you need to learn it before you go into using tools to do the job for you. But yeah I do agree with the points you guys made, I don't deny it.

rsheridan6

10-29-2005 09:36 PM

Yeah, you've definitely got to have a thorough understanding of memory management if you're going to use C or C++, and going straight to tools like Valgrind may not be helpful for a newbie if they try to rely on it instead of really understanding what they're doing. And if you look at this board, it seems that every third question is about a segfault, so obviously lots of people don't understand it (maybe they should consider using a GCed language).

But I think the best way to master this is to learn at least the basics of assembly, really learn what the stack and heap are, write some simple programs and compile them with gcc -S (with C, because C++ assembly output is too complex), and examine the compiled output. At least that's what it took for me to get it, and to stop writing programs that segfaulted all the time.

Ygrex

10-30-2005 01:48 AM

No, I do not think "lots of people don't understand it".
It is not very difficult itself. The real problem is to
write programs free of this damned bug. It is far more
hard than simply concieve this memory process.

And also I do not think there is any contrary between
Valgrind and breakpoints with fprintf. I often use them
together. Firstly Valgrind shows me where problem is, in
which function, but further investigating (if this bug
does not concerns stupid mind-absent and I see it
immediately) I implement thru breakpoints.

All times are GMT -5. The time now is 10:45 PM.