I ran into a major issue with how we were handling naming conventions in our C# code. We had originally decided to follow the C# convention of uppercase method names and convert fan method names under the covers. However, C# prevents you from having a method with the exact same name as the enclosing class:
class Type
{
public Type Type() { return type; } // error!
}
When I first discovered this I thought I could just work around it with a hack using a different name. But that breaks polymorphism. Type() is defined on Obj, so you see the dilemma. You can't guarantee a subclass won't violate this rule unless the Fan compiler enforces it. I also ran into this case with Map.map().
So we decided to go back and use lowercase method names in all our fan code. And the Fan compiler will also prevent method names from exactly matching the class name. As a result of that, we also adopted the convention of using the m_ prefix for fields:
class Type
{
public Type type() { return m_type; } // ok
}
C# also dissallows the use of the $ character in identifier names. The Java code uses this convention for the instance make constructors, and also for mixins, all the C# code will use the underscore instead.
andyTue 13 Nov 2007
C#/Fan naming conventions
Namespace
Namespace is written as "Fan.<podName>" using Pascal case:
Type names use the same Pascal case as Fan, so they will be the same:
Int -> Int
OutStream -> OutStream
TimeZone -> TimeZone
Methods
Methods are written using camel case (note this differs from the .NET convention of Pascal case). We use camel case to avoid naming conflicts in some of the sys classes (i.e., Type.type(), Map.map()). So C# method names will always match the Fan version:
Fields are broken out into one or more slots, with accessors using the same camel case as Fan, and the backing field written using camel case and perpended with "m_":
andy Fri 23 Feb 2007
I ran into a major issue with how we were handling naming conventions in our C# code. We had originally decided to follow the C# convention of uppercase method names and convert fan method names under the covers. However, C# prevents you from having a method with the exact same name as the enclosing class:
When I first discovered this I thought I could just work around it with a hack using a different name. But that breaks polymorphism. Type() is defined on Obj, so you see the dilemma. You can't guarantee a subclass won't violate this rule unless the Fan compiler enforces it. I also ran into this case with Map.map().
So we decided to go back and use lowercase method names in all our fan code. And the Fan compiler will also prevent method names from exactly matching the class name. As a result of that, we also adopted the convention of using the
m_
prefix for fields:C# also dissallows the use of the $ character in identifier names. The Java code uses this convention for the instance make constructors, and also for mixins, all the C# code will use the underscore instead.
andy Tue 13 Nov 2007
C#/Fan naming conventions
Namespace
Namespace is written as "Fan.<podName>" using Pascal case:
Types
Type names use the same Pascal case as Fan, so they will be the same:
Methods
Methods are written using camel case (note this differs from the .NET convention of Pascal case). We use camel case to avoid naming conflicts in some of the sys classes (i.e., Type.type(), Map.map()). So C# method names will always match the Fan version:
Fields
Fields are broken out into one or more slots, with accessors using the same camel case as Fan, and the backing field written using camel case and perpended with "m_":
A special case is made for the public
val
field on some sealed sys types (Int, Str):