why `Private Sub` instead of `Public Sub`

Question

I have searched for the difference between Private Sub , Public Sub and Sub to make sure of what i have to use.

i have got a question, why don't we use Public Sub instead of Private Sub ? Public Sub can be accessed from any module while Private Sub is only limited to this small place

File 1:

Module ModuleA
    Public Sub Test()
        messagebox.show("Message from Public Sub")
    End Sub
End Module

File 2:

Module ModuleB
    Private Sub Run_Public_Sub Handles Button.Click
        Test()
    End Sub
End Module

Answer 1

Deciding whether to use Private over Public all comes down to the intended scope of what is being declared. While yes, using Public with a Sub means that the code can be referenced from most anywhere and may seem like a good idea, doing so may cause undesirable results.

For example, if I created all of my Sub s as Public , I may inadvertently call a Sub that relies on something that isn't there which will result in a NullReferenceException at runtime. See the following example:

Class fooBar
    Private Property myPrivateProperty As String
    Public Property myPublicProperty As String
    Public Property myValue As String

    Public Sub New()
        myPublicProperty = "Hello"
    End Sub

    Public Sub callThisSubFirst()
        myPrivateProperty = "World"
        setValue()
    End Sub

    Public Sub setValue()
        myValue = myPublicProperty.ToUpper & myPrivateProperty.ToUpper
    End Sub
End Class

As you can see in the above example, I have used the Public modifier on all Sub s in the class fooBar . If I were to call the setValue() method before calling the callThisSubFirst() method, a NullReferenceException will occur because I am trying to call the .ToUpper string extension on a string object that is not instantiated.

Sub Main()
    Dim test As New fooBar
    test.setValue() ' NRE will occur here
    Console.WriteLine(test.myValue)
End Sub

What should have happened was that the callThisSubFirst() method should have been called in order to instantiate myPrivateProperty and only after that should have the setValue() method have been called. If I had marked the setValue() method as Private then I would have received an error stating that setValue() was not available in the context when I attempted to call it outside of the class; which is exactly what needs to happen since setValue() depends on the callThisSubFirst() method being executed. Here's how the code should have been written:

Class fooBar
    Private Property myPrivateProperty As String
    Public Property myPublicProperty As String
    Public Property myValue As String

    Public Sub New()
        myPublicProperty = "Hello"
    End Sub

    Public Sub callThisSubFirst()
        myPrivateProperty = "World"
        setValue()
    End Sub

    Private Sub setValue()
        myValue = myPublicProperty.ToUpper & myPrivateProperty.ToUpper
    End Sub
End Class

And here's how it should have been used:

Sub Main()
        Dim test As New fooBar
        test.callThisSubFirst() ' Hurray, no exceptions!
        Console.WriteLine(test.myValue)
End Sub

That's just one example of how marking everything to Public can cause issues in your application. There are multitudes of other reasons why doing so is also a less than ideal solution, the biggest being maintainability. If everything is marked as Public in a class and a small change needs to be made to a single method, the entire code base will need to be checked to confirm that the change doesn't affect any other callers which may be expecting the original behavior. If the method or function is marked as Private to begin with, then the only code that needs to be checked is the code that resides within the same scope.

Answer 2

You seem to understand the difference between public and private , that a good start. Yes, you could use public wherever private can be used but that's not necessarily a good thing. I believe the main reason for using both access levels is maintainability. Changes to code that is accessible from outside of the class or module can cause additional changes to the other classes and components. This can complicate code modifications by causing multiple changes throughout an application. Changes to a private routine can only directly affect the class or module that contains it. Making routines private prevents other developers from using them directly. This frees the developer of the class to make changes to private code without having to be concerned that it might adversely affect other developers.