Coding Styles

[xwb]

Normally I write the code as

o constructor
o destructor
o mix of member functions, declarations etc

I recently came across the following coding style

o constructor
o mix of member functions, declarations etc
o destructor

The code is declared like that in both the header and the source. Someone told me that because everything began with T instead of C, it was probably a Borland style. I'm just wondering, is this common? I've never seen this style in any book, at any site or in any distributed code in 20 years of using C++.

What I find annoying about it is someone comes along adds new functions after the destructor instead of before the destructor so the destructor is now in the middle.

The other strange thing I've seen recently is constants in lowercase, variables and structures in uppercase, member variables beginning with any case. Granted there is no standard coding style but this stuff is just so weird it is difficult to follow. I'm working on 12 year old code so this has been going on for some time.

 

[cpjust]

I've seen all kinds of crazy/messy coding styles, but I don't think I've seen that one.
I always put the member variables at the top, followed by the constructors & destructor, then the public member functions, then protected functions & private functions. I also try to keep them in alphabetical order unless somebody else already messed it up.
I prefix member variables with m_ and start member functions with a capital letter.

 

[Demonpiggies]

Oh God you should see the code I work on: the code has had at least 4 different code standards that have been used over the past decade...

It's like they never heard of nesting or keeping things aligned so it can be readable...

Comments are the worst...

Variable names do not match their function or their intended use...

And the number of #Defines is absolutely astounding...

Normally I do:
- Constructors
- Deconstructors
- Accessors (or they are inlined on the *.h, which I don't really like to do)
- Functions

I don't discriminate between public/private/protected methods; I just use them as they are added...

I just like things organized...

The thing I have noticed is that older programmers that have been coding since the early 90's (and don't keep themselves up to date on software trends) tend to create their own standard and don't stray from that. The opposite seems true for programmers that started in the late 90's.

I attribute this to the ever-spreading use of OOB and the willingness to embrace change.

 

[xwb]

I once worked on a project that hit the limit on #defines. They had #defined hex00 to hexFF!

 

[Demonpiggies]

...I'm speechless...

That is truly hilarious!

 

[ArkM]

Tastes differ.
There are some logic in the OP mentioned style (ordered by call sequence.

For example, my own coding style (as usually looks like cpjust's one except follows:
- all data member declarations are placed AFTER member funcions (because there are protected and private members only and therefore ALL data members are not a part of a class interface)
- I hate hungarian-like naming conventions including m_prefix or _suffix (and prefer this->member form in ambiguous contexts). What is a name?...

I don't think that it was specifically "Borland" style.

In any case the 1st (good step in the project is to establish this->project coding style (or better follow corporation coding rules...

By the way member function definition placement is of no importance with IDE class browsers and Doxygen genererated docs. So my advice is: at first use Doxygen for legacy (foreign) codes.

 

[xwb]

This one actually has doxygen stuff built into it but the guy who did it didn't know doxygen very well so everything is in absolute locations in the doxygen input file. Also, he didn't use the //< for parameters and return values: only the /// for routines so there is a description of the routine without descriptions of the parameters.

Anyway, many of the routines do not have headings. It is quite obvious what they do (AddBeam adds a beam, RemoveBeam removes a beam)

There is a corporate style: if you can read through the waffle, it basically says code however you want. It was an attempt to satisfy auditors that there was a corporate style. Every dept was different so they came up with a doc that fitted with the different styles that every dept had. Basically all the shalls became shoulds i.e. not mandatory.

There is an underlying thought that memory is cheap and processors are fast so everything is passed by value. I'm still going through changing that - it is one of those never-ending tasks, along with putting the constructor and destructor together at the top of the class.

Also found quite a few where they started with

o constructor
o members
o destructor

and ended up with

o new code
o constructor
o members and new code
o destructor
o new code

 

[ArkM]

I think the most useful Doxygen feature in the studies of third-party codes are not comment derivatives but all sorts of diagrams (inheritance, collaborations, dependencies, calls etc). Fortunately, in that case no needs in the precense of Doxygen-oriented comments.

Some years ago I have seen a very serious banking C++ code (of famous authors. How about classes with 300-400 member functions + 100-200 data members arranged in purely stochastic order?

This code works well till now

 

[xwb]

I'll have to find out how to switch on the diagramming feature. Might be useful.

I once worked on a word processing system where the main class was a text box. Everything was a text box: a page, a header, a footer, a table cell. This was the single biggest class in the system, split over 7 source and 7 header files, each source with roughly 5-10K lines. Originally it was split because too many people were working on the same file and having enormous difficulty merging the changes. It really should have been refactored at that stage.

Sometimes, at bank interviews, I get asked about some strange feature of C++. I know the answer but I start questioning why they code like that. They normally give some reason like complicated complex constructors. When yous start questioning that, they get really edgy. Of course, I don't get the job because nobody likes a smart arse but then again, I wouldn't like to work in such a place where they are really proud of a bad design/concept.

 

[cpjust]

- I hate hungarian-like naming conventions including m_prefix or _suffix (and prefer this->member form in ambiguous contexts). What is a name?...

I hate Hungarian Notation too, but I don't consider m_ to be Hungarian Notation.
Using this->member is fine as long as everyone that works on it uses it all the time, but there's no way for the compiler to enforce it. If someone uses just member it looks like a regular local variable, and worse, if they also use member as a parameter name they'll be hiding the real member variable and could introduce bugs.
Using m_Member not only saves 4 characters when typing, but can be easily recognized as a member variable, and is enforced by the compiler because if you just type member without the m_ the compiler will tell you it doesn't know what member is.

 

[xwb]

Just tried the diagramming feature. Impressive.

There are two types of Hungarian notation: one that indicates what it is used for and another that just indicates the type. I use the former but not the latter. Most MS stuff uses the latter.

 

[ArkM]

I was very impressed by the text box successor example. Thank you, xwb

Dear cpjust, I understand why you (and may others) have used m_prefix in member names. Well, it's a matter of taste (and habit. I think that it's not a powerful coding errors filter...

Truth to tell, I'm not a naming style purist. For example, I like p-prefix for pointers (alas and never use underscores in C++ names (but used it in Unix env and C codes)...