Proper C Etiquette

[tengarp]

So I'm trying to teach myself C (to be able to program an Arduino) through various websites and I was just wondering if there is any proper coding etiquette involved with it. I was taught python in a class and there i learned to keep my code nice and organized, and to comment a lot so that the code s easier to read, but is there anything else I should know? Such as should i put " return 0 " at the end of every print statement or not? Any tips you could give me would be very much appreciated! Also if you have any website recommendations/youtube videos i should watch to learn C that would be nice too. Thanks!

 

[WanderingFool]

You know there is no real magic bullet for proper C Etiquette...although admittedly there are some rules that should be follow (but doesn't affect how the code runs).

The first is always return the main function...Personally I don't care that the specification allows for leaving the line out...it just makes sense to put in the return statement.

 

Having gone through many different processors who requires different code, there are many different mentalities behind writing and commenting in code.

 

In general this is the rules I follow:

Commenting:

• Put a comment at the top of each function, just as a quick description.  If it returns something, say what it returns...in the event of a pointer make a note whether the pointer needs to be freed.
• Comments inside a function should be used only to describe what is happening, if not obvious, or if you need to make note of something (e.g. if(((a<<b)>>a)+i++!=3534) isn't very obvious and shouldn't be done, but if you do comment)

Coding:

• Try making everything readable.  Nothing is worse than going back to your code to find variables named a b c d e f... when they could have been named index, maximum, minimum...etc.
• Try avoiding insanely long lines of code, you can break it down so that they are on different lines (and it won't affect the processing)
• This one is only my pet peeves, nested if statements...yes they can't always be avoided, but if you have code with 6 tabs to the current line there is something wrong   This is just a personal opinion though, built through a few processors who disliked them...with that said I have seen people who did this

  int main() {    ...    if(i < 5) {         ... //50 lines of code         if(z > 5) {             ...//50 more lines of code         }         else {             return 2;         }    }    else {        return 1;     }   return 0;}//The more reasonable approach (in my mind)int main() {    ...    if(i >= 5)        return 1;    ...//50 lines of code    if(z <= 5)        return 1;    ..//50 lines of code    return 0;}

• For myself, I enjoy ) { but, there are many people who prefer ) \n { which is alright

Macros (#define):

• This is a tricky one, but don't touch function macros until you have learned the language fully (there are way to many errors)
• In general though macros can be good when you need to re-write multiple lines of code that repeat itself, expect with a few name changes
• If you plan to work in a group, don't use function macros
• When learning, use macros for constants like #define PI 3.1414... or for header guards.

[tengarp]

 

You know there is no real magic bullet for proper C Etiquette...although admittedly there are some rules that should be follow (but doesn't affect how the code runs).

The first is always return the main function...Personally I don't care that the specification allows for leaving the line out...it just makes sense to put in the return statement.

 

Having gone through many different processors who requires different code, there are many different mentalities behind writing and commenting in code.

 

In general this is the rules I follow:

Commenting:

• Put a comment at the top of each function, just as a quick description.  If it returns something, say what it returns...in the event of a pointer make a note whether the pointer needs to be freed.
• Comments inside a function should be used only to describe what is happening, if not obvious, or if you need to make note of something (e.g. if(((a<< B)>>a)+i++!=3534) isn't very obvious and shouldn't be done, but if you do comment)

Coding:

• Try making everything readable.  Nothing is worse than going back to your code to find variables named a b c d e f... when they could have been named index, maximum, minimum...etc.
• Try avoiding insanely long lines of code, you can break it down so that they are on different lines (and it won't affect the processing)
• This one is only my pet peeves, nested if statements...yes they can't always be avoided, but if you have code with 6 tabs to the current line there is something wrong   This is just a personal opinion though, built through a few processors who disliked them...with that said I have seen people who did this

  int main() {    ...    if(i < 5) {         ... //50 lines of code         if(z > 5) {             ...//50 more lines of code         }         else {             return 2;         }    }    else {        return 1;     }   return 0;}//The more reasonable approach (in my mind)int main() {    ...    if(i >= 5)        return 1;    ...//50 lines of code    if(z <= 5)        return 1;    ..//50 lines of code    return 0;}

• For myself, I enjoy ) { but, there are many people who prefer ) \n { which is alright

Macros (#define):

• This is a tricky one, but don't touch function macros until you have learned the language fully (there are way to many errors)
• In general though macros can be good when you need to re-write multiple lines of code that repeat itself, expect with a few name changes
• If you plan to work in a group, don't use function macros
• When learning, use macros for constants like #define PI 3.1414... or for header guards.

 

Okay, thankyou for your response!

[WorldDominator]

Learn pointers and learn them well. I'm still confused with them. Bad teacher is bad 

[manon_gfx]

Learn pointers and learn them well. I'm still confused with them. Bad teacher is bad 

 

My teacher just let us watch this: https://www.youtube.com/watch?v=6pmWojisM_E

Now I perfectly understand how pointers work

[WorldDominator]

My teacher just let us watch this: https://www.youtube.com/watch?v=6pmWojisM_E

Now I perfectly understand how pointers work

Oh my lord I actually watched this lol. I get confused when I should use * or &

[fizzlesticks]

My teacher just let us watch this: https://www.youtube.com/watch?v=6pmWojisM_E

Now I perfectly understand how pointers work

Wow, that was a long way to go just to draw a penis.

[alpenwasser]

Oh my lord I actually watched this lol. I get confused when I should use * or &

To me the ampersand looks a bit like a capital A:

& A

Therefore & stands for &ddress. Principle of exclusion then gets me to the

meaning of *. Haven't confused the two since I came up with this.

[WanderingFool]

My teacher just let us watch this: https://www.youtube.com/watch?v=6pmWojisM_E

Now I perfectly understand how pointers work

haha, that is such an odd video...effective but odd.

The unfortunate thing is they didn't get into functors/function pointers...got to tell you, it scared me when I first saw something like this "double (*funcp)(double, double (*funcptwo)(double))"

[alpenwasser]

haha, that is such an odd video...effective but odd.

The unfortunate thing is they didn't get into functors/function pointers...got to tell you, it scared me when I first saw something like this "double (*funcp)(double, double (*funcptwo)(double))"

The potential power they have is pretty mighty as far as I'm aware (without being

an uber-C guru myself TBH), but the potential for creating undecipherable unholy

messes seems almost equally great. :lol:

Then again, pointers seem to have that capability in general, regardless of how

awesome (at least IMHO) the concept itself is.