Just another Vector Class

So this is just something that I did for my teacher, it's a class that does some simple math on 3D Vectors.  It's not entirely finished, but it gets the job done.

The comments pretty much explain how it works, but a simple test would work like this:

public void Test()
{
    Vector P = new Vector(3f, 4f, 5f);
    Vector Q = new Vector(40f, 10f, 20f);

    MsgBox("Addition: ", P + Q);
    MsgBox("Subtraction: ", P - Q);
    MsgBox("Division: ", P / Q);
    MsgBox("Dot Product: ", P * Q);
    MsgBox("Cross Product: ", P ^ Q);
    MsgBox("Gram Shmidt Orthonormalization: ", P.GramShmidt(P, Q));
}
public void MsgBox(string desc, object obj)
{
    MessageBox.Show(desc + "\n\r" + obj.ToString());
}

Comments or suggestions are welcome.

(Picture somewhat unrelated)

littleguru wrote:



You should also always start member variables with an underscore (_) or "m_". In C# the _ is used most by devs.

Just a few ideas from my side

I thought the MS code convention does not use the underscore notation. Member are always lower case and properties the sam word with the first letter uppercase like:

private string foo;
public string Foo
{
get{...}
set{...}
}

Is not that what FxCop force?

section31 wrote:

Is not that what FxCop force?

FxCop isn't concerned with how you name private members. It only looks at public stuff.

I prefer the _ prefix as well, since I believe that having two identifiers that differ only by case is a Bad Idea(tm).

littleguru wrote:



Sven Groot wrote: ...Bad Idea(tm).

Haha! Not only that... You could have a local variable that has exactly the same name. like "value" ... Now to get the class member you need to write this.value - When adding a _ you just type that underscore and get all the class fields... No overlapping/hiding.

I read this from http://msdn2.microsoft.com/en-us/library/ms229012.aspx 

Names of Fields
The naming guidelines for fields apply to static public and protected fields. You should not define public or protected instance fields. For more information, see Field Design.

Do use Pascal casing in field names.
Do name fields with nouns or noun phrases.
Do not use a prefix for field names. For example, do not use g_ or s_ to distinguish static versus non-static fields.

 

section31 wrote:

I read this from http://msdn2.microsoft.com/en-us/library/ms229012.aspx 

Names of Fields
The naming guidelines for fields apply to static public and protected fields. You should not define public or protected instance fields. For more information, see Field Design.

Added emphasis. These guidelines aren't applicable to private fields.

The only people who care what you name your private members are your other team members. Decide on something and stick with it. Be consistent, not much else matters.

I see your objection. But again when started with coding in C# I'looked for coding conventions and  I foond something on MS sites. You can see that on http://msdn2.microsoft.com/en-us/library/ta31s3bc(vs.71).aspx">http://msdn2.microsoft.com/en-us/library/ta31s3bc(vs.71).aspx where is an example class:

public class Control: Component
{
   private int handle;
   protected int Handle
   {
      get
      {
         return handle;
      }
   }
}



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

2.6 Naming

Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

• Do not use Hungarian notation
• Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

....


But maybe I have to rethink my conventions.

littleguru wrote:

Public field... No no never, never ever (Texas Lightning)!

Public consts count as public fields. And in some cases where you can't use a const you would use a public static readonly field.

I think it's pointless to disagree about naming. I have my own style which I prefer and I have very clear (to me) reasons for doing so. Because I rarely work in a team I'm free to use what I want.

If you feel you should use something else, by all means do. Nobody is right or wrong here.

There's only two things that I feel are really important here:
1. Pick a style and stick to it. Consistency is the most important thing in creating readable code.
2. If you do work in a team, make sure everybody uses the same style.

That's all.

section31 wrote:



I see your objection. But again when started with coding in C# I'looked for coding conventions and  I foond something on MS sites. You can see that on http://msdn2.microsoft.com/en-us/library/ta31s3bc(vs.71).aspx">http://msdn2.microsoft.com/en-us/library/ta31s3bc(vs.71).aspx where is an example class:

public class Control: Component
{
   private int handle;
   protected int Handle
   {
      get
      {
         return handle;
      }
   }
}



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

2.6 Naming

Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

• Do not use Hungarian notation
• Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

....


But maybe I have to rethink my conventions.

If it's worth anything, I do the same in my own projects.  It's mainly because I started out in Java, where you don't have the concept of properties, so you don't end up with names differing only in case.  In Java, it makes more sense to have, say,

private int number;
public int getNumber() {

than it does to stick in an extra _ in the name.

On the subject of duplicating the names of local and member variables, I do it.  It makes sense to me to have names duplicated if a variable is going to end up setting the class variable of the same name anyways (as in a constructor).

Of course, if a job were to require that I adhere to specific guidelines or I were working with someone else's code, I would adhere to their style, but this is how I format my code in my own projects.

The big areas where I differ from the .Net coding guidelines are in PascalCasing and bracket placement.  Pascal casing is too hard to type compared to camel casing everything (camelCase) and in bracket style.

littleguru wrote:

I know about that... But not even Microsoft is following it in the .NET Framework. And what I do is to follow these guidelines.

Look at this example:

    class Foo

    {

        private string foo;

 

        public void SetFoo(string foo)

        {

            this.foo = foo;

        }

    }

It's a show example, without real meaning, but demonstrates what I mean. In this case the foo argument is overlapping the foo class member. Which isn't very funny. It leads to bugs that are hard to find! I had to add this to make C# understand that the foo I'm referencing to is the class member foo and not the argument.

At the company I used to work for we always had the opinion to follow 90% of the official coding guidelines. Class field naming was not in that 90%, because even Microsoft didn't do it...

You are right with overlapping names and  this already happens in my code one or two times. I guess it's a good reason to break the guidline in this case.

I guess this doesn't apply since most people here are using C# and VB but my professor has a bunch of very usefull C++ classes for points, vectors and transformations in an affine space.  The point and vector classes implement an affine space.  It has all the standard vector stuff but also supports subtracting points to get vectors and also adding vectors to points to get new points.

http://graphics.idav.ucdavis.edu/education/CppNotes/Classes-We-Use.html

littleguru wrote:



    class Foo

    {

        private string foo;

 

        public void SetFoo(string foo)

        {

            this.foo = foo;

        }

    }

I'm using the _ prefix more as a shorthand notation for "this."

It's shorter to write

_foo = foo.

Although, I find it more useful in this more typical example:

public void DoSomething(string foo)
{
   ....
   // 20 lines later
   _someProp = foo;

   // is much more readable than...

   someProp = foo;   // is "someProp" a local var? or a member?

}

----------

Re: the Vector class, it'd be nice if someone could make an visual Vector app.... say, I type new Vector(2, 3, 0) ... I get to see it on the screen... Wouldn't that be cool?

littleguru wrote:



You should also always start member variables with an underscore (_) or "m_". In C# the _ is used most by devs.

Just a few ideas from my side

Well my roots are in VB, so I guess I just like to take advantage of the fact that C# is case-sensitive.