Board index » cppbuilder » Re: programming style

2005-03-05 03:32:38 AM
cppbuilder5
again sometime.
But, thank you for the explanation.
Jonathan
 

remember - could be something with draft printing.
--
Best regards,
Vladimir Stefanovic
 

need to code correctly, rather than how I like it.
 

{smallsort}

paper.
 

Vladimir Stefanovic wrote:
to be style guidelines from the main vendors. C++ does not have any, so
you'll see a range of styles.
What I find strange though, is that Borland has a style guide for
Delphi, but not for its own C++ code.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"God is love, but get it in writing." -- Gypsy Rose Lee.
 

TMyClass* mc;
more intuitve for several reasons.
A) The type is pointer-to-TMyClass, thus the type is more clearly defined.
B) Is is consistent with the common syntax for references:
TMyClass& mc;
C) It is consistent with common type-cast syntax:
(TMyClass*) or
static_cast<TMyClass*>()
The downside is in declaring multiple pointers of the same type, but this
honestly is rare, and any complex system is going to have exceptions. It
doesn't cost much to declare each on a sperate line, like
TMyClass* mc1;
TMyClass* mc12;
alternativly:
TMyClass* mc1,
* mc2,
* mc3;
The best solution would be if C++ devieated from C and defined TMyClass* as
the type, thus
TMyClass* m1, mc2, mc3
would declare three pointers. But to keep compatibility with C, the * is
officially a modifier to the variable.
I think we can agree that declaring both pointers and objects in a single
line is not wise. Hence,
(ptr) (ptr) (obj) (ptr)
TMyClass *mc1, *mc2, mc3, *mc4;
should never be used and there is no real need for this *feature* within the
context of C++. IMO, TMyClass* should be the type. Thus the TMyClass* syntax
gets as close to that definition while still supporting C compatibilty.
I'm sure not everyone agrees, but one thing I'm sure we can all agree on is
this:
TMyClass * mc1; //is very bad.
 

page of code for years.
--
Best regards,
Vladimir Stefanovic
 

Most IDEs including BCB have a setting to convert tabs to spaces.
"Jonathan Benedicto" < XXXX@XXXXX.COM >wrote in message

 

--
Best regards,
Vladimir Stefanovic
 

Vladimir Stefanovic wrote:
Oh, I see it is:
community.borland.com/soapbox/techvoyage/article/1,1795,10280,00.
html
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Sometimes a scream is better than a thesis."
- Ralph Waldo Emerson (1803-1882)
 

Jonathan Benedicto wrote:
type - because when it is, visually it's conveying the wrong meaning.
.a
 

"Jonathan Benedicto" < XXXX@XXXXX.COM >writes:
TMyClass * mc;
--
Chris (TeamB);
 

"Alex Bakaev [TeamB]" < XXXX@XXXXX.COM >writes:
small font it's hard to sometimes tell what they are. :) At least,
that was one of the motivating factors for why we chose to have space
on both sides of the * and & chars in type declarations.
--
Chris (TeamB);
 

intervening space.
You will learn why the next time you are tired and frustrated in a
debugging session because things do not work as they should only to
finally notice the brace. This is the same issue as is illustrated by
the semicolon in this while line (which is not one of yours) as you
sit there in your debugging session wondering why executable-statement
only executes once:
while (condition);
executable-statement;
quickly read. There is no advantage, only disadvantage.
Post incrementing when it is not required is at best no less efficient
than pre-incrementing but syntactically suggests that a post increment
is needed, which it is not. For C++ classes and structures, including
and especially STL-related items, post-increment can be expensive in
both code size and execution time. Never use t++ when ++t will do.
if(condition){statement;statement;}else{statement;statement;}
and does not line wrap. I like the blank line following it. It makes
it stand out.
If it has enough enum values to line wrap I prefer it to be formatted
much as a structure declaration is done. Using your brace style that
might be something like this:
enum TMyEnum {
meOne,
meTwo,
meThree,
meFour,
meFive,
meEtc
};
. Ed