New C programmer, criticism

korkadapa · 2011-12-30 17:18:19

Hi! I've been learning C lately. I've been doing some programming in Python before, but C is fairly new to me. I've written a small "Todo manager", https://github.com/stritfajt/Todo, and while it works just fine, I'm afraid that I've made some stupid mistakes that would lead me into bad habits later on.

I'm also thinking about how I would go about implementing a function to delete a todo. Is there a simple way to delete a line of a file in C? Or will I have to read the file in to a string and then write the desired lines to a temporary file wich I later move to the correct location? Is there anything wrong with that approach?

Please excuse my language, I'm not a native English speaker.

Simon.

ewaller · 2011-12-30 17:28:46

Well...

I would not hard code the file names.
You perform no error checking when performing file operations.
You use the file pointers without having checked that they are valid.
Instead of long if..then..else structures, I prefer to build tables driven logic.

gbrunoro · 2011-12-30 18:13:03

Hi korkadapa,

I'll add up two things to ewaller remarks:
1) I wouldn't use "r+" mode for files in this case, you'd be better off with a temp file. Using read-write mode can bring some serious trouble.
2) Try to follow some style guidelines, as the column 80 rule. You can read some open source code (for instance the kernel) to get an idea what real life C looks like.

/dev/zero · 2011-12-30 21:21:20

I wouldn't hard code the magic number "100".
I would use more comments.
I would consider using lex/yacc to parse the input. Also, if you used a config file to avoid hard coding the file names, you could use lex/yacc to parse that too.

korkadapa · 2011-12-30 22:36:58

ewaller wrote:

Well...
I would not hard code the file names.
You perform no error checking when performing file operations.
You use the file pointers without having checked that they are valid.
Instead of long if..then..else structures, I prefer to build tables driven logic.

I've declared the path with an #define line now, that seems nicer. In the future I might add a config file.

As for the error checking, should I just check the return value of fopen, fgets and fputc? Or where you thinking of anything else?

Could you elaborate on the tables driven logic? I don't think I understand what you mean there, any examples?

gbrunoro wrote:

Hi korkadapa,
I'll add up two things to ewaller remarks:
1) I wouldn't use "r+" mode for files in this case, you'd be better off with a temp file. Using read-write mode can bring some serious trouble.
2) Try to follow some style guidelines, as the column 80 rule. You can read some open source code (for instance the kernel) to get an idea what real life C looks like.

I can't see why, but I'll trust you regarding the r+ mode!

I read about the column 80 rule and added some stuff in my .vimrc so help me follow it. Any more style guidelines that I should follow?

/dev/zero wrote:

I wouldn't hard code the magic number "100".
I would use more comments.
I would consider using lex/yacc to parse the input. Also, if you used a config file to avoid hard coding the file names, you could use lex/yacc to parse that too.

How do you do it without hardcoding the array size then? With a file I would have read it twice and counted the size the first time, but I can't think of a way to do that with an input...

lex/yacc seems great, I will have to learn that sometime!

/dev/zero · 2011-12-31 00:05:14

korkadapa wrote:

How do you do it without hardcoding the array size then? With a file I would have read it twice and counted the size the first time, but I can't think of a way to do that with an input...

Well, at the very least, hash-define it so you don't get the magic number 100 scattered all through your code. This way, if you want to change it later, you only have to change one thing. It will also make your code easier to understand, if people see "INPUT_LENGTH" everywhere instead of this mysterious number 100.

Anyway, as I understand it, it's considered better practice to use getline rather than fgets. It uses realloc if it turns out that your chosen number is too small.

Edit: Short tutorial on getline.

Last edited by /dev/zero (2011-12-31 00:08:07)

gbrunoro · 2012-01-01 16:56:48

korkadapa wrote:

I can't see why, but I'll trust you regarding the r+ mode!

It's just a way to have it clear in your code the purpose of the file, so you can have bettercaching, multi-process access, etc. And it is also more organized

korkadapa wrote:

I read about the column 80 rule and added some stuff in my .vimrc so help me follow it. Any more style guidelines that I should follow?

There are some code styles that I can point you, so you can make up your mind about which one you like best:

GNU coding guidelines: http://www.gnu.org/prep/standards/
Python style guide for C code: http://www.python.org/dev/peps/pep-0007/
Google C++ style guidelines: http://google-styleguide.googlecode.com … pguide.xml (not exactly C, but it's nice)

korkadapa · 2012-01-01 20:10:56

gbrunoro wrote:

There are some code styles that I can point you, so you can make up your mind about which one you like best:
GNU coding guidelines: http://www.gnu.org/prep/standards/
Python style guide for C code: http://www.python.org/dev/peps/pep-0007/
Google C++ style guidelines: http://google-styleguide.googlecode.com … pguide.xml (not exactly C, but it's nice)

NIce, I'll read up! Can anyone explain why the people folks recomend 4 spaces instead of a tab though? That seems so impractical in so many ways...

Anthony Bentley · 2012-01-01 22:57:35

korkadapa wrote:

gbrunoro wrote:
There are some code styles that I can point you, so you can make up your mind about which one you like best:
GNU coding guidelines: http://www.gnu.org/prep/standards/
Python style guide for C code: http://www.python.org/dev/peps/pep-0007/
Google C++ style guidelines: http://google-styleguide.googlecode.com … pguide.xml (not exactly C, but it's nice)
NIce, I'll read up! Can anyone explain why the people folks recomend 4 spaces instead of a tab though? That seems so impractical in so many ways...

Generally, because the width of a tab can be user‐defined. Using spaces forces a specific width. Of course, some people (like me) disagree, and say indentation should be done with tabs.

My personal favorite coding style is the Kernel Normal Form used by the BSDs, based on the K&R style of The C Programming Language. As for the GNU style, well, I’ll quote Linus:

First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.

Arch Linux

#1 2011-12-30 17:18:19

New C programmer, criticism

#2 2011-12-30 17:28:46

Re: New C programmer, criticism

#3 2011-12-30 18:13:03

Re: New C programmer, criticism

#4 2011-12-30 21:21:20

Re: New C programmer, criticism

#5 2011-12-30 22:36:58

Re: New C programmer, criticism

#6 2011-12-31 00:05:14

Re: New C programmer, criticism

#7 2012-01-01 16:56:48

Re: New C programmer, criticism

#8 2012-01-01 20:10:56

Re: New C programmer, criticism

#9 2012-01-01 22:57:35

Re: New C programmer, criticism

Board footer