Lesson coding standards

I like camelCase, or m_ prefixing for member variables. I do not like the k_ stuff, I think CONSTANTS with all caps seem like a good standard as well.

I think we need a standard for how to comment on functions. We also need to decide on spaces or tabbing. I have so far seen a mixture of this in the current lesson.

Variables
All member variables should have a prefix of m_ and member pointers should have a mp_ prefix.

Global variables should be prefixed with g_ although preferably we should limit these. Constants should be in CAPITALS.

I prefer spacing over tabbing; in general I try to be explicit when the option presents itself (tabbing length is open to interpretation - usually either 4 or 8 spaces long).

Regarding the all caps for constants, I think all caps are reserved for macros and I dont think we should change that. Upper case tends to indicate that the preprocessor will touch the value.

With regards to the prefixes, they seem to be widely used; I'm kinda supprised that you guys have not seen the k_ prefix. I think if we want to endorse proper coding style, however we should use the following prefixes:
- my_ for class members
- our_ for static class members
- the_ for global members
I'm not exactly sure what is used for const members in this style...

I would choose tabs over spaces, its so much easier to indent chunks of code with them, and also in most tools the size of the tabs can be set, so its dependent on the viewer of the code what they set the spacing to not the developer.

Um, what does the k_ stand for?

I was thinking should we keep our naming of variables the same as the SDK? Then the transfer from introductory basecode to SDK code would be more seamless. The naming in the SDK is:

m_ for member variables
mp_ for member pointers
c_ for constants

I'm not entirely sure what the k_ stands for :s, but I've seen it everywhere. However, I would still prefer using the prefixes I previously outlined; they make more sence for OOP.

I'm still quite adament about keeping spaces over tabs. You tend to get a lot of wierd tabbing artifacts when switching between 4 and 8 space tabs. A proper editor will also indent code chunks properly with spaces. We also want things looking consistent online, independent of browser selection.

I think we should add this to this weeks meeting agenda, we really need some standards devised.

Quote:

Original post by Kazade The naming in the SDK is: m_ for member variables mp_ for member pointers c_ for constants

I like this personally. With the addition of ms_ for static members, and g_ for globals, it is exactly what I use in my own code, and I find it works quite well for identifying things.

Personally I keep all my classes named as such GLWindow, or RenderDevice, and pure virtual classes the same, but I append a I to them to designate that it is an interface. Functions I name the same way, but from my Java background I am also used to camelCase. Personally, I don't like our current style of everything lower case, as I think it doesn't show a distinction between types and variables.

And to be honest, I have never seen k_ anywhere. I've always either seen constants in all caps, or with c_. I feel like I am missing out on something here.

I added a template page that we can use/modify for the meeting this sunday. It is a template for the lesson coding standards it can be found here: https://opensvn.csie.org/traccgi/NeHeDev/wiki/LessonCodingStandards

Quote:

Original post by DevLiquidKnight I think we should add this to this weeks meeting agenda, we really need some standards devised.

Speaking of the meeting, I have an additional suggestion: The addition of an "action items" page created after each weekly meeting. This page would list any specific tasks decided upon during the meeting as well as who should be responsible. Each week's meeting could then begin with a brief followup where the progress on the previous week's action items are checked.

So to clarify, for each meeting there would be on the wiki:
- An agenda, created before the meeting.
- A list of action items, created after the meeting.
- A log of the meeting, and optionally a cut-down log of highlights.
- and possibly an additional 'topics for discussion' page from which weekly agendas could be drawn up.

The action items sound quite possibly the same as the highlights. I just see it similar; perhaps some differences such as who is responsible. Today I did add more topics to this upcoming meetings topics. I suggest everyone look into them and see we can add/move around them.

Quote:

Original post by Kazgoroth Quote: Original post by DevLiquidKnight I think we should add this to this weeks meeting agenda, we really need some standards devised. Speaking of the meeting, I have an additional suggestion: The addition of an "action items" page created after each weekly meeting. This page would list any specific tasks decided upon during the meeting as well as who should be responsible. Each week's meeting could then begin with a brief followup where the progress on the previous week's action items are checked. So to clarify, for each meeting there would be on the wiki: - An agenda, created before the meeting. - A list of action items, created after the meeting. - A log of the meeting, and optionally a cut-down log of highlights. - and possibly an additional 'topics for discussion' page from which weekly agendas could be drawn up.

I like this idea, except I feel as though I will never get tasks assigned to me, because unfortunately, I work practically every Sunday, at the time the meetings are scheduled.