LiveGeometry Wiki & Documentation Rss Feed

Updated Wiki: Home

KirillOsenkov — Sat, 07 May 2011 22:42:25 GMT

NEW: Tabula

Professional geometry learning software built using the Live Geometry engine:
http://numeracyworks.com
http://blogs.msdn.com/b/kirillosenkov/archive/2011/05/02/tabula.aspx

Project Description

Live Geometry lets you create interactive ruler and compass constructions and experiment with them. It is CAD-like educational software for teachers and students. It helps visualize and solve geometry problems.
The project is written with Silverlight 4 and C# 4.0 (Visual Studio 2010). Visual Studio 2008 is no longer supported.
The core engine is a flexible and extensible framework that allows you to easily add new figure types and features. The project has two front-ends: WPF and Silverlight; they both share the common DynamicGeometry library.

Live Preview

Try the Drawing -> Samples button:

You need to install Microsoft Silverlight to view this content. Get Silverlight!

Releases and Downloads

To make sure only the up-to-date source code is available, I'm not publishing releases on the downloads tab. You can always download the latest source on the Source Code tab, just pick the recent changeset number and click Download to download the latest source.
You can view and use the application live at http://livegeometry.com

Documentation

Screenshots

Updated Wiki: Home

KirillOsenkov — Sat, 07 May 2011 22:41:47 GMT

NEW: Tabula

Professional geometry learning software built using the Live Geometry engine:
http://numeracyworks.com

Project Description

Live Geometry lets you create interactive ruler and compass constructions and experiment with them. It is CAD-like educational software for teachers and students. It helps visualize and solve geometry problems.
The project is written with Silverlight 4 and C# 4.0 (Visual Studio 2010). Visual Studio 2008 is no longer supported.
The core engine is a flexible and extensible framework that allows you to easily add new figure types and features. The project has two front-ends: WPF and Silverlight; they both share the common DynamicGeometry library.

Live Preview

Try the Drawing -> Samples button:

You need to install Microsoft Silverlight to view this content. Get Silverlight!

Releases and Downloads

Documentation

Screenshots

New Comment on "Documentation"

meenacs — Mon, 07 Mar 2011 07:12:24 GMT

Is there a full detailed document for this project?Really need it

Updated Wiki: Home

KirillOsenkov — Sun, 12 Sep 2010 03:33:50 GMT

Project Description

Live Geometry lets you create interactive ruler and compass constructions and experiment with them. It is CAD-like educational software for teachers and students. It helps visualize and solve geometry problems.
The project is written with Silverlight 4 and C# 4.0 (Visual Studio 2010). Visual Studio 2008 is no longer supported.
The core engine is a flexible and extensible framework that allows you to easily add new figure types and features. The project has two front-ends: WPF and Silverlight; they both share the common DynamicGeometry library.

Live Preview

Try the Drawing -> Samples button:

You need to install Microsoft Silverlight to view this content. Get Silverlight!

Releases and Downloads

Documentation

Screenshots

New Comment on "CodingGuidelines"

rharding64 — Tue, 27 Jul 2010 03:11:54 GMT

concerning possible uses of Live Geometry; i have not yet dug into it yet, but i am looking at possible application areas; First some upfront supporting information: I am an electronic engineer who cross trained into MS .NET about 4 years ago. Since that time, my deliverables have consisted of c# windows based applications that provide remote control of connected device under test over USB/LAN and associated electronic test equipment using ivi.com .NET drivers using SCPI(see ivifoundation.org). So, in demos that i show to employers, i have an agilent 33220A arbitrary waveform generator that i remote control over USB and LAN(LXI device) using c# 2008 express and sql server 2008 express. I have 2010 tools installed and i have been experimenting with silverlight together with ironpython and ironruby. So, what i am looking for in the LIveGeometry is a way to model these waveforms so i can port them to webpage using silverlight. besides waveform generator test equipment i have specialized electronic hardware with both analog to digital and digital to analog capabilties on board. So, using that equipment or using the waveform generator, i want to be able to view the waveforms in my c# .NET GUI. My application is targeted to electronic engineers who are working on new product prototypes, so it will contain a waveform editor, an equation editor for output and waveform display for both input and output. looking for any suggestions you may have. have a good day. any suggestions / comments are welcome.

New Comment on "CodingGuidelines"

rharding64 — Tue, 27 Jul 2010 03:10:49 GMT

concerning possible uses of Live Geometry; i have not yet dug into it yet, but i am looking at possible application areas; First some upfront supporting information: I am an electronic engineer who cross trained into MS .NET about 4 years ago. Since that time, my deliverables have consisted of c# windows based applications that provide remote control of connected device under test and associated electronic test equipment using ivi.com .NET drivers using SCPI(see ivifoundation.org). So, in demos that i show to employers, i have an agilent 33220A arbitrary waveform generator that i remote control over USB and LAN(LXI device) using c# 2008 express and sql server 2008 express. I have 2010 tools installed and i have been experimenting with silverlight together with ironpython and ironruby. So, what i am looking for in the LIveGeometry is a way to model these waveforms so i can port them to webpage using silverlight. besides waveform generator test equipment i have specialized electronic hardware with both analog to digital and digital to analog capabilties on board. So, using that equipment or using the waveform generator, i want to be able to view the waveforms in my c# .NET GUI. My application is targeted to electronic engineers who are working on new product prototypes, so it will contain a waveform editor, an equation editor for output and waveform display for both input and output. looking for any suggestions you may have. have a good day. any suggestions / comments are welcome.

New Comment on "Documentation"

MoosaviAmir — Mon, 14 Jun 2010 05:53:43 GMT

Hi guys! Is there a full detailed document for this project? i really need something like this and i really wonder if you could help me to understand your code! Thank you!

New Comment on "Documentation"

MoosaviAmir — Sun, 13 Jun 2010 08:22:30 GMT

hi guys! is there a full detail document for this project? i really need something just like this and i really wonder if you can help me to understand your code! thank you!

Updated Wiki: Documentation

KirillOsenkov — Mon, 12 Apr 2010 06:57:34 GMT

Live Geometry Documentation

Requirements

The project is built using Visual Studio 2008 with Silverlight Tools installed (currently Silverlight 3.0). The language is C# 3.0, and the projects exist that target both WPF (.NET Framework 3.5) and Silverlight 3.0. Same source code files are used for WPF and Silverlight versions.

Source code overview

The source code (Main) consists of several projects:

DynamicGeometryLibrary

The dynamic geometry library (framework) that provides types and services to model geometric figures and drawings.
DynamicGeometry.csproj is the WPF (desktop) project, and SilverlightDynamicGeometry.csproj is the Silverlight project. They both reference the same set of .cs files.

SilverlightClient

Silverlight client application (front-end) for the Dynamic Geometry library.

WPFClient

WPF (desktop) version. It is currently less maintained and I concentrate more efforts on the Silverlight version. It doesn't expose all the feature that are available in the DynamicGeometryLibrary yet. I will come back to WPF at a later point and update it to surface more features and to reach parity with Silverlight client.

Samples

Samples folder currently contains one sample application that is built on top of the dynamic geometry library. It is called PolylineRouting and it is a simple app that connects two dots with the shortest path around a polygon. Read more here: http://blogs.msdn.com/kirillosenkov/archive/2009/06/07/algorithms-in-c-shortest-path-around-a-polygon-polyline-routing.aspx

Drawing.cs

The central class of the DynamicGeometry library is a Drawing. A Drawing represents a set of figures as a logical entity. It's not a WPF/Silverlight control, so you can't directly place a Drawing on a Canvas. Instead, you can associate a Drawing with any existing Canvas control. A Drawing HAS a Canvas, not Drawing IS Canvas.
A Drawing references several other parts, such as a RootFigureList, an ActionManager, a Behavior, a CoordinateSystem, a CoordinateGrid (CartesianGrid) etc.

To experiment with hosting a Drawing on your own Canvas, you can view the PolylineRouting sample: Main\Samples\PolylineRouting\Page.xaml.cs

FigureList.cs

A FigureList is a list of figures in a Drawing. Actually, Drawing references a derived class called RootFigureList.

Dependency Tracking

Dynamic geometry stores an algorithm of a construction, and figure coordinates are recalculated every time a drawing is changed. All the figures are classified into three groups: independent, semi-dependent and dependent.

Figures can be independent of other figures, for instance a point can exist all by itself and its coordinates are determined by the user who drags the point around.
Other figures can be partially dependent on other figures (for example, a point on a line can be both dragged by the user or moved with the line as the line moves around).
Finally, a figure can be fully dependent on other figures. For example, a segment is fully defined by two points, so the user has no way of influencing the segment other than moving its endpoints. A caveat here is that if you drag a dependent figure, the dynamic geometry engine computes the least set of independent figures that fully defines the one the user is dragging, and drags this set, so the user has the impression of dragging the figure itself.

Independent figures are: Point, Label, Hyperlink, FunctionGraph.
Semi-dependent figure is: PointOnFigure.
All other figures are dependent (e.g. Segment, Line, Circle, IntersectionOfCircleAndLine, Polygon, CoordinatesMeasurement, etc.)

A figure can have dependencies (figures it depends on) and dependents (figures that are depending on it). This relationship can be modeled using "in" and "out" edges of a dependency graph. The dependency graph doesn't have cycles, so it's really a DAG.

Since all the figures form a DAG with respect to the dependency relationship, we sort the figures using topological sorting. Here's an example of the DAG for a circle circumscribed around a triangle (dependencies are in parentheses):

1. Point
2. Point
3. Point
4. Segment (1, 2)
5. Segment (2, 3)
6. Segment (1, 3)
7. Midpoint (1, 2)
8. Midpoint (1, 3)
9. Perpendicular (7, 4)
10. Perpendicular (8, 6)
11. Intersection (9, 10)
12. Circle (11, 1)

This is sufficient description to fully define the drawing given the coordinates of the first three points as input. The coordinates of all figures are recalculated every time an independent or semi-dependent figure has been moved by user. Figures are recalculated in topological order (top-to-bottom in our example). Topological order means that all dependencies of each figure come before it (and all dependents come after it). A drawing is usually fully defined by several independent figures (points).

Each figure (IFigure) has a property called Dependencies, which is a list of figures that the current figure depends on. Also each figure has a property called Dependents which stores all figures that directly depend on this one. When a new figure is created, a RegisterWithDependencies() method is called, that fills the new figure's Dependencies list and then goes through all the figures in it and adds the new figure to their Dependents list. So the relationship is bi-directional.

The TopologicalSort method is used to sort all figures topologically with regards to the dependency relationship. You can read more at :
http://blogs.msdn.com/kirillosenkov/archive/2008/08/10/representing-dependencies-in-code.aspx

Function Graphs

The Silverlight client exposes a feature that allows the user to plot function graphs given a string such as "sin(x)" or "x*2 + 3". To evaluate arithmetical expression, we host the DLR and piggyback on its ability to compile a string to an executable delegate. Read more at:
http://blogs.msdn.com/kirillosenkov/archive/2009/03/26/dlr-hosting-in-silverlight.aspx

Updated Wiki: Documentation

KirillOsenkov — Mon, 12 Apr 2010 06:56:47 GMT

Live Geometry Documentation

Contributing to the project

Contributing

Requirements

Source code overview

The source code (Main) consists of several projects:

DynamicGeometryLibrary

SilverlightClient

Silverlight client application (front-end) for the Dynamic Geometry library.

WPFClient

Samples

Drawing.cs

FigureList.cs

A FigureList is a list of figures in a Drawing. Actually, Drawing references a derived class called RootFigureList.

Dependency Tracking

Figures can be independent of other figures, for instance a point can exist all by itself and its coordinates are determined by the user who drags the point around.
Other figures can be partially dependent on other figures (for example, a point on a line can be both dragged by the user or moved with the line as the line moves around).
Finally, a figure can be fully dependent on other figures. For example, a segment is fully defined by two points, so the user has no way of influencing the segment other than moving its endpoints. A caveat here is that if you drag a dependent figure, the dynamic geometry engine computes the least set of independent figures that fully defines the one the user is dragging, and drags this set, so the user has the impression of dragging the figure itself.

Independent figures are: Point, Label, Hyperlink, FunctionGraph.
Semi-dependent figure is: PointOnFigure.
All other figures are dependent (e.g. Segment, Line, Circle, IntersectionOfCircleAndLine, Polygon, CoordinatesMeasurement, etc.)

Function Graphs

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:55:47 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable.

Project/solution structure

File placement, file names and folder structure are very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Tools -> Options -> Text Editor -> Tabs -> Insert spaces, tab size = 4
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters. This is the default Visual Studio setting.

Curlies

Opening curly of a block should be on a new line like this:

block 
{
    stuff
}

and not like this:

block {
    stuff
}

One line flow-control statements should still include a block statement:

if (something)
{
    something else;
}

and not:

if (something)
    something else;

This enhances maintainability by ensuring that someone modifying the code at a later date will not forget to add the braces.

This style will be applied consistently to all code construct that require an open/close brace pair (classes, namespaces in C#, method block, etc.)

Commenting

It's OK to not have comments, since the code is still very much in flux. However it helps to have comments in difficult parts of the code.

Don't use obvious comments that can be inferred by just reading the code:
AssignValue(instance); // assigns a value to instance

Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.

Types and members should use XML doc comments.

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);

Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )

Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()

Do not use spaces inside brackets:
Right: x = dataArray[index];
Wrong: x = dataArray[ index ];

Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)

Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

http://msdn2.microsoft.com/en-us/library/xzf533w0(vs.71).aspx]
Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

Names of types, members and enums (except fields): PascalCasing
names of parameters, local variables and fields: camelCasing
NOSCREAMINGCAPS
nounderscoresif_possible
Prefix interfaces with I
Do not use Hungarian notation (bstrSomething, frmMain)
DontAbbrevLngWrdsBcseAbbrAreUsuDffcltToRd:

Use full words instead of shortened words:
expectedFilenames expFilenames
expectedMessageResourceIDs expMsgResIDs
localizedErrorMessage localizedErrMsg
modifier mod
projectReference projRef
languageOptions langOptions

Method level

Use shorter boolean conditionals:
if (X) instead of if (X == true)
if (!X) instead of if (X == false)
if (X && !Y) instead of if (X == true && Y == false)

Don't use the old C convention if (null == stuff), use if (stuff == null).

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:55:23 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable.

Project/solution structure

File placement, file names and folder structure are very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Curlies

Opening curly of a block should be on a new line like this:

block 
{
    stuff
}

and not like this:

block {
    stuff
}

One line flow-control statements should still include a block statement:

if (something)
{
    something else;
}

and not:

if (something)
    something else;

Commenting

It's OK to not have comments, since the code is still very much in flux. However it helps to have comments in difficult parts of the code.
Don't use obvious comments that can be inferred by just reading the code:
AssignValue(instance); // assigns a value to instance
Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.
Types and members should use XML doc comments.

Spacing

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

http://msdn2.microsoft.com/en-us/library/xzf533w0(vs.71).aspx]
Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

Names of types, members and enums (except fields): PascalCasing
names of parameters, local variables and fields: camelCasing
NOSCREAMINGCAPS
nounderscoresif_possible
Prefix interfaces with I
Do not use Hungarian notation (bstrSomething, frmMain)
DontAbbrevLngWrdsBcseAbbrAreUsuDffcltToRd:

Method level

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:52:37 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable.

Project/solution structure

File placement, file names and folder structure are very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Curlies

Opening curly of a block should be on a new line like this:

block 
{
    stuff
}

and not like this:

block {
    stuff
}

One line flow-control statements should still include a block statement:

if (something)
{
    something else;
}

and not:

if (something)
    something else;

Commenting

It's OK to not have comments, since the code is still very much in flux. However it helps to have comments in difficult parts of the code.
Don't use obvious comments that can be inferred by just reading the code:
AssignValue(instance); // assigns a value to instance
Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.
Types and members should use XML doc comments.

Spacing

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

http://msdn2.microsoft.com/en-us/library/xzf533w0(vs.71).aspx
Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

Names of types, members and enums (except fields): PascalCasing
names of parameters, local variables and fields: camelCasing
NOSCREAMINGCAPS
nounderscoresif_possible
Prefix interfaces with I
Do not use Hungarian notation (bstrSomething, frmMain)
DontAbbrevLngWrdsBcseAbbrAreUsuDffcltToRd:

Use: instead of:
expectedFilenames expFilenames
expectedMessageResourceIDs expMsgResIDs
localizedErrorMessage localizedErrMsg
modifier mod
projectReference projRef
languageOptions langOptions

Method level

Variable initialization and declaration: the assignment operators should be aligned under each other like this:

int i = 0
string j = 0

Use shorter boolean conditionals:
Use: instead of:
if (X) if (X == true)
if (!X) if (X == false)
if (X && !Y) if (X == true && Y == false)

Don't use the old C convention if (null == stuff), use if (stuff == null).

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:51:20 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable.

Project/solution structure

File placement, file names and folder structure are very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Curlies

Opening curly of a block should be on a new line like this:

block 
{
    stuff
}

and not like this:

block {
    stuff
}

One line flow-control statements should still include a block statement:

if (something)
{
    something else;
}

and not:

if (something)
    something else;

Commenting

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);

Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )

Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()

Do not use spaces inside brackets:
Right: x = dataArrayindex;
Wrong: x = dataArrayindex;

Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)

Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

Method level

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:50:05 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable.

Project/solution structure

File placement, file names and folder structure are very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Curlies

Opening curly of a block should be on a new line like this:

block 
{
    stuff
}

and not like this:

block {
    stuff
}

One line flow-control statements should still include a block statement:

if (something)
{
    something else;
}

and not:

if (something)
    something else;

Commenting

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()

Do not use spaces inside brackets:
Right: x = dataArrayindex;
Wrong: x = dataArrayindex;
Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)
Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

Method level

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:48:18 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable.

Project/solution structure

File placement is very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Tools -> Options -> Text Editor -> Tabs -> Insert spaces, tab size = 4
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.

Curlies

Opening curly of a block should be on a new line like this:
block
{
stuff
}
and not like this:
block {
stuff
}

One line flow-control statements should still include a block statement:
if (something)
{
something else;
}
and not:
if (something)
something else;

This enhances maintainability by ensuring that someone modifying the code at a later date will not forget to add the braces.

This style will be applied consistently to all code construct that require an open/close brace pair (classes, namespaces in C#, method block, etc.)

Commenting

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()

Do not use spaces inside brackets:
Right: x = dataArrayindex;
Wrong: x = dataArrayindex;
Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)
Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

Method level

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:47:38 GMT

Live Geometry Coding Guidelines

This is a live document, please edit and add stuff as necessary. Every edit should be reviewed or discussed with the team.

Goals: the code should be uniform, consistent, readable, with no discrepancies.

Project/solution structure

File placement is very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.

Tabs and indenting

Tools -> Options -> Text Editor -> Tabs -> Insert spaces, tab size = 4
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.

Curlies

Commenting

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()

Do not use spaces inside brackets:
Right: x = dataArrayindex;
Wrong: x = dataArrayindex;
Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)
Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

Method level

Type and Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.

Library usage

Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:45:57 GMT

Live Geometry Coding Guidelines

Links:

Design Guidelines for Class Library Developers:
http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx

Krzysztof Cwalina:
http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx

Brad Abrams:
http://blogs.msdn.com/brada/articles/361363.aspx

Kirill Osenkov (whitespace guidelines):
http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Project/solution structure

Tabs and indenting

Tools -> Options -> Text Editor -> Tabs -> Insert spaces, tab size = 4
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.

Curlies

Commenting

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()

Do not use spaces inside brackets:
Right: x = dataArrayindex;
Wrong: x = dataArrayindex;
Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)
Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

Method level

Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).

Updated Wiki: CodingGuidelines

KirillOsenkov — Mon, 12 Apr 2010 06:38:35 GMT

Live Geometry Coding Guidelines

Project/solution structure

File placement is very important. Carefully think when adding a new file, because changing the file structure is costly! If in doubt, ask other team members.
User Defined Types - we are encouraged to define and use user defined types to clearly capture the intent of the code. Don't be afraid of adding a new user defined type.
Use FileInfo and DirectoryInfo instead of strings to store file and directory names
Use Path.Combine to concatenate parts of a path
Use File.ReadAllText(string) to read text from a file into a string
Tabs and indenting

Tools -> Options -> Text Editor -> Tabs -> Insert spaces, tab size = 4
(Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.)

Feel free to make use sufficient amount of vertical space in your source files. Source code should be readable and sufficient vertical space enhances readability.

Bracing

Opening curly of a block should be on a new line like this:
block
{
stuff
}
and not like this:
block {
stuff
}

One line flow-control statements should still include a block statement:
if (something)
{
something else;
}
and not:
if (something)
something else;

This enhances maintainability by ensuring that someone modifying the code at a later date will not forget to add the braces.

This style will be applied consistently to all code construct that require an open/close brace pair (classes, namespaces in C#, method block, etc.)

Commenting

Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.

Types and members should use XML doc comments.

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between method arguments:
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1);
Do not use a space after the parenthesis and method arguments:
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 )
Do not use spaces between a method name and parenthesis:
Right: CreateFoo()
Wrong: CreateFoo ()
Do not use spaces inside brackets:
Right: x = dataArrayindex;
Wrong: x = dataArrayindex;
Do use a single space before flow control statements:
Right: while (x == y), if (true)
Wrong: while(x==y), if(true)
Do use a single space before and after binary operators:
Right: if (x == y), a = 2 + 3;
Wrong: if (x==y), a=2+3;

Vertical spacing:

http://blogs.msdn.com/kirillosenkov/archive/2009/03/12/kirill-s-whitespace-guidelines-for-c.aspx

Naming conventions

http://msdn2.microsoft.com/en-us/library/xzf533w0(vs.71).aspx
Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

Names of types, members and enums (except fields): PascalCasing
names of parameters, local variables and fields: camelCasing
NOSCREAMINGCAPS
nounderscoresif_possible
Prefix interfaces with I
Do not use Hungarian notation (bstrSomething, frmMain)
DontAbbrevLngWrdsBcseAbbrAreUsuDffcltToRd:

Use: instead of:
expectedFilenames expFilenames
expectedMessageResourceIDs expMsgResIDs
localizedErrorMessage localizedErrMsg
modifier mod
projectReference projRef
languageOptions langOptions

Method level

Variable initialization and declaration: the assignment operators should be aligned under each other like this:

int i = 0
string j = 0

Use shorter boolean conditionals:
Use: instead of:
if (X) if (X == true)
if (!X) if (X == false)
if (X && !Y) if (X == true && Y == false)

Don't use the old C convention if (null == stuff), use if (stuff == null).

Member design

Avoid using fields - use either properties or auto-properties (PascalCasing).

Updated Wiki: Contributing

KirillOsenkov — Mon, 12 Apr 2010 06:35:47 GMT

Contributing to the project

Getting the source

All the tools necessary to work with the project (except for Visual Studio itself) are free.
The page http://livegeometry.codeplex.com/SourceControl/list/changesets on the right-hand side shows the choices of version control client that you can use to follow the project and make edits.

If you're not a developer on the project, unfortunately you cannot use the (Team Foundation Client) that installs into Visual Studio. You have two choices: install a free Subversion client (recommended: TortoiseSVN) or the CodePlex client.
If you ARE a developer on the project, things are much easier. If you have Visual Studio 2008, make sure to install Team Explorer (from the TFC folder in the Visual Studio 2008 installation DVD or from here. If you have Visual Studio 2010, Team Explorer comes preinstalled (unless you're running Express), so you don't have to do anything.

If you're following the project, it is recommended that you use a version control client such as TortoiseSVN and regularly download new versions using SVN Update, instead of manually downloading the changeset archives for new versions. It will save you a lot of time - updating using SVN Update or the CodePlex client is one command - you don't have to download and extract the full source code all over again.

Submitting changes

There are several ways to contribute your source code changes to the project.

TFS shelveset (preferred). The most preferred way to send me code for approval is using TFS shelvesets. If you're a developer and you're using the Team Foundation Client that is built into Visual Studio (recommended), just Shelve Pending Changes and let me know the shelveset name. I will be able to unshelve your changes on my side, review them and check in. Shelvesets are a great way to share code, much better than patches or archived code files. Read more about Shelvesets here: http://msdn.microsoft.com/en-us/library/ms181403(VS.80).aspx
Subversion patch. If you use TortoiseSVN or other Subversion client to follow the project, use the Create patch context menu option on the root of your working copy folder, and upload the patch on the LiveGeometry project website (http://livegeometry.codeplex.com/SourceControl/UploadPatch.aspx).
Check-in directly. If you're a developer on the project, feel free to just check in (although if you're unsure, I'd be happy to review a shelveset or a patch). Live Geometry is still in its early stages, so I can always refactor and improve the code as necessary, so don't be afraid to break things.

Coding guidelines

I am very passionate about clean code and uniform coding guidelines, so one thing I ask of contributors is to maintain these guidelines. So please bear with me if I ask you to correct a thing or two about your source code.
CodingGuidelines