The Sandbox Thread

21 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Just another Vector Class

Back to Forum: The Sandbox
  • User profile image
    vbrunner__

    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)

  • User profile image
    littleguru

    Hi! Nice class. Although I few things are strange... Why are you setting all properties in the constructor and then creating an array and set it again? I would turn the Array property to a ToArray() method...

    The Array[x] in the setters of the X, Y, Z and H properties does just nothing. You create an array (when calling the getter of Array property) on the fly - you change it and the change gets lost. You are already setting the x, y, z, or h in the setter. That's enough.

    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 Smiley

  • User profile image
    bitdisaster

    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?

  • User profile image
    littleguru

    section31 wrote:
    
    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?


    If you use Reflector and look at the classes (the one of the BCL) you will see that most member variables (class fields) start or with a m_ or a _

    I have also read once (on a website) that this.<membervariable> should be used. But I find it a lot easier to start them with an _

  • User profile image
    Sven Groot

    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).

  • User profile image
    littleguru

    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.

  • User profile image
    bitdisaster

    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.

     

  • User profile image
    Sven Groot

    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.

  • User profile image
    littleguru

    Sven Groot wrote:
    
    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.


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

  • User profile image
    bitdisaster

    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.

  • User profile image
    Sven Groot

    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.

  • User profile image
    littleguru

    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...

  • User profile image
    littleguru

    Sven Groot wrote:
    
    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.


    Valid points! Public consts are OK, public readonlys also. string.Empty is for example a public readonly!

    Yes. Consistency (as always) is very important.

  • User profile image
    Cannot​Resolve​Symbol

    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.

  • User profile image
    bitdisaster

    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.

  • User profile image
    Jhaks

    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

  • User profile image
    Minh

    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?

  • User profile image
    vbrunner__

    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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.