Constant, Variable, Function, ect - Formatting and Naming Conventions

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Newbie.  While I'm learning how to actually make the AVR dance, I also want to learn the best housekeeping practices in the process.  Regarding Constant, Variable, Function, ect - Formatting and Naming Conventions, I found this:

http://en.wikipedia.org/wiki/Nam...

 

They don't provide much of a description for C.  But, the table for Java looks interesting.  Paraphrasing:

- Variables: lowerCamelCase
- Constants: CAPS_SEPARATED_BY_UNDERSCORE
- Methods: lowerCamelCase()
- Classes: class UpperCamelCase

 

Is this typical for C also?  I don't quite understand the Classes, as after a class, it would typically be a variable or something, right?

 

Thoughts?  Other Formatting standards?  Naming convention standards?  Anything else good for the cause you can think of?  Thanks!

Last Edited: Wed. Jan 14, 2015 - 08:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this typical for C also?

I would say that it is common in C rather that typical. There are many conventions. Which one you use is up to you. The most important things is that you stick to whatever convention you think suits you.

I don't quite understand the Classes, as after a class, it would typically be a variable or something, right?

They are referring to the class definition, not the declaration of an instance of a class:

class Foo
{
    ...
};

Foo instanceOfFoo;

 

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are many conventions. Which one you use is up to you.

+1

 

I'd just read some other people's project code and see which you personally find "more readable" and then adopt the style they use. Maybe mix it up a bit "some of that over there and a bit of this here". In you original post you said:

- Constants: CAPS_SEPARATED_BY_UNDERSCORE

I'm not sure I (personally) would agree with that. I think it's almost universal that caps separated by underscore would usually highlight preprocessor macro names. Things like PORTB, ISR(), PORTB_DIR and so on. When you read those names you instinctively expect to find them in a #define somewhere.

 

I've been following (pretty much) the same coding standard for C for about 15 years but while it dictates symbol names separated by underscores I now work in an environment where camel case is used instead but when I start to type symbol names I instinctively type undersored names then realise I need to change - it's a hard habit to drop.

 

One of the key things about coding standards is that in a team of programmers it's fairly important for everyone to try and adhere to the same standard so Tom's code looks/reads just like Jerry's code. It makes code maintenance easier as you can instantly pick up code someone else wrote and see the structure of the implementation.

 

But if you are working alone pick what suits you and you personally find easiest to read so when you come back to your own code in 18 months you can instantly recognize what's going on.

 

(when I do use someone else's code in a different coding standard I often start by editing it to match what I know -  which makes it easier for me to then read what's going on. I might not go as far as editing symbol names but I'd certainly use the same vertical and horizontal layout that I prefer. It helps you to see the wood from the trees!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EDIT talk about coincidence. After writing this earlier today I have since been learning about Google's "protobufs" (a bit like a meta language for defining structs in a universal format from which C++ code can then be auto-generated). In reading about it I came across this:

 

https://developers.google.com/pr...

 

That's quite an interesting concept - they suggest a mixture of CamelCase and underscored_names in fact!

 

Oh and this case their form of enum{}s are suggested to be UPPER_AND_UNDERSCORED - what an interesting mix cheeky

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ick.

I'm so not a fan of camelCaseNaming. It looks weird, like I forgot to cap the word....

 

the only things that should be all uppercase are #defines and enums in c.

In C++ there should be no #defines and enums are real types so everything should JustBeTheSame

Classes should have a C prefix; CMyClass::CMyClass(). This is to make it clear that they are a custom class. But I'm forgiving on this one.

 

I lived through Hungarian notation in the 90's, it really doesn't help, and when you change a type everything is wrong so you start not to trust it anymore. Using weird combinations of case, caps and underscores has the same problem, if you change from a const to an enum it's now wrong and most people won't fixt it.

 

The only reason to UPPERCASE #defines is because they are untyped and dangerous ( esp in C++ )

 

But in the final analysis, it doesn't matter that much. Just make the code readable and comment what the purpose of the dang Class, Function, Enum, variable, is

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

EDIT talk about coincidence. After writing this earlier today I have since been learning about Google's "protobufs" (a bit like a meta language for defining structs in a universal format from which C++ code can then be auto-generated). In reading about it I came across this:

 

https://developers.google.com/protocol-buffers/docs/style

There's a google c++ style guide which is probably more relevant to avr:

 

http://google-styleguide.googlecode.com/svn/trunk/cppguide.html

 

For naming, it contains a curious mix of CamelCase and underscored_names. Constants names are of the form kConstantVal.

 

Don't take this document as gospel. Many of the rules in it are controversial.

 

- S

 

Last Edited: Fri. Jan 16, 2015 - 01:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone else voting for an "m_" prefix on member variables in C++ classes? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This style guide covers most embedded stuff on AVRs..

 

http://www.ganssle.com/misc/fsm.doc

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone else voting for an "m_" prefix on member variables in C++ classes? ;-)

This is what we do at my current job (and in fact, most jobs that I have had). We go one step further and use "a_" for parameters passed into a function. With that, anything without a prefix is easily distinguishable as a local variable.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is what we do at my current job (and in fact, most jobs that I have had).

Phew, glad it isn't just us then!

 

In fact I can't remember which it was, but there's an editor in some IDE that auto-prefixes "m_" onto members when you define class{} so I figured it must be pretty common.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the inputs!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:

Anyone else voting for an "m_" prefix on member variables in C++ classes? ;-)

This is what we do at my current job (and in fact, most jobs that I have had). We go one step further and use "a_" for parameters passed into a function. With that, anything without a prefix is easily distinguishable as a local variable.

 

I used t do that when I was doing MFC and windows 95/2000.

I've decided it doesn't add any value.

Member variables have the FirstLetterOfEachWord in caps, locals are all lower case

Beyond that it doesn't matter

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Beyond that it doesn't matter

But it can matter. A parameter passed in might be a reference, so setting its value can affect the caller. Even if it is not a reference, it can be important to easily know whether the value came from the caller or something generated in the local function.

Regards,
Steve A.

The Board helps those that help themselves.