Thread: Naming for Namespace, Class, and Variables

Hello.

First question, are you developing a FLOSS application, Closed-Source Library (for resale) or a Closed-Source Application?

In the last case, I'd stick with naming convention YOU can live with...in the other two cases it is most important that the interface of the code is intuitive. In the first two cases make sure to use XML-Documentation.

Code:

Navigation.Heading.Direction 'leads me to something what points into a direction

Value is used whenever it is logical that the Object has properties and a underlaying value.

Bobby

WhatToName2: Direction as suggested is a good property name for this.
WhatToName1: _direction would be my choice.
WhatToName3: direction is the guidelines suggestion in this case.
WhatToName4: value is put here by the property snippet, it is also commonly used in the .Net library.

Guidelines for Names

Originally Posted by JohnH

WhatToName2: Direction as suggested is a good property name for this.
WhatToName1: _direction would be my choice.
WhatToName3: direction is the guidelines suggestion in this case.
WhatToName4: value is put here by the property snippet, it is also commonly used in the .Net library.

I would agree with JohnH on 2, 1 and 4.

For 3, I prefer to defy convention and use "whatDirection" as I feel "Me.Direction = direction" is messy. Purely my personal preference though.

Originally Posted by InertiaM

I would agree with JohnH on 2, 1 and 4.

For 3, I prefer to defy convention and use "whatDirection" as I feel "Me.Direction = direction" is messy. Purely my personal preference though.

"Me.Direction = direction" may look at bit confusing to a developer, but the key here is what the user sees when using this class. The guideline I had in mind was this from Constructor Design :

Do use the same name for constructor parameters and a property, if the constructor parameters are used to simply set the property. The only difference between such parameters and the properties should be casing.

So when consumer uses this constructor it should be obvious that the 'direction' parameter is a way to set the 'Direction' property directly when creating the class instance.

Whether is was "Me.Direction = direction" (setting value through property setter) or "Me._direction = direction" (setting value to private field) is just a matter of reuse of existing code if necessary, for example when setter does validation.

Thanks everyone. This is very helpful and I think I am getting the hang of it. I have another one that is exactly the same but is for Bearing ("The direction of one object in relation to another object"). So that one would be Navigation.Bearing.Direction right?

Last question: I have another class, the same as above, which is called "Speed". It is used to hold meters per second. I am using it for this GPS app but I don't think it should go into the Navigation namespace as it could be related to stuff other than navigation, right? For the property name of this class, would I want to name it something like "MetersPerSecond" or is that a no no?

Stephen

Originally Posted by subaru_sti

Thanks everyone. This is very helpful and I think I am getting the hang of it. I have another one that is exactly the same but is for Bearing ("The direction of one object in relation to another object"). So that one would be Navigation.Bearing.Direction right?

Last question: I have another class, the same as above, which is called "Speed". It is used to hold meters per second. I am using it for this GPS app but I don't think it should go into the Navigation namespace as it could be related to stuff other than navigation, right? For the property name of this class, would I want to name it something like "MetersPerSecond" or is that a no no?

Stephen

I can't see why you would need a class for speed. Surely speed is just a number, so you'd just assign a value to a Double variable or the like. The only reason I can see to have a class for speed would be if you wanted to have a numerical value and a unit as well, e.g. kph or m/s.

I want to have a class so that in the SET, I can validate that the value is greater than 0.

Stephen

Okay. I think this makes sense, to me anyways:

Code:

Namespace GPS
    Public Class Speed
        Private _metersPerSecond As Double

        Public Sub New(ByVal metersPerSecond As Double)
            Me.MetersPerSecond = metersPerSecond
        End Sub

        Public Property MetersPerSecond() As Double
            Get
                Return _metersPerSecond
            End Get
            Set(ByVal value As Double)
                If value < 0 Then Throw New ArgumentOutOfRangeException("Speed cannot be less than 0.")

                _metersPerSecond = value
            End Set
        End Property
    End Class
End Namespace

Stephen

That still doesn't make sense. Consider this. If you had a Car class would it make sense to say myCar.Speed.MetersPerSecond = 10? That doesn't make sense to me. What does make sense is myCar.Speed = 10. The Car class would have a Speed property of type Double and you would validate the value inside that property. Having a whole separate class for speed is not appropriate.