| ★ wanayoo — archive 1999 http://www.cgsoftware.com/BeOS/Tools/Style.html | Nouvelle recherche | Portail wanayoo |
Style Conventions For the Deco Project
One of our primary goals it to write code that is readable. So if for some reason something is just not readable by using our naming conventions or style then throw out what we say and write readable code. Although I seriousely doubt that code is any more readable any other way, this is the best coding style. I guarantee.
'T' and use mixed case:
class TMyClassclass TSomeLameClassvoid DoSomething();void LoadFromFile();void SaveToFile();Functions that are not setter/getters should do something, and therefore have verb names, like DecodeAudio() or EatTheVegetables().
Functions that are setter/getters should have noun names and use the single overloaded name convention, i.e.: void Color(rgb_color SetColor), rgb_color Color().
The Exception to this is getter/setters should never be re-named, this usually happens when deriving from a class in the BeOS kits, such as BControl::IsEnabled() and BControl::SetEnabled(). You would not try and create your own Enabled() pair.
Arguments passed into fucntions should be Upper and Lower case mixed names, just like function names, this helps them be differentiated from local variables and 'Fields', ie:
void TSpiffyControl::IncreaseSpiffyness(int8 SpiffAmount, char* SpiffMoniker) { ... }
These 'fields' should have descriptive names, use upper and lowercase letters to break up words and must be pre-pended with an 'F' to differentiate them from other variables:
vector<TSomeClass*> FSomeClassVec;
int64 FSomeHugeValue;
It is also advisable to line up the variables for ease of reading.
The Object Inspector shows what are called Properties and Events.
Properties need to be named with a noun, i.e.: Position, Left or FollowsText.
Event handlers are verbs that happen at a certain time and are usually prefixed
with 'On', i.e.: OnOpen, OnAnimate or OnCreate.
int i;
BRect rect;
for (i = 0; i < 1 ; i++)
{
rect.top = i;
}
int myLongNamedLocalVariableInteger;
const int _this_is_my_global_variable =
100
T'. We wanted it to be clear what type of enumeration is being
used, so that is why we do the following: If I have an enumerated type called
TCodeStyle and there are three data names called Keyword,
Comment, and Code, then the enumerated type would be
defined as:
enum TCodeStyle = {csKeyword, csComment, csCode};
typedef TMyClass TCool;
#define MYCREATEWINDOW CreateWindow
#define MY_DEFINE 100
MyFile.h and MyFile.cpp. Second, we don't like the
new C++ style of naming header files with a .hpp.
We much prefere the old way of naming C header files as
.h.
The top section should be only generic C/C++ header includes.
#include <stdio.h> #include <stdlib.h> ...
Then go with the generic C++ stuff, ie:
#include <cpp/vector> #include <cpp/map> ...
Then the BeOS "C" type stuff:
#include <be/kernal/fs_attr.h> ...
Then the BeOS C++ kits stuff:
#include <be/interface/View.h> #include <be/storage/File.h> ...
Then project specific includes:
#include "ProjectDefs.h" #include "ThatOtherView.h" ...
Then last, but not least, the header for that .cpp module:
#include "ThisClassesHeader.h"
The subpath below boot/develop/headers/ should be included in the include as well,
this helps to speed up compile times a bit.
Do this:
if (0 == something) { if ("dave" == FName) { } } else { }
Not this:
if (0 == something) { if ("dave" == FName) { } } else { }
//------------------------------------------------------------------------------
String Flop(int Value)
{
// ToDo: switch according to value.
switch (Value)
{
case FLOP_IT:
return "To Flop or Not to Flop.";
case FLOP_ME:
return "One never Flops.";
case FLOP_YOU:
return "That is offensive, please refrain yourself.";
}
return "I have nothing to say to you.";
}
Classes should have the following general form:
class TSuperKeenClass : public TSomething
{
private:
TAggregate* FThatAggregate;
int64 FBigNumber;
protected:
bool FUsefulState;
public:
TSuperKeenClass();
~TSuperKeenClass();
virtual void GenerateCoolApplication();
TAggregate* Aggregate();
};
This may look up-side down, but it actually seems better after you get used to it.
Variable names should be lined up, as should Function names, but not necessarily
with eachother.
Member functions should also be separated by comment lines thusly :
#include "SuperKeenClass.h" //------------------------------------------------------------------------------ TSuperKeenClass::TSuperKeenClass() { ... } //------------------------------------------------------------------------------ TSuperKeenClass::~TSuperKeenClass() { ... } //------------------------------------------------------------------------------ void TSuperKeenClass::GenerateCoolApplication() { ... } //------------------------------------------------------------------------------
Code in the functions should be wrapped so that it fits in the comment line widths,
this is usually about 80 characters, but may be more if necessary.
//------------------------------------------------------------------------------
// These two lines are 80 characters
//------------------------------------------------------------------------------
class TFido
{
public:
void FunctionName(int SomeValue, String Some String, float SomeFloatNumber) { return SomeFunction(); }
};
//------------------------------------------------------------------------------
class TFido
{
public:
void FunctionName(int SomeValue, String SomeString,
float SomeFloatNumber) { return SomeFunction(); }
};
//------------------------------------------------------------------------------
class TFido
{
public:
void FunctionName(int SomeValue, String SomeString, float SomeFloatNumber)
{
return SomeFunction();
}
};
inline in front of
it. For example:
//------------------------------------------------------------------------------
class TFido
{
public:
void FunctionName(int SomeValue, String SomeString
float SomeFloatNumber);
};
// ...
inline void TFido::FunctionName(int SomeValue, String SomeString,
float SomeFloatNumber)
{
// ...
}