Ed's Blog

I’ve been thinking recently that I should write a style guide for personal C++ code. I’ve found the need to do this as I’ve found myself doing different things at different times and contradicting myself in several places. Also the lack of a clearly defined style guide at companies I think has harmed the code style in general. Note however that if I am working in existing source there is no choice but to assume the same style as the existing code. Imposing a new style of code in existing code makes the code unreadable and is bad practice.
I’ve read a lot of these at other locations and taken the ones I agree with. Please note that this is an evolving document that will be added to as I find more cases that I feel need style definitions.

Defines

• The #define pre-processor directive shall not be used to define constant values. Instead, the
  const qualifier shall be applied to variable declarations to specify constant values.
• When using #include, use
  for platform or other project includes and “header.h” for same project includes

Includes

• When using #include, use
  for platform or other project includes and “header.h” for same project includes
• Declarations of classes that are only accessed via pointers (*) or references (&) should be
  supplied by forward headers that contain only forward declarations.

General Code Rules

• Source lines will be kept to a length of 120 characters or less.
• Each expression-statement will be on a separate line. The following is not allowed:

  if(var == a) val = 0;
  

• Braces (“{}”) which enclose a block will have nothing else on the line except comments (if
  necessary).
• Braces (“{}”) which enclose a block will be placed in the same column, on separate lines
  directly before and after the block.
• C++ style casts (const_cast, reinterpret_cast, and static_cast) shall be used instead of the
  traditional C-style casts.
• All switch statements that do not intend to test for every enumeration value shall contain a
  final default clause.
• The increment expression in a for loop will perform no action other than to change a single
  loop parameter to the next value for the loop.
• Floating point variables shall not be tested for exact equality or inequality. We should use epsilon and use subtraction for tests on comparison to equality
• C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
• Operators should have a space at either side of them e.g.

  // wrong
  if(x
  

Filename Naming Conventions

• All filenames will start with an uppercase letter and each consequent word have an uppercase letter e.g. PackageManager.h
• Prefixes should not be used, they cause the reuse of a class difficult at a later point e.g. MTPackageManager.

Class Naming Conventions

• All classes will start with an uppercase letter and each consequent word have an uppercase letter e.g. SteamCommunicator

Variable Naming Conventions

• Local variables should always start with a lowercase letter
• Always attempt to use the smallest datatype possible, i.e use a short instead of an integer where possible.
• Member variables should have a 'm' prefix, e.g. m_count
• Const members (or anonymous members) should have a 'k' prefix
• Static variables should have a 's' prefix. Static members should have a 'm' prefix.
• Global variables should have a 'g' prefix.
• All variables should be initialised if possible in the constructor
• Only 1 variable should be defined per line e.g

  // incorrect
  int32 first button_on_top_of_the_left_box, i;
  

Pointers

• Pointers should have the 'p' prefix.
• The dereference operator ‘*’ and the address-of operator ‘&’ will be directly connected with the type-specifier.

  // incorrect
  int *pInt;
  // Correct
  int* pInt; 
  // incorrect 
  int &rInt; 
  // correct
  int& rInt;
  

Function Naming Conventions

• Functions should start with a lowercase letter and each consequent word have an uppercase letter e.g. listProducts
• Underscores shall NOT be used
• Any immutable/read-only parameters shall use a const reference. The exception to this rule is PODs which can be const but need not be a reference.
• Any reference non-const parameters shall use the 'r' prefix. This is to indicate to the method's code that the parameter is effectively an 'out' or return value
• Any parameter that is a pointer or smart point should use the 'p' prefix.
• A member function that does not affect the state of an object (its instance variables) will be declared const.
• A class will have friends only when a function or object requires access to the private elements of the class, but is unable to be a member of the class for logical or efficiency reasons.
• Functions shall always be declared at file scope or in anonymous namespaces.
• Functions with more than 7 arguments will not be used.
• Functions will have a single exit point, functions should not return early or have multiple exit points. This can be confusing when debugging and difficult to understand
• If a function returns a status code or boolean, this status or boolean MUST be tested and at least logged if something unexpected happens
• Only functions with 1 or 2 statements should be considered candidates for inline functions.
• Trivial accessor and mutator functions should be inlined and the number of accessor and mutator functions should be minimized.

Constructors & Destructor

• Unnecessary default constructors shall not be defined.
• Initialization of nonstatic class members will be performed through the member initialization
  list rather than through assignment in the body of a constructor.
• Members of the initialization list shall be listed in the order in which they are declared in the
  class. If possible the compiler will issue warnings for variables that are defined out of order.
• A copy constructor and an assignment operator shall be declared for classes that contain
  pointers to data items or nontrivial destructors.
• A copy constructor shall copy all data members and bases that affect the class invariant (a
  data element representing a cache, for example, would not need to be copied).
• All base classes with a virtual function shall define a virtual destructor.
• Avoid doing complex initialization in constructors (in particular, initialization that can fail or that requires virtual method calls).
• Use the C++ keyword explicit for constructors with one argument.
• ou must define a default constructor if your class defines member variables and has no other constructors. Otherwise the compiler will do it for you, badly.

Operators & Overloads

• The default copy and assignment operators will be used for classes when those operators
  offer reasonable semantics.
• An assignment operator shall return a reference to *this.
• An assignment operator shall assign all data members and bases that affect the class invariant
  (a data element representing a cache, for example, would not need to be copied).
• When two operators are opposites (such as == and !=), both will be defined and one will be
  defined in terms of the other.

Typedefs

• Typedefs should start with an uppercase letter and each consequent word should have an uppercase letter. The name of the type should indicate the type of the object eg. ProductMap.
• Container typedefs should always have an interator and const iterators defined:

  typedef ProductMap::iterator ProductMapIter
  typedef ProductMap::const_iterator ProductMapConstIter
  

Enumerations

• Enums should always start with an uppercase and each subsequent word start with an uppercase letter e.g. DisplayTypes
• Enum types should have an 'e' prefix and use the definition name at the start of the name e.g.

  enum DisplayType
  {
     eDisplayTypeBlock,
     eDisplayTypeInline,
     eDisplayTypeMax
  };
  

• The enum should always contain a 'max' enum type, this is to facilitate iterating through the enums.

If statements

• When mutable variables are compared with a constant (or NULL) the style should always be as follows:

  if(12 == x)
  {
  }
  

• If statements should always have curly brackets and should start on the line after the if statement.

For statements

• For statements should always have curly brackets and they should start on the line after the for statement

Comments

• Standard ('//') comments and comment blocks ('/** ... **/') are the only comments allowed
• Code commented should should be deleted, this is the whole point of source control.
• PRE and POST conditions of functions should be commented in the header for a class

  // PRE(pPointer)
  // POST(pPointer)
  void doSomething(pPointer);
  

I've attached my personal C++ and Objective C template classes which are effectively skeletons and to be used as a starting point for new classes.

CPPTemplate.h
CPPTemplate.cpp
ObjectiveCTemplate.h
ObjectiveCTemplate.m

I’ve found a need to use Perforce with C# recently. The first step was to get the right DLLs for the job. I got the P4 API DLL from SourceForge here

Extracting it, I think you actually only need the p4API dll in the bin/CLR_2.0 directory, I took the whole directory just in case.

In your project right click on the References directory and ‘Add Reference’ and navigate to the p4api.dll.

// Load up the API
using P4API;
...

// Create the connection
P4Connection p4 = null;
            try
            {
                p4 = new P4Connection(); // Uses the default connection to Perforce        
                p4.Connect();

                // Don't throw an exception on a Perforce error.  We handle these manually.
                p4.ExceptionLevel = P4ExceptionLevels.NoExceptionOnErrors;
            }
            catch (System.Exception ex)
            {
                Console.WriteLine(ex.Message);
            }

I want to delete a file from the repository so to do this I needed to just put through the right call. From what I’ve gathered you can run any P4 command that can be run via the command line, all you need to do is

try
{
       if (p4 != null)
       {
             p4.RunUnParsed("delete", selectedItemPath);
       }                
}
catch (System.Runtime.InteropServices.COMException ex)
{
        MessageBox.Show(ex.Message);
}

Done!

Hi,

I’ve just started using C# for the first time and decided to chuck up a little intro on how to connect with a Postgres database. This is a very stripped down tutorial, does the basics and doesn’t really handle exceptions, error states and the like. Firstly you need to get a few DLLs, Npgsql.dll, policy.2.0.Npgsql.dll and MonoSecurity.dll. You can get them from PgFoundry here.

I’ve put these in the same folder as the project. Go to Solution Explorer and locate the ‘References’ section under your project. Right click that and Add Reference. Click the ‘Browse’ tab and select the Npqsql dll only.
Firstly you need to load up the package/namespace (I’m not sure of the correct terminology here). Then you’re ready to connect to the database using the correct name, port, username and so on. This is simple.

using System;
...
using Npgsql;


....


NpgsqlConnection dbConnection = new NpgsqlConnection("Server=myServer;Port=xxxx;User Id=xyz;Password=xyz;Database=myDB;");

try
 {
        dbConnection.Open();
 }
catch
{
        //Handle error states here
}

That’s it! You’re now ready to execute queries and updates on the database.

I’ve included a very simple select statement below, it selects all from a hypothetical animal table and extracts the name and type column values from the results. The GetOrdinal is a useful helpful function to return you the integer that represents the index of the named column. It is more robust to changes in the database as indices may change but you need to check for NULLs as it won’t work (I’ve found out!)

NpgsqlCommand Command = new NpgsqlCommand("select name,type from animals", dbConnection);
NpgsqlDataReader result = Command.ExecuteReader();

while (result.Read())
{
      String animalName = result.GetString(result.GetOrdinal("name"));
      String animalType = result.GetString(result.GetOrdinal("type"));
      ... (Do something here)
}

Finally when you’re done with your database you need to close down the connection

dbConnection.Close();
dbConnection = null;

Thats it’s some very simple DB manipulations in very few lines of code, impressed with C# so far I must say!
Next step do things in transactions and handle exceptions!